Transport Protocols for Internet- Compatible Satellite Networks Written by Thomas R. Henderson and...
-
Upload
oscar-murphy -
Category
Documents
-
view
222 -
download
0
Transcript of Transport Protocols for Internet- Compatible Satellite Networks Written by Thomas R. Henderson and...
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
2. Transport Environment of Future Satellite Systems2. 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 Systems2. 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 Systems2. 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. 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
4. Methodology4. Methodology
Fig. 2 Experimental setup
14
4. Methodology4. 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 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
5. TCP Performance over Satellite Networks5. 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 Networks5. 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 Networks5. TCP Performance over Satellite Networks
Fig. 3 Throughput performance of different TCP
19
5. TCP Performance over Satellite Networks5. 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 Networks5. 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 Networks5. TCP Performance over Satellite Networks
Fig. 4 Throughput performance of TCPSACK-NewReno
22
5. TCP Performance over Satellite Networks5. 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 Networks5. TCP Performance over Satellite Networks
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
5. TCP Performance over Satellite Networks5. TCP Performance over Satellite Networks
Table I TCP latency effects (in s) on HTTP transfers
25
5. TCP Performance over Satellite Networks5. 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 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
6. Split TCP Connections6. Split TCP Connections
Fig. 6 Satellite networking with split TCP connections
28
6. Split TCP Connections6. 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 Connections6. 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 Connections6. Split TCP Connections
Fig. 7(a) Forward throughput performance of split TCP
31
6. Split TCP Connections6. Split TCP Connections
Fig. 7(b) Reverse channel utilization of split TCP
32
6. Split TCP Connections6. 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)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)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)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)7. Satellite Transport Protocol (STP)
Fig. 8 Example of STP operation
37
7. Satellite Transport Protocol (STP)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)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)7. Satellite Transport Protocol (STP)
Fig. 9a STP vs. TCP: Forward throughput performance
40
7. Satellite Transport Protocol (STP)7. Satellite Transport Protocol (STP)
Fig. 9b STP vs. TCP: Reverse channel utilization
41
7. Satellite Transport Protocol (STP)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. 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