Transport Protocols for Internet-Compatible Satellite Networks

1. Transport Protocols for Internet-Compatible Satellite Networks Written by Thomas R. Henderson and Randy H. Katz Presentation by Bilguun Bold January 22, 2004

2. 1. Introduction In this Presentation we will: • Evaluate how well TCP performs in a satellite environment in GEO or LEO. • Discuss the assumptions concerning future broad-band satellite systems. • Discuss extensions to standard TCP to improve performance in a satellite environment and point out some unresolved problems.

3. 1. Introduction • Describe the experiments to quantify the performances of different implementations of TCP, both for large file transfers and short Web transactions. • Investigate the improvements that can be gained by using a transport gateway to split the end-to-end connection. • Describe a new transport protocol STP for use within a satellite subnetwork or on the satellite side of the split connection.

4. 2. Transport Environment of Future Satellite Systems Fig. 1 General topology of satellite networking

5. 2. Transport Environment of Future Satellite Systems Main characteristics that affect transport protocol performance are: • Latency (propagation delay) • GEO: 270 ms (one way) • LEO: 20 ms for an altitude of 1000 km (one way) • Bandwidth asymmetry • May exist due to economic factors • Higher downlink bit rates than uplink bit rates

6. 2. Transport Environment of Future Satellite Systems • Transmission errors • New modulation and coding techniques should help to make normal bit error ratios (BER) very low. • Congestion • The uplink/downlink spectrum, which fundamentally limits the links between earth and satellites, should make the internal satellite network generally free of heavy congestion.

7. 2. Transport Environment of Future Satellite Systems In summary, future satellite systems expected to have: • Low bit error rates • Potentially high degrees of bandwidth and path asymmetry • Low internal network congestion

8. 3. Satellite TCP Fundamentals TCP did not perform well over satellite networks. Therefore some TCP extensions have been specified to improve the performance of TCP in such environments: • Window Scale: important particularly for satellite links, which require large windows to realize high data rates. • Selective Acknowledgements (SACK): allow for multiple losses in a transmission window to be recovered faster.

9. 3. Satellite TCP Fundamentals • TCP for Transactions (T/TCP): attempts to reduce the connection handshaking latency for most connections. This reduction can be significant for short transfers. • Path MTU Discovery: this option allows the TCP sender to probe the network for the largest allowable message transfer unit (MTU). Large MTU is efficient and helps the congestion window to open faster.

10. 3. Satellite TCP Fundamentals Despite the progress, there remain some unresolved problems. For these problems, there are no standardized solutions: • Slow Start: TCP’s slow start mechanism may still be too slow for broadband connections. Possible solution is 4K slow start (4KSS) for transfers for file sizes under 4 Kbytes. • Link Asymmetry: when the reverse path has limited bandwidth, the TCP acknowledgement stream becomes burstier as ACKs are clumped together or dropped.

11. 3. Satellite TCP Fundamentals • Implementation Details: to trigger the window scaling options we need large buffer sizes. • This requires users to manually configure applications and TCP implementations. • Some applications do not permit such configurations, including common Web servers. • TCP Fairness: TCP’s congestion avoidance algorithm results in drastically unfair bandwidth allocations when multiple connections with different RTTs share a bottleneck link.

12. 4. Methodology The experiments were conducted using hosts (running BSD/OS 3.0 Unix) connected to Ethernets in a local area subnet at Berkeley. • Receivers were configured to offer the largest window possible (240 kbytes) to the senders. • Traffic sources were connected to a 100 Mbits/s Ethernet. • Traffic sinks were on a 10 Mbits/s Ethernet separated by a 10 Mbits/s transit Ethernet segment.

13. 4. Methodology Fig. 2 Experimental setup

14. 4. Methodology • GEO satellite links were modeled by a constraint of 1.3 Mbits/s of TCP/IP bandwidth on a 600 ms RTT link. • LEO satellites were modeled by a constraint of 1.3 Mbits/s with a fixed RTT in the range of 40-400 ms. • The links had no bit errors or variation in propagation delay.

15. 5. TCP Performance over Satellite Networks Performance for Large File Transfers Challenge: Large TCP congestion window requires better congestion avoidance and loss recovery mechanism. • TCP Reno: unmodified TCP implementation, which supports window scale and MTU discovery. • TCP NewReno: a collection of bug fixes and refinements for how TCP Reno handles the fast recovery phase of congestion avoidance.

16. 5. TCP Performance over Satellite Networks • TCP SACK-Reno: TCP-Reno congestion avoidance algorithms combined with the SACK option for loss recovery. • TCP SACK-NewReno: TCP NewReno congestion avoidance algorithms combined with the SACK option for loss recovery. • For file transfer experiment, 10 Mbyte files were repeatedly transferred with varying satellite channel latency.

17. 5. TCP Performance over Satellite Networks Results: • For low values of RTT (less than 100 ms), the performance is relatively high for all. • For greater delays (greater than 100 ms), there are differences in performance due to behavior immediately upon leaving the slow start of congestion avoidance.

18. 5. TCP Performance over Satellite Networks Fig. 3 Throughput performance of different TCP

19. 5. TCP Performance over Satellite Networks Results: • TCP SACK-NewReno: has the best performance cutting its window in half once • TCP SACK-Reno: multiple reduction in congestion window. • TCP NewReno: can only recover one loss per RTT. • TCP Reno: almost no avoidance in multiple reduction in congestion window.

20. 5. TCP Performance over Satellite Networks However, in the wide-area Internet, competition from many different connections leads to network congestion. In this case, it only takes one low delay (20 ms RTT) to drastically reduce the achievable throughput for TCP SACK-NewReno (mostly due to TCP fairness problem).

21. 5. TCP Performance over Satellite Networks Fig. 4 Throughput performance of TCPSACK-NewReno

22. 5. TCP Performance over Satellite Networks In summary, we observe that • The use SACK alone is not sufficient. • SACK accelerates the loss recovery phase. • NewReno helps to avoid coarse timeouts and multiple window reductions. • It only takes low levels of congestion to impair the performance of even well-configured TCP connections.

23. 5. TCP Performance over Satellite Networks Performance for Web Transfers Besides file transfers, most of the TCP traffic in the Internet is driven by Web transfers. Two mechanisms attempt to alleviate the latency effects of TCP for short connections: • T/TCP does away the initial handshake (RTT) of the connection. • 4KSS allows the TCP server to send up to 4380 bytes in the initial burst of data.

24. 5. TCP Performance over Satellite Networks Table I TCP latency effects (in s) on HTTP transfers

25. 5. TCP Performance over Satellite Networks Results: • The use of either T/TCP or TCP with 4KSS improves mean latency by a small amount. • The combination of both, T/TCP with 4KSS, can offer a 50% improvement in user perceived latency. • P-HTTP: allows for a single TCP connection between client and server to be reused for multiple objects.

26. 6. Split TCP Connections The basic idea is to insert a gateway on the link between the satellite terminal equipment and the terrestrial network. The goal is: • To shield high latency network segments from the rest of the network. • To use an alternative protocol for the satellite portion of the connection.

27. 6. Split TCP Connections Fig. 6 Satellite networking with split TCP connections

28. 6. Split TCP Connections Split Connection Approaches: • TCP Spoofing: the gateway on the network side prematurely acknowledges data destined for the satellite host. • TCP Splitting: the connection is fully split, so a different transport protocol can be used in the satellite portion of the network. • Web Caching: Users in the satellite network, connected to this web cache, need not to set up connections, if the requested contents are available from this web cache.

29. 6. Split TCP Connections Hazards: • The data accumulates at the spoofer (gateway) leading to second bottleneck. • TCP source is unaware of the event of link interruption and will continue sending packets until the buffer overflows. • A split connection that is not explicitly associated with a proxy or a cache breaks the end-to-end semantics of the transport layer.

30. 6. Split TCP Connections Fig. 7(a) Forward throughput performance of split TCP

31. 6. Split TCP Connections Fig. 7(b) Reverse channel utilization of split TCP

32. 6. Split TCP Connections Split Connection Performance: • The reverse channel usage required of this TCP connection is roughly 20 kbits/s. • For 1000 byte segments, it’s roughly 2% of the forward throughput achieved. • This sets an upper bound on the forward throughput achievable.

33. 7. Satellite Transport Protocol (STP) STP is specifically optimized for the satellite environment for use in place of TCP. It’s an outgrowth of an existing ATM-based, reliable link layer protocol SSCOP. STP can be used in two ways: • As the satellite portion of a split TCP connection. • As a transport protocol for control and network management traffic within a satellite communications network.

34. 7. Satellite Transport Protocol (STP) Features: • Sequence numbers on packets (not bytes). • Periodic request for acknowledgement. • Selective negative acknowledgement for lost data. • Retransmission of specific packets explicitly requested by the receiver. • No retransmission timers.

35. 7. Satellite Transport Protocol (STP) Operation: STP has 4 basic packet types for data transfer: • SD: sequenced data (a segment of user data) • POLL: periodically sent to the receiver for acknowledgement for sent data. • STAT: selective acknowledgements, including complete report of the state of the receiver. • USTAT: negative acknowledgements, reporting gaps in the received sequence packets (without waiting for POLL).

36. 7. Satellite Transport Protocol (STP) Fig. 8 Example of STP operation

37. 7. Satellite Transport Protocol (STP) Protocol Modifications: • Congestion Control: The SSCOP included no congestion control mechanism. • Handshake Avoidance: data are allowed to be sent in a BEGIN message. • Piggybacked POLL: reduces the number of standalone POLL segments and quickly triggers STAT responses.

38. 7. Satellite Transport Protocol (STP) Performance – STP vs. TCP SACK-NewReno for large file transfers: • STP and TCP SACK-NewReno achieve approximately the same forward throughput. • For long RTT, STP’s throughput is slightly smaller due to congestion control mechanism • In the reverse direction, STP uses much less bandwidth due to polling frequency.

39. 7. Satellite Transport Protocol (STP) Fig. 9a STP vs. TCP: Forward throughput performance

40. 7. Satellite Transport Protocol (STP) Fig. 9b STP vs. TCP: Reverse channel utilization

41. 7. Satellite Transport Protocol (STP) Performance – STP vs. TCP, T/TCP for Web transfers: • Overall STP behavior is similar to that of T/TCP for short transfers • The reverse channel utilization of STP is greatly reduced for long transfers (as low as 1kbits/s). Table II STP, TCP, T/TCP performance for HTTP traffic

42. 8. Conclusions • Maintaining good performance over GEO latencies (or long LEO paths) is challenging • TCP (SACK-NewReno) can work well for large transfer, even over GEO links. • Moderate congestion (traffic in the Internet) degrades satellite connection performance. • T/TCP plus 4KSS benefits Web transfers • Split TCP connections help to keep throughput high • STP is optimized for satellite links with low reverse bandwidth utilization