transport protocols for internet-compatible satellite networks

Transport Protocols for Internet-Transport Protocols for Internet-Compatible Satellite NetworksCompatible Satellite Networks

Written by Thomas R. Henderson and Randy H. Katz

Presentation by Bilguun Bold

January 22, 2004

2

1. Introduction1. 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. Introduction1. 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 Systems2. Transport Environment of Future Satellite Systems

Fig. 1 General topology of satellite networking

5


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


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


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. 3. Satellite TCP FundamentalsSatellite 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. 3. Satellite TCP FundamentalsSatellite 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 Fundamentals3. 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 Fundamentals3. 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. Methodology4. 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


Fig. 2 Experimental setup

14


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 Networks5. 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


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


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


Fig. 3 Throughput performance of different TCP

19


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


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


Fig. 4 Throughput performance of TCPSACK-NewReno

22


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


Performance for Web TransfersBesides 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


Table I TCP latency effects (in s) on HTTP transfers

25


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 Connections6. 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


Fig. 6 Satellite networking with split TCP connections

28


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


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


Fig. 7(a) Forward throughput performance of split TCP

31


Fig. 7(b) Reverse channel utilization of split TCP

32


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)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


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


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


Fig. 8 Example of STP operation

37


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


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


Fig. 9a STP vs. TCP: Forward throughput performance

40


Fig. 9b STP vs. TCP: Reverse channel utilization

41


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. Conclusions8. 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

transport protocols for internet-compatible satellite networks

Documents

satellite environment

satellite tcp fundamentalstcp

satellite links

satellite subnetwork

internal satellite network

performance of tcp

tcp extensions

standard tcp