VESTIGIOS ARABES EXISTENTES

TCP treats all losses on the journey between source and destination as an indication of congestion, or overflowing packet buffers in router queues leading to discards. TCP creates its own imperfect feedback on the state of its communication path and thus the internetwork the path traverses, as a result of its acknowledgements. The performance of an end-to-end TCP connection does not equate to the performance of any link that the TCP connection is carried across. TCP cannot be aware of the condition of an individual subnetwork or link.

To illustrate this, consider an end-to-end TCP connection across a number of joined networks, one of which is an ATM network where an available bit-rate (ABR) virtual channel is used to tunnel the TCP packets across the ATM network.

ABR is generally intended to be closed-loop, where the network communicates its congestion state back to the endpoints so that they can adjust their output

[KalyJainetal98]. This contrasts with the more open-loop approach taken by TCP, where TCP infers network conditions, rather than being told them explicitly.

If the ATM network is congested, there is no way that ABR with explicit rate (ER) feedback can tell the TCP endpoints how much they need to decrease their output, and ABR may then make decisions about allocation which are inappropriate for the needs of the TCP senders.

The TCP endpoints do not react directly to the congestion in the ATM network, and gain a less accurate picture of congestion in that network as a result. Here, the different assumptions used in tunnelling and tunnelled protocols have acted to break

any direct feedback loop from congestion through losses to TCP detection.

That is one example demonstrating that the information about the internetwork inferred from TCP’s acknowledgements feedback loop is not indicative of the state of networks through which TCP/IP traffic is tunnelled. As many (often ATM-based) satellite networks will be tunnelling IP, implementations of TCP’s

congestion-avoidance mechanism at the customer endpoints may well be of little use to the satellite network operators. If the tunnels are guaranteed channels, then the user will expect to get the full channel capacity that is being paid for. This explains the satellite operator’s traditional emphasis on getting the most from fixed channels, and concern over TCP’s congestion-control reaction to packet losses caused by link errors, rather than by congestion.

A number of intertwined algorithms determine the rate at which TCP puts new data into the network, and how losses are detected and handled. In particular, a TCP sender maintains a congestion window variable that determines how large the size of its sliding window of unacknowledged data given to the network can be at any point in time. This cwnd variable is increased over time from start, or after congestion losses, as the TCP sender probes the network and discovers that new data can be sent with increasing frequency. It is decreased when the sender infers losses due to congestion. Slow-start and other algorithms control the congestion window and other TCP settings. These are described in detail in [RFC2581].

3.3.1 Errors in the satellite environment

Communication between terminals using a geostationary satellite has a comparatively long round-trip time (RTT) from sender to receiver and back of the order of half a second. This means that considerable time is needed in slow-start, on opening a new connection for TCP, to increase its throughput to what the link capacity will bear. Any losses due to errors in transmission on a less-than-perfect satellite link, rather than to congestion, cause TCP to reduce its overall sending rate to help alleviate perceived congestion. After an errored packet is inferred as lost due to congestion, and the congestion window is reduced, the return to the previous high rate of throughput is slowed by the large RTT.

Current TCP congestion control algorithms assume that packets that are lost due to

satellite channel errors are lost as a result of internetwork congestion. The errors in the satellite channel can be bursty as a result of convolutional coding; interleaving and an outer Reed-Solomon code can randomise and spread the occurrence of errors, but any errors will still affect higher layers. This leads to sub-optimal use of available satellite link capacity after an error where frame loss leads to packet loss: congestion avoidance algorithms cause the TCP sender to decrease its sending rate dramatically, followed by a slow return to the previous transmission rate. This can waste expensive satellite channel capacity in the interim.

This really results from a lack of reliable explicit congestion notification [RFC2481], or some roughly-equivalent form of explicit corruption notification, to distinguish between network congestion and link errors. Tweaking congestion control algorithms to improve performance slightly in the satellite environment cannot completely

compensate for this lack of information on the real cause of packet loss.

In both TCP slow-start and when recovering from errors, increasing the congestion window takes a number of slow half-second roundtrips, and the capacity of an expensive satellite link will not be fully used as a result. Satellite considerations for TCP are detailed in [PartridgeShepard97] and [RFC2488].

TCP’s process of treating error recovery as congestion and using timeouts has been improved by the later introduction of fast retransmit and recovery. These permit less backoff in cases where communication between sender and receiver is still clearly taking place [RFC2581].

3.3.2 Coding on the satellite link

Careful selection of physical- and data-link error-correction suitable for the space environment can minimise the errors on a link, in packets and thus seen by TCP. This can minimise the effects of errors on congestion control algorithms, without requiring changes in the TCP implementations. Improvements in coding on satellite links have altered link error characteristics to be in one of two states from a packet-level viewpoint: either error-free or extremely errored. With a correctly-dimensioned purpose-designed satellite link, making possible the low resulting error rate that TCP expects, it can be assumed that the satellite link is as reliable as any terrestrial link. This

assumption is extremely useful for simulation, as it allows concentration on effects of interest, without confusing the results for the added effects on TCP resulting from packet discards or transmission errors leading to packet loss.