$
' TCP Behavior in Networks with Dynamic Propagation Delay Mark Allman, NASA GRC/BBN Jim Griner, NASA GRC Alan Richard, NASA GRC/Analex
&
IEEE Globecom November, 2000 1
%
'
&
$
Overview Introduction and Motivation Simulation Environment RTO Estimator Validation Simple TCP Experiments Simple Hando Experiments Conclusions
IEEE Globecom
November, 2000 2
%
'
&
$
Introduction and Motivation
Plenty of researchers have looked at the impact of long, static delays on TCP performance. - See RFCs 2488, 2760 and references therein. But, what about situations where the propagation delay changes over time? - E.g., NASA's Earth-observing satellites.
IEEE Globecom
November, 2000 3
%
'
&
Introduction and Motivation (cont.)
$
Our paper is based on models of satellites sending data to the ground. However, we believe the results apply to any situation where modest motion is involved.
IEEE Globecom
November, 2000 4
%
'
&
$
Simulation Environment We used a variety of spacecraft orbiting in the LEO and MEO bands. - These spacecraft send data to TDRS, which transmits the data to Earth. We used Satellite Toolkit 4.0 to generate orbital data. We introduced a variable delay link into the ns network simulator. - The propagation delay along the link changes as a function of time, based on the STK output.
IEEE Globecom
November, 2000 5
%
'
Simulation Environment (cont.)
$
Simulated topology: LEO/MEO S
100 Mbps 1 ms
R1
1.5 Mbps Var. Delay
TDRS (GEO) 1.5 Mbps 250 ms
D
100 Mbps 1 ms
R2
Earth
&
IEEE Globecom
November, 2000 6
%
'
Variable Delay Scenarios
0.545
0.55
0.545
0.55
0.54
0.54
0.54
0.54
0.5
0.505 1000
1500 2000 Time (sec)
2500
3000
3500
0.55
0.54
0.54
0.535
500
1000
1500 2000 Time (sec)
2500
3000
3500
0.525 0.52
0.52 0.51
0.49
0.51 0.505
0.48 0
500
1000 1500 2000 2500 3000 3500 4000 Time (sec)
1000 1500 2000 2500 3000 3500 4000 Time (sec)
0
0.555
0.56
0.55
0.55
0.545
0.54
0.535 0.53 0.525
0.5
0.515
0.48 500
0.54 RTT (sec)
RTT (sec)
0.53
500
1000
1500 2000 Time (sec)
2500
3000
0.5 0.49 2000 4000 6000 8000 10000 12000 14000 16000 Time (sec) 0.6
0.6
0.58
0.545
0.54
0.58
0.56
0.53
0.56
0.54
RTT (sec)
0.525
0.52 0.51
RTT (sec)
0.62
0.55
RTT (sec)
0.56
0.53
0.54 0.52 0.5
0.48
0.515
0.49
0.48
0.46
0.51
0.48
0.46
4000
6000 8000 10000 12000 14000 Time (sec)
0
500
1000 1500 2000 2500 3000 3500 4000 Time (sec)
3500
0
500
0
2000
1000 1500 2000 2500 3000 3500 4000 Time (sec)
0.5
0.5
2000
3000
0.52
0.52
0
2500
0.48 0
0.55
0.535
1500 2000 Time (sec)
0.51
0.555
0.54
1000
0.52
0.515 3500
500
0.53
0.52
0.51 0
0.51 0.5
0
0.53
0.52
0.49
0.505 0
0.545
0.52
0.51
0.48 500
0.525
0.515
0.49
0.51
RTT (sec)
0.51
0.53
0.53
RTT (sec)
0.52
0.52
RTT (sec)
0.525
RTT (sec)
0.53
0.515
RTT (sec)
0.535
0.53 RTT (sec)
RTT (sec)
0.535
0
$
0.44 0
5000
10000 15000 20000 25000 30000 35000 Time (sec)
4000
6000 8000 Time (sec)
10000 12000 14000
0.7 0.65
RTT (sec)
0.6 0.55 0.5 0.45
& 0.4
0.35
0
10000
30000
50000 Time (sec)
70000
IEEE Globecom
90000
November, 2000 7
%
'
$
Simple RTO Experiments TCP uses a retransmission timer (RTO) to guarantee reliable data delivery. The standard RTO estimator: RTO SRTT + 4 RTTV AR
&
RTO measured and calculated using a clock with granularity G. - Traditionally G = 500 ms - Some have suggested ner grained timers will yield better performance, so we also used G = 1 ms.
IEEE Globecom
November, 2000 8
%
'
&
Simple RTO Experiments (cont.)
$
Loss is also taken as an indication that the network is congested. - Hence, the sending rate is reduced. Therefore, one desirable property of an RTO estimator is that it not retransmit segments too early and cause a needless reduction in sending rate.
IEEE Globecom
November, 2000 9
%
'
&
Simple RTO Experiments (cont.)
$
Do the variable delay scenarios used in our experiments confuse the RTO estimator? - Set the maximum TCP window size to 1 segment. - Run a TCP transfer for the length of the scenario. - Watch for retransmissions. Answer: No. The RTO estimator is able to cope with the changing propagation delays we tested. - But, what about a slightly more dynamic environment with queueing delays?
IEEE Globecom
November, 2000 10
%
'
&
$
Single Flow Tests
Tested various le sizes (4{10,000 packets). The transfer start time was roughly every 60 seconds over the course of the scenario. Started with G = 500 ms
IEEE Globecom
November, 2000 11
%
'
$
Single Flow Tests (cont.)
Throughput (bytes/sec)
1e+06
4 pkts 8 pkts 20 pkts 200 pkts 2,000 pkts 10,000 pkts
100000
10000
1000
&
IEEE Globecom
0
2
4
6 8 Scenario Number
10
12
14
November, 2000 12
%
'
&
$
Single Flow Tests (cont.)
As expected... - Small les underutilize the capacity. - Large les nearly fully utilize the capacity. - More throughput variation in small les. Also, no unnecessary retransmits were detected.
IEEE Globecom
November, 2000 13
%
'
&
$
Single Flow Tests (cont.) What about using a ne-grained timer? - Small transfers (4{200 packets) did not cause needless retransmissions. Small transfers do not build queues { and we know that ne-grained timers work well with no queues on our delay scenarios. RTTV AR is initially RTTmeas , which in ates the RTO 2 at the beginning of a transfer, providing some protection against spurious retransmits. - Large transfer do experience needless retransmits.
IEEE Globecom
November, 2000 14
%
'
$
Single Flow Tests (cont.) 2,000 packet transfer 140000
Throughput (bytes/sec)
135000 130000 125000 120000 115000 110000
G=1 ms G=500 ms
105000
&
IEEE Globecom
0
2
4
6 8 10 Scenario Number
12
14
November, 2000 15
%
'
&
$
Hando Scenario Our last scenario models a perfect (no loss, no reordering) hando that essentially moves from a single GEO hop to a double hop and back. G = 1 ms cannot cope with the drastic change in RTT caused by moving from a single hop to a double hop. G = 500 ms does not needlessly retransmit even when crossing the large jump in throughput.
IEEE Globecom
November, 2000 16
%
'
&
$
Conclusions With a large minimum RTO (e.g., as we get with G = 500 ms) TCP performs quite well in the environments examined. Fine-grained timers reduce performance for long transfers. As in more static environments, short transfers often underutilize the capacity of the network path. The throughput obtained by short transfers is somewhat variable depending on start time.
IEEE Globecom
November, 2000 17
%
'
&
$
Future Work Consider more realistic hando s where reordering and/or loss may occur. When a satellite is moving, typically the signal strength is changing, as well as the propagation delay. This will yield di erent BERs at di erent points in the curve. This should be investigated. A more realistic trac pattern should be obtained and used.
IEEE Globecom
November, 2000 18
%
