SICS Technical Report ISRN:SICS-T–2005/11-SE
T2005:11 ISSN 1100-3154
A new proposal for congestion control in
ambient networks
Ian Marsh
Swedish Institute of Computer Science Box 1263, SE-164 29 Kista, Sweden
August 2005
Abstract
This report describes the protocol design of TCP with Forward Error Correction (TCP-FEC). The performance of TCP can be sig-nificantly improved by generating and sending redundant segments in addition to the normal TCP data segments. Data losses in the network can be recovered from the redundant or the original data packets. Ad-ditionally by adding correcting codes to the TCP transmissions, both isolated and some degree of bursty losses can be handled. The ad-vantage for the application is that the long retransmission times can be avoided if the repair can be done locally. The advantage for the network is two-fold, excessive retransmissions do not further congest the network and wireless losses can be repaired at the receiver. This technical report details TCP-FEC from a design, migration and pro-tocol perspective in the highly heterogeneous wireless environments envisaged by the sixth framework Ambient Networks project1.
1
Introduction
The TCP protocol is known to have problems in highly heterogeneous en-vironments, particularly those with wireless hops. However no alternative to TCP has been too successful in establishing itself as the dominant trans-port protocol in wireless environments, particularly cellular ones. One of the reasons is performance, losses cause significant reductions in the transmis-sion rate, making tasks such as web browsing or email impossibly slow. One other issue is interoperability, TCP has become the only reliable transport protocol where IP is concerned, and solutions that don’t follow the TCP semantics will need some form of split-connection or kludge to inter-operate with TCP. Numerous solutions have been proposed, but none very widely adopted. Therefore, if errors can be recovered without needing retransmis-sions, and the solution is inter-operable with TCP a standard could be set. The network will be able to transfer data faster and with less delay. Also it will be more stable, controllable and ongoing flows can be protected from spurious losses. One relatively new and promising approach is provide end-to-end protection of flows by transmitting redundant packets in the hope that many of the retransmissions will not be needed. This method has been used successfully at the link layer, but its introduction in the transport layer is relatively new.
The focus of this work has been the evaluation of different TCPs with forward error correction. The main goal has been to ascertain if TCP-FEC is indeed suitable for Ambient Networks as a congestion control mechanism. Within the next sections we show that indeed, this type of scheme is well suited to the demanding needs of an ambient network.
2
TCP-FEC in ambient networks
2.1
Advantages
The throughput of TCP is, and should be, a fundamental issue within the design of any IP network. For the type of networks targeted by the Ambient project [1] the throughput is especially important due to the property of smaller, separate networks composing into single, larger entities. For example a personal area network could compose with a wireless LAN home network, forming a single administrative entity. If TCP is to run end-to-end in these kind of environments then it needs to be able to cope with the dynamic of the network as proposed by the Ambient networks project.
trans-mitted across the network as few times as possible, ideally only once. It is better to send extra data initially, than to have the need to resend it, pos-sibly multiple times. This will surely help avoid congestion situations, the major factor in network performance. Taking this principle one step further, it is possible to say that, once admitted into the network, the flow should be serviced as quickly as possible and then not seen again. Too many long-lived flows with a few bytes left to transmit are disastrous for the performance of any network. Therefore TCP-FEC is used to protect on-going flows by regulating the amount of data and redundancy in order to allow the flow in, protect it and then remove it. This is not an easy mechanism to implement with existing approaches, because there is not sufficient flexibility in most protocol designs. Therefore the goal of TCP with added forward error cor-rection, is to improve the throughput of the longer-lived flows, but not the ones with one or two round-trip TCP transmissions, often associated with short downloads. In many of these cases, TCP never leaves the slow-start phase and TCP-FEC is not particularly useful.
Another benefit of TCP-FEC from an Ambient Networks perspective is that the throughput of TCP can be improved by protecting the important packets and not reducing the sending rate for the wrong reasons. TCP must be aware of congestion in the network, but only when true congestion is encountered and not spurious wireless losses. The ability of TCP-FEC to cover both these situations is quite unique. Many of the previous efforts (as described in the TCP section) have tried to identify which case is the most likely and take preventative action. TCP-FEC can actually cope with both of these, particularly if TCP-SACK or ECN is used to indicate which segments (bytes) were lost.
A third advantage is that no extra functionality from the Ambient infras-tructure is needed. TCP-FEC is self-contained. The nature of the end-to-end operation of TCP allows the characteristics of each path to be determined within a few round trips. In fact, it is an advantage that TCP-FEC finds its operating point itself, although as we will see later some information can be usefully used by the TCP-FEC mechanism. That said, information about the network state can be incorporated into TCP-FEC, however it is not mandatory.
2.2
Ambient applications
A technical scenarios document [41] describes six situations that the conges-tion control of Ambient networks should address. They include extremely short-lived composition for burst-like transfer, multi-homing, handovers and handoffs, heterogeneous partially AN-opaque transfer paths, non-participating
endpoints or non-conformant protocols and mobile networks. The applica-tion of TCP-FEC fits best in the mobile network scenario, where the network scenario in this case is envisaged to be a train. TCP-FEC is well suited to this application for a number of reasons, firstly packet losses as seen by an application in this type of environment are likely to be highly dynamic. More concretely, losses in a stationary position tend to be more correlated (with each other) than those observed whilst the train is moving (we are assuming communication is outside of the train in these cases). If the train is sta-tionary and then starts moving, the loss process may well be correlated in some respect with the trains speed. TCP-FEC can adapt to this situation well, series of losses can be repaired (in the correlated loss sense) and single sporadic losses can be dealt with (in the non-correlated sense).
Typically as a train moves into a station, people begin to communicate and congestion situations may occur. In this case they could well be com-municating with an access point installed in the station or with one inside the train, however whether the TCP connections are local to the train and one aggregated ’pipe’ is available to the outside or micro-flows exist from the train to the outside is not important to TCP-FEC. The traffic will have different patterns, depending on which one of these is used, but a scheme such as the one proposed in this approach is flexible enough to cope with most cases. In fact, it highlights the functionality and flexibility of a scheme like TCP-FEC, hence this scenario is the most relevant of the six described.
3
Background
The following two sections give some background on TCP and some of the approaches presented to solving this problem. FEC is discussed next, and how it is used in communication networks Since TCP-FEC is actually a combination of networking technology and channel coding, there are many related works, however we have tried to focus on some of the key ones. Also, where relevant, the differences and similarities with TCP-FEC are given. This section can also be seen as a related work section, as even more references are given than are actually cited, should the reader require further material not discussed in this text.
3.1
TCP
TCP is a connection-oriented transport protocol that offers a reliable byte stream service to the application. Data to be sent by an application is, if need be, broken into ’segments’ before they are sent. For forward error correction
this is important as the TCP segments are used to create the redundancy data and the extra packets. In TCP, each byte is numbered, and the first byte is used as a sequence number. The numbers may not necessarily begin from one, but they are monotonically increasing with the number of bytes transmitted. Again this is important for FEC as the receiver can establish which of the segments is lost. The receiver transmits a cumulative acknowledgment of the bytes received, by indicating which the number of the highest byte seen
in order, commonly known as a TCP acknowledgment, or ’ack’. The true
end-to-end nature of TCP can be seen in this simple exchange,
In order to detect loss, TCP manages a timer, called the retransmission timer (RTO) that is started when a segment is sent. If the timer expires before the segment is acknowledged, the segment is retransmitted. The RTO timer is calibrated from estimates of the round trip time (RTT). Again this is important in the context of TCP-FEC, as in the worst case the receiver must wait for the RTO timer to expire before the segment can be retransmitted (a one-way transmission plus the timer). In the case of fast recovery, noticed by acknowledgments of the same data sequence, it “only” takes the one-way transmission time. If the data can be recovered at the receiver from the packets received, these times can be neglected. Therefore one can see TCP-FEC as a method for reducing the delay in the transfer of data.
Since 1986 TCP has had mandatory congestion control primarily due to a congestion collapse in the Internetin 1986 [42]. The terms used in congestion control are slow start, congestion avoidance, fast retransmit and fast recovery. The transmission rate of TCP is controlled by its window size changes. Note this is not the rate as seen by the network or the receiver, rather the number of segments that can be injected into the network, more specifically it is the number of outstanding (or unacknowledged) segments. It is also TCP’s method of estimating the capacity of the network. This is done by increasing the number of outstanding segments, the cwnd variable (shown on the y-axis of figure 3.1) limits this number. The initial number is set between one and four. The sender also considers an advertised receiver window (rwnd), as exchanged in the setup phase of TCP, from the receiver as well and actually injects the minimum of these two quantities into the network at any one time. The receiver window, rwnd, is used to stop the end terminal from being overrun by overly aggressive senders. This can occur on networks with lower capacities closer to the receiver than the sender.
In the slow start phase, the congestion window is increased by one seg-ment for each acknowledgseg-ment received, which (as can be seen) gives an exponential increase in the window size. Slow start is so named as it starts from a small number of outstanding segments, however the growth of the window is anything but slow. As stated earlier, slow start is used at the
beginning of transmissions, it is not envisaged to employ TCP-FEC in this phase2. However, if a timeout is experienced, slow start is initiated. The
congestion window is increased until either a timeout occurs, or a thresh-old value (ssthresh) is reached. Both these cases are shown in the figure for illustration. timeout 0 2 4 6 8 12 10 14 16 18 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 cwnd (segments) ssthresh ssthresh round−trip times
Figure 1: TCP congestion window behavior showing the effect of packet loss
If ssthresh is reached, TCP moves from slow start to congestion avoidance. In this phase the congestion window is increased by one for each round-trip time. This gives a linear increase in the window size. If a timeout occurs then ssthresh is halved to limit the amount of outstanding data from 20 to 10 in this case. In the figure the sender window size goes through slow start to congestion avoidance, packet loss, timeout, and slow start and congestion avoidance again. Note this example of the behavior of the congestion window does not necessarily represent the throughout seen by the receiver. Due to buffering in the routers and the transmission times, the rate might be observed more stable. In the upcoming text, we will see mechanisms for repairing the lost data more quickly and hence maintaining the throughput or ’good-put’ as it is sometimes referred for the receiver.
There are approaches for repairing loss(es) before the timeout occurs. They are known as fast retransmit and recovery algorithms. Their purpose is keep the throughput as constant as before a packet loss (and subsequent timeout).
If a segment arrives out of order, the receiver transmits an acknowledg-ment for the last segacknowledg-ment it received with the sequence number for the bytes is has received in order. This acknowledgment contains a sequence number that is identical to the previous acknowledgment therefore is called a
dupli-cate acknowledgment. If the sender sees three duplidupli-cate acknowledgments
then the sender immediately retransmits the segment that directly followed the sequence number seen in the acknowledgments, assuming one segment was lost. This saves time by not waiting for the retransmission timer to expire. This major change to TCP, is essentially the difference between so called TCP Tahoe and TCP Reno, where Reno includes the fast recovery and retransmit algorithm. Note that the scheme can only account for a sin-gle segment in the same window, if more than one segment is lost this process has to be repeated. Again TCP-FEC could react to this situation by when the sender uses the fast retransmit scheme, it could increase the amount of redundancy or at least note that losses are occurring within the network. Therefore some new options were introduced into TCP-SACK. Should multi-ple segments be lost in the same window, TCP-SACK can acknowledge up to three non-continuous blocks of received bytes in the same acknowledgment. The sender then knows which segments are missing and has the possibil-ity to retransmit these. Timestamps provides additional means to identify segments and their acknowledgments. A 12 byte timestamp is added to the outgoing segments and the receiver adds the same timestamp to the acknowl-edgments going back to the sender. If the option is enabled, the sender can sample the round trip time with a higher frequency, giving a more accu-rate round trip time estimation. Other mechanisms include window scaling [43], limited transport [44] and increased initial window [45]. TCP-SACK is seen as one of the better choices for wireless transmissions due to the fea-tures described above (particularly handling more than one loss segment in a window).
Three main TCP variants have been discussed Tahoe, Reno and TCP-SACK. Tahoe is the original BSD 4.4 implementation, including congestion control by Jacobson. As stated Fast retransmit and recovery are known as Reno. TCP New Reno which was not discussed adds to TCP Reno by chang-ing some thresholds in the fast recovery algorithm and avoidchang-ing a scenario where multiple retransmits can occur after a timeout. Apart from this it is essentially the same and no new functionality has been added. TCP-SACK one of the more modern variants is seen as an improvement over the previous versions, even though Reno and NewReno are still the most widely deployed.
3.2
Other TCP-based end-to-end approaches
Wireless networks pose problems for TCP. The main problem is differen-tiating losses caused by congestion and wireless effects. Also sudden large increases in the delay can occur, this can also be interpreted as loss, as the retransmission timer expires before the acknowledgment is received. The de-layed data is unnecessarily retransmitted and TCP enters slow start. Highly varying RTTs can lead to a large retransmission timer, since the retransmis-sion timer is based on both estimates of the RTT and its variations. In the next paragraphs we will discuss some of the alternatives and additions to the TCP protocol in order to make it more suitable for wireless networking. We discuss three methods that use information from the link layers and the transport/networking layers.
One approach is to make use of link layer optimizations to improve the performance of TCP. Snoop [46] uses link layer retransmissions and is im-plemented as an agent in the base station. It caches link layer frames and only looks at TCP headers, therefore a full TCP implementation is not nec-essary. A link layer retransmission is performed from the base station after a link layer timeout or a duplicate ack is seen from the mobile station, as-suming it is the receiver of course. Further duplicate acknowledgments are discarded by the base station in order to prevent the sender from performing fast retransmit and recovery. WTCP [47] is similar to Snoop in that it uses duplicate acknowledgments and link layer timeouts to detect lost segments on the wireless link. However, it also uses the timestamps option to limit the outstanding data over the wireless links. The base station increments the timestamp field in the TCP header for each retransmission that is needed with the purpose of obtaining a more accurate RTT estimate. Acknowledg-ments from the mobile node are not changed by the base station. After a timeout, WTCP is more conservative than Snoop as it only allows one out-standing segment on the wireless link assuming it is in a bad state. Once acknowledgments come back to the base station again, the link is assumed to be in a better state and the limit on the outstanding data is set to the receiver window. TCP-FEC tries to guess the number of losses from the missing ac-knowledgments and adjusts the amount of correction to compensate for this. Note FEC can be applied on a link layer level too, and this is not in mutually exclusive with TCP-FEC. In fact, TCP-FEC can use this information to as-certain when link-layer FEC failed to adjust its level of redundancy correctly, assuming that it is only this particular link that is troublesome. TULIP [48] is one scheme that does not use information from the transport level, how-ever uses the networking layer (IP) and provides a reliable service for TCP segments. Note it does not for the TCP acknowledgments or UDP traffic.
Since TCP-FEC lives ’underneath’ TCP, TULIP has the same objectives as TCP-FEC, except that it is applied end to end.
The link layer improvements try to improve the performance of TCP at the lower layers, assisting TCP by trying to alleviate the need for retrans-missions end to end. They all preserve the end to end semantics of TCP, but note that the data and acknowledgments must pass through the same base station. One method to deal with the losses being for different reasons on fixed and wireless networks, is to split the connection and use two separate connections end to end. In these cases the TCP semantics are not preserved. One option is to use a modified TCP over the wireless link, and an unmod-ified version over the fixed network. Various methods exist, the first we will consider is known as Indirect TCP or I-TCP [49]. It is intended for WLANs with mobility support at the IP level. When the mobile node moves and a handover occurs, new TCP state is transferred to the new base station and the retransmission timer is reset. The main saving by using this approach is that the round trip times are shorter and therefore the TCP sender in the base station can recover faster to data loss. Note that is almost a classic split connection technique, two separate feedback loops exist, however in the case of mobility management, the goal of this paper, there is little choice. It is in-teresting to note if the packet loss rate is low, the throughput would be lower in this situation. TCP-FEC has this tunable feature, it can act as a normal TCP over the wireless path or even exist on top of a link layer reliability mechanism. I-TCP is rather a static solution to a practical problem.
Two other alternatives that exist are MTCP and the selective repeat protocol (SRP) [58]. Again, after a handover, TCP states are moved to the new base station. MTCP uses standard TCP over the wireless and wired links as one alternative or a selective repeat protocol is employed over the wireless link. SRP is a UDP-based protocol that performs flow and error control. It can recover more than one segment for each RTT as it uses selective acknowledgments. If load is not the problem on the wireless link, then TCP-FEC can be used as an alternative to SRP, depending on the losses and coding all of the lost segments can be recovered. Note also it is possible to use TCP-FEC and TCP as a split combination. This is a similar idea to using link-layer FEC except it is handled at the transport layer, also marrying the split TCPs is easier from a protocol perspective if TCP is used over the wireless link.
Other alternatives include using methods to indicate to the sender that losses are wireless losses and not are due to congestion, these are known as explicit notification methods. One simple method is to use ICMP messaging to notify the sender. The intermediate node between the wired and wireless links generates explicit notifications. A new ICMP type, ICMP-DEFER, is
used in the method proposed in [50]. If data is lost over the wireless network an ICMP-DEFER is sent to the receiver, postponing the expiration of the retransmission timer. This avoids conflicts between the link-layer retransmis-sions at the base station and the end-to-end retransmisretransmis-sions. If a segment needs to be retransmitted, and an ICMP-DEFER has been received then the
cwnd is not reduced at the sender. This indicates the loss was not due to
congestion but to wireless conditions. The scheme can be further improved by adding another ICMP message, ICMP-RETRANSMISSION. The base station transmits an ICMP-RETRANSMISSION to the TCP sender when the maximum number of retransmission attempts is reached and the packet is discarded. This explicitly says that the loss was due to the link layer performance and/or situations just now. Note normal TCP has little option in this kind of situation to do anything except reduce its rate and wait for better times. TCP-FEC however, can add more protection to the data, in the event that the receiver can make use of the received packets. Different codings can be used, or even experimented until the best operating point is reached. There is one further advantage by continuously sending data even if some of it is discarded, an accurate picture of the network conditions is available to the receiver and the sender. Also in an Ambient scenario, if feedback is possible as in this situation, then the amount of redundancy can be quickly determined.
Explicit loss notification (ELN) can be used if the mobile node is the sender [51]. If a segment is lost over the wireless link, notification can be sent to the sender in the form of an ELN. The base station keeps track of the sequence numbers, where holes indicate losses. The receiver sends back a duplicate acknowledgment as normal, and the base station sets an ELN flag in the acknowledgment header before it is forwarded to the mobile station. The mobile station then retransmits the lost segment but does not reduce its congestion window. TCP-FEC could also use ELN, it is worthwhile for the sender to know whether losses are due to congestion or wireless artifacts. In the case of wireless losses, the amount of redundancy doesn’t need to be reduced. In the case of congestion, then the rate should probably be lowered, at least.
Syndrome [52] is a modification of the base station to enable detection of packet losses over the wireless link. The base station counts the number of packets it relays and includes this counter in the TCP header as one of the TCP option fields. This counter is known as a “syndrome” and is used together with the sequence number. If there is a gap in the syndrome counter, then packets were lost on the wireless link. However gaps in the sequence number and not in syndrome indicate losses on the fixed part of the network. Explicit loss notification is used by the receiver to inform the sender about
the losses.
One other method to distinguish congestion from data loss is to use new types of acknowledgments. In [53] the authors propose a new type of acknowl-edgment known as a partial acknowlacknowl-edgment. The base station transmits this type in response to data sent from a sender who is in the fixed network. If not segments are lost, the receiver receives two types of acknowledgments, one partial from the base station and one full one from the receiver. If only the partial arrives, the sender can conclude that the data must be lost over the wireless network and no congestion control is required. If no acknowl-edgments arrive, the most likely cause is data lost to congestion. A similar approach is given in [59] with two new partial acknowledgments.
Alternative end to end schemes include TCP Westwood, which is a sender side control algorithm implemented within TCP Reno. Instead of relying on slowly probing the available bandwidth until segments are dropped, the rate of incoming acknowledgments is used to determine the available bandwidth. TCP Westwood has been shown to give improvements over wireless links since error recovery is faster than in standard TCP. The bandwidth estimation is also considered when values for cwnd and ssthresh are computed after each data loss. WTCP as discussed earlier, also uses a rate-based approach to control the number of transmissions. Inter-packet separations at the sender and receiver are used as a metric for calculating the transmission rate. TCP Real is another rate-based scheme in which the receiver is responsible for controlling the transmission rate at the sender [54]. The receiver uses changes in the rate of incoming segments to compute the congestion window the sender should use. If the rate of incoming segments is decreasing, this is taken as an indication of increasing load and therefore cwnd should be decreased, in the case of loss, cwnd is adjusted sooner than with standard TCP as the receiver includes estimates of the cwnd in the acknowledgments back to the sender. Other schemes exist that share some of the features described and include Freeze-TCP, Delayed dup-ack and Eifel [55, 56, 57]. Finally interleaving is an alternative to both TCP ARQ and FEC over wireless links, data is shuffled to mix data from different users. Hence, if losses/errors arrive in bursts they are spread out. It can be useful on its own if the application can tolerate uncorrelated losses better than correlated, but mainly it is a complement to FEC in order to make it more efficient.
3.3
FEC
Forward error correction3 is the process of adding redundant information to
a data stream allowing some statistical certainty of being able to recover the original data stream even with some loss. Assuming sufficient data is available, and the coding scheme is robust enough, the original data can be recovered. Forward error correction does not stipulate how the data should be protected and a number of different schemes exist. In this work we are interested in block coding, that is storing (actually copying) a number of packets before redundant data is generated. Note the original data is not changed when creating the extra redundant information.
A longitudinal redundancy check (LRC) or horizontal redundancy check (HRC) is a form of redundancy based on the formation of a new code. A simple example is given to show the process, in the case of single characters, the block check formation rules are applied in the same manner to each char-acter. A combination of longitudinal and vertical redundancy checks allows the detection and correction of single bit errors. A LRC XOR specifies that corresponding bits of the LRC and the input characters should be exclusive-or’ed together and the resultant bit values should become the values of the corresponding bits in the result. This concept can be extended to using so called ’symbols’ instead of characters, bits etc. so that the unit of encoding is independent of the data type chosen. Vertical coding is chosen within TCP-FEC, which means that the first symbol from the data packets is represented in the first symbol in the redundant packet. The redundant packet will be the same length as the data packets, this also means that the data packets should be the same length. Reed-Solomon is an alternative method to parity checks which we will discuss later.
3.4
TCP and FEC
End to end error correction has been investigated in the networking commu-nity [2, 5, 60, 9]. In [2] they have proposed, implemented and evaluated some of the design issues with TCP-FEC. This work has also been extended to us-ing TCP-FEC as a method of differentiatus-ing quality of service between elastic (TCP) and non-elastic flows. In [5] the authors use mathematical modeling to analyse the benefit of using a hybrid version of FEC and ARQ-SR. FEC consumes extra bandwidth, but ARQ-SR takes extra round trip times so a hybrid is reasonable. Their findings are that for long-lived TCP transfers ARQ-SR is good for Bernoulli-type errors and FEC is better for higher error
3Backward error correction is the process of repairing losses by retransmissions, or an
rates. In [9] they study the tradeoff between the bandwidth consumed by FEC and that gained by TCP.
Two tradeoffs are available when controlling the redundancy for TCP sessions and ultimately how the network is operated. This is important in an Ambient scenario, not just the train case, but more generally. In an ambient networks setting some control of the network might be possible, unlike the uncontrolled Internet. At the cost of a higher network load as redundancy is added will hopefully reduce the number of retransmissions. This will benefit the application both in terms of delay and throughput, but can penalize the network. The amount of redundancy is dependent on the characteristics of the network and the performance of the FEC algorithm. Another alternative is reducing the throughput of the application by using some of its capacity for the redundancy packets, if successful the delay should be improved by involving fewer retransmissions, however the application can be penalized by a lower throughput.
Receiver
4
ACK ACK ACK
3 2 1 43 2
1 Sender
There are a number of methods for finding the number of redundancy packets. One method to find this R as function of the bandwidth estimation
BW E the number of data packets K, the RT T and the loss probability P
is R = f (BW E, K, RT T, P ). Further options are available if additional in-formation can be exchanged using Explicit Congestion Notification (ECN) to inform the sender about TCP-FEC corrected errors. How these are inter-preted is a decision of the algorithm. One option is to lower the rate (or the redundancy) as potentially TCP-FEC is contributing to the network load. Only by the receiver stating which packets were repaired can this information be established. An alternative is to use and adapt the error control in order to try and minimize the losses reported by ECN.
It is not a surprise that the algorithm should adapt to the network, as is the case for channel coding, where FEC mechanisms are widely deployed adapt to the bit errors on the channel. In end to end packet transmissions the important available tunable parameters are the length of the block to code and the number of redundancy packets. The length of the block to code depends somewhat on the current congestion window of TCP (how many packets can be sent in one round trip). How this is dealt with is described
more in the next section. The second tunable parameter is the number of redundant packets sent, this is purely a decision of the algorithm, within the confines of the operating points of the network of course. Normally the choice is made to achieve a certain loss percentage after the packets have been decoded. This can be formulated as an ’acceptable loss level’.
4
Implementation
As mentioned the error correction is ’included’ as part of the TCP implemen-tation, so the interface can be minimal as seen from the exterior. It is possible to implement FEC ’above’ or ’below’ TCP. In this approach FEC is imple-mented under TCP making it appear that TCP is working on network with better loss characteristics. Implementing FEC above TCP has been looked at by [34]. Within the TCP implementation itself packet loss observed by the receiver is, via acknowledgments, fed back to the sender. Using knowledge of the losses, redundancy can be added to subsequent transmissions to repair future lost TCP segments.
As stated the FEC module sits under the network-layer TCP protocol implementation. That is, TCP hands the segment to the FEC module and given loss information, the segment is coded with extra data and added to the TCP segment. A TCP header extension is used to indicate which segments contain extra data. Reed-Solomon coding is the one suggested in this work, that is because if the position of the loss is known, Reed-Solomon coding can protect against more losses than a given lost. In coding terms these loss events are known as ’erasures’. Polynomial or algebraic codes are used. In the implementation chosen, the sender does not need to wait to create the redundancy packets. Each outgoing packet is simply copied and from those the redundancy is generated. Ideally this should be as fast as possible so that the receiver does not need to wait too long should the redundant packet be needed. The receiver needs to buffer extra packets in order to hold the segments in case a lost packet needs to be regenerated.
5
Deployment
5.1
In ambient networks
There are two options for deploying TCP-FEC in an Ambient network. One is for Ambient network in which case a new TCP could exist, for example TCP-Amb, which is purely used in Ambient networks. On the border to
traditional IP networks the FEC packets could be removed (by the NBP for example).
5.2
In the Internet
TCP-FEC can be implemented with the help of ECN enabled in the routers without any modifications to the currently deployed implementations. One would use a different application socket call or ioctl() to enable the TCP-FEC. For testing it is useful to have TCP-FEC and TCP operational for performance comparison. An alternative would be to add the functionality to an existing TCP (TCP-Reno is the most deployed currently) and TCP-FEC would operate as if it was vanilla TCP. In a totally integrated version, the TCP layer would intercept the application to IP protocol interaction, adding FEC where losses are observed and correctable. Finally the semantics do not change for the application, only the application sees a TCP with a lower delay, as there are fewer retransmissions.
Exactly how to find the correct operating values for TCP-FEC initially is still an open issue. However this is not as big drawback as it seems, sit-uations change rapidly in our considered scenario and TCP-FEC can adapt rapidly to a particular path. So even with ’informed’ starting conditions, TCP-FEC (or even TCP) would need to observe for itself the loss character-istics. In the Ambient scenario, if information is available to the end systems, TCP-FEC can take advantage of this. Useful information might be to know of bandwidth constrained links so that TCP-FEC never adds that much re-dundancy to induce losses itself. One FEC issue is the choice of segment sizes, it is assumed that all segments are maximum length, in the case this is not true they can be padded before redundancy coding is applied, however this is internal to the TCP implementation and shouldn’t be a problem for the network as a whole. These will be addressed in the final version of the technical document.
6
Conclusion
Modifying TCP to include extra protection has been dealt with in this report. Including protective measures to TCP is not trivial due to the window-based congestion control of TCP, but it is possible with significant savings in terms of the number of retransmissions needed. This document described some of the protocol issues by using this approach to improving TCP and TCP’s congestion control. Evaluation and validations will be available in the next release of this document.
References
[1] WWI Ambient Networks.
[2] Henrik Lundqvist, Gunnar Karlsson, ”TCP with End-to-End Forward Error Correction”, Technical Report, TRITA-IMIT-LCN R 03:03, ISSN 1651-7717, ISRN KTH/IMIT/LCN/R-03/03-SE, KTH, Royal Institute of Technology, Sweden.
[3] M. Allman, D. Glover, L.Sanchez, ” Enhancing TCP Over Satellite Channels using Standard Mechanisms”, BCP 28, RFC 2488, Jan. 1999. [4] E. Altman, A. Jean-Marie, ”Loss Probabilities for Messages with Re-dundant Packets Feeding a Finite Buffer”, IEEE Journal on Selected Areas in Communications, vol. 16, no. 5, June 1998.
[5] E. Ayanoglu, R. Gitlin, N. Cem Oguz, ”Performance Improvement in Broadband Networks using Forward Error Correction for Lost Packet Recovery”, Jour. of High Speed Networks, vol. 2, 1993, pp. 287-304. [6] E. Ayanoglu, S.Paul, T.F. LaPorta, K. K. Sabnani, R.D. Gitlin,
”AIR-MAIL: A link-layer protocol for wireless networks”, ACM ACM/Baltzer WirelessNetworks J., vol. 1, pp. 47-60, Feb. 1995.
[7] D.S. Bakin, M. Joa-Ng, A.J. McAuley, ”Quantifying TCP Performance Improvements in Noisy Environments Using Protocol Boosters”, Com-puters and Communications, 2000. Proceedings. ISCC 2000. Fifth IEEE Symposium on , 2000.
[8] H. Balakrishnan, V.N Padmanabhan, S. Seshan, R.H. Katz, ”A Com-parison of Mechanisms for Improving TCP Performance over Wireless Links”, IEEE/ACM Trans. On Networking, vol. 5, no. 6, Dec. 1997. [9] Chadi Barakat, Eitan Altman, ”Bandwidth tradeoff between TCP and
link-level FEC”, Computer Networks, vol. 39, no. 2, pp. 133-150, June 2002.
[10] J.-C. Bolot, ”End-to-End Packet Delay and Loss Behaviour in the In-ternet”, Proc. SIGCOMM’93, Pages 289 - 298, Sept. 1993.
[11] M. S. Borella, ”Measurement and Interpretation of Internet Packet Loss”, Journal of Communication and Networks, Vol. 2, No. 2, June2 000.
[12] L. Brakmo, L. Peterson, ”TCP Vegas: End to End Congestion Avoid-ance on a Global Internet”, IEEE JSAC, Vol. 13, No. 8, Oct 1995. [13] J. W. Byers, M. Luby, M. Mitzenmacher, A. Rege, ”A Digital Fountain
Approach to Reliable Distribution of Bulk Data”, Proceedings of ACM SIGCOMM’98, Vancouver, 1998.
[14] J. Cao, K. Ramanan, ”A Poisson Limit for Buffer Overflow Probabili-ties”, IEEE Infocom 2002.
[15] G. Carle, E. Biersack, ”Survey of Error Recovery Techniques for IP-Based Audio-Visual Multicast Applications”, IEEE Network, Vol. 11, Issue 6, Nov.-Dec. 1997, pp. 24-36.
[16] I. Cidon, A. Khamisy, M. Sidi, ”Analysis of Packet Loss Processes in High-Speed Networks”, IEEE Trans. on Inf. Theory, vol. 39, no. 1,J anuary 1993.
[17] A. DeSimone, M. C. Chuah, O-C. Yue, ”Throughput Perfoemance of Transport-Layer Protocols over Wireless LANs”, IEEE Globecom’93, pp 542-549, vol. 1, 1993.
[18] S. Floyd, T. Henderson, ”The NewReno Modification to TCP’s Fast Recovery Algorithm”, RFC2582, Apr. 1999.
[19] A. Goel, C. Krasic, K. Li, J. Walpole, ”Supporting low latency TCP-based media streams”, In Proceedings of the Tenth International Work-shop on Quality of Service (IWQoS), May 2002.
[20] B. Hochwald, K. Zeger, ”Tradeoff Between Source and Channel Coding”, IEEE Trans. On Inf Theory, vol. 43, no. 5, Sept 1997.
[21] C. Huitema, ”The Case for packet level FEC”, Proc. 5th Workshop on Protocols for High Speed Networks, pp. 109-120, Sophia Antipolis, France, Oct. 1996.
[22] V. Jacobson, ”Congestion Avoidance and Control”, in Proc. SIGCOMM ’88 Symp., Aug. 1988, pp. 314-329.
[23] H. Jin, A. Khandekar, R. McEliece, ”Irregular Repeat-Accumulate Codes”, Proceedings 2nd International Symposium on Turbo codes and Related Topics, Brest, France, Sept. 4, 2000. pp. 1-8.
[24] D. Katabi, M. Handley, C. Rohrs, ”Congestion Control for High Bandwidth-Delay Product Networks”, ACM SIGCOMM’02,P ittsburgh, 2002.
[25] L. Massouli, J. Roberts, ”Arguments in favour of admission control for TCP flows”, In: Teletraffic Engineering in a Competitive World - Proc. ITC 16, Edinburgh. Eds. D. Smith and P. Key. Elsevier, Amsterdam (1999), 33-44.
[26] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, ”TCP Selective Acknowledgement Options”, RFC 2018, Oct. 1996.
[27] A. McAuley, ”Reliable Broadband Communication using a Burst Era-sure Correcting Code”, Proc. SIGCOMM ’90, Philadelphia, PA, Sept. 1990, pp. 287-306.
[28] The UCB/LBNL/VINT Network Simulator (NS). URL: ”http://www-mash.cs.berkeley.edu/ns/”.
[29] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, ”Modeling TCP Reno Per-formance: A Simple Model and Its Empirical Validation”, IEEE/ACM Trans. On Networking, Vol. 8, no. 2, April 2000.
[30] V. Paxson, ”Measurements and Analysis of End-to-End Internet Dy-namics”, PhD thesis, University of California, Berkeley, April 1997. [31] V.Paxson, M. Allman, ”Computing TCP’s Retransmission Timer”, RFC
2988, November 2000
[32] L. Peterson, B. Davie, ”Computer Networks: a systems approach”, Mor-gan Kaufmann, 1996.
[33] K. K. Ramakrishnan, S. Floyd, D. Black, ”The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, Proposed Standard,S eptember 2001.
[34] L. Rizzo, ”On the Feasibility of Software FEC”, DEIT Technical Report LR-970131. URL: ”http://www.iet.unipi.it/ luigi/softfec.ps”.
[35] J. H. Saltzer, D.P. Reed, D.D. Clark, ”End-to-End Arguments in Sys-tem Design”, ACM Transactions on Computer Science, pages 277-288, November 1984.
[36] N. Schacham, P. McKenney, ”Packet recovery in high-speed networks using coding and buffer management”, Proc. IEEE Infocom ’90, pp. 124-131, May 1990.
[37] T. Tuan, K. Park, ”Multiple Time Scale Redundancy Control for QoS-sensitve Transport of Real-time Traffic”, INFOCOM 2000. Proceedings. IEEE Volume: 3, 2000 , Page(s): 1683 -1692 vol.3.
[38] L. Wilhelmsson, L. B. Milstein, ”On the Effect of Imperfect Interleaving for the Gilbert Elliott Channel”, IEEE Trans on Communications, vol. 47, no. 5, pp. 681-688, May 1999.
[39] M. Yajnik, J. Kurose, D. Towsley, ”Packet Loss Correlation in the MBone Multicast Network”, GLOBECOM ’96, 1996 , Page(s): 94 99. [40] M. Zorzi, R.R. Rao, L.B. Milstein, ”ARQ error control for fading mobile
radio channels”, IEEE Trans. Veh. Tech., vol. 46, pp. 445- 455, May 1997.
[41] Task 3.3 Draft Scenario(s) Ambient Networks internal publication. [42] M. Allman, V. Paxson, W. Stevens. RFC 2581: TCP Congestion control.
April 1999.
[43] V. Jacobson, R. Braden, and D. Borman. RFC 1323: TCP extensions for high performance, May 1992.
[44] M. Allman, H. Balakrishnan, and S. Floyd. RFC 3042: Enhancing TCP’s loss recovery using limited transport, January 2001.
[45] M. Allman, S. Floyd and C.Partridge RFC 3390: Increasing TCP’s ini-tial window, August 2002.
[46] H. Balakrishnan, S. Seshan and R. H. Katz. Improving reliable transport and handoff performance in cellular wireless networks. ACM Wireless Networks, 1(4), December 1995.
[47] K. Ratnam and I. Matta. WTCP: An efficient transmission control pro-tocol for networks with wireless links. In Proceedings of the third IEEE symposium on computers and Communications (ISCC ’98), Athens, Greece, June 1998.
[48] C. Parsa and J. Garcia-Luna-Aceves. Improving TCP performance over wireless networks at the link layer. ACM Mobile Networks and Applica-tions Journal, vol 5, issue 1, 2000.
[49] A. V. Bakre and B. Badrinath. Implementation and performance evalu-ation of Indirect TCP. IEEE Transactions on Computers, 46(3), March 1997.
[50] S. Goel and D. Sanghi. Improving TCP performance over wireless links. Proceedings of TENCOM 98 - IEEE Region Ten Conference on Global Connectivity in Energy, Computer Communication and Control, 1998. [51] H. Balakrishnan and R. Katz. Explicit loss notification and wireless
web performance. In Proceedings Globecom Internet Mini-Conference, Sydney, Australia, November 1998.
[52] W.P. Chen Y.C. Hsiao. J.C. Hou. Y. Ge and M.P. Fitz. Syndrome: a light-weight approach to improving TCP performance in mobile wireless networks. Wireless Communications and Mobile Computing, (2):37-57, 2002.
[53] S. Biaz, M. Mehta, S. West and N. H. Vaidya. TCP over wireless net-works using multiple acknowledgments. Technical report 97-001. Com-puter Science, Texas A & M University, January 1997.
[54] C. Zhang and V. Tsaoussidis. TCP Real: Improving real-time capa-bilities of TCP over heterogenous networks. Proceedings of the 11th IEEE/ACM NOSSDAV 2001.
[55] T. Goff, J. Moronski, D. Phatak and V. V. Gupta. Freeze-TCP: A true end-to-end enhancement mechanism for mobile environments. In Pro-ceedings of IEEE Infocom, Marc 2000.
[56] N. Vaidya, M. Mehta, C. Perkins and G. Montenegro. Delayed duplicate acknowledgments: A TCP-unaware approach to improve performance of TCP over wireless. Technical Report, Computer Science Dept, Texas A & M University, February 1999
[57] R. Ludwig and R. H. Katz. The Eifel Algorithm: Making TCP robust against spurious retransmissions. ACM Computer Communication Re-view. 30(1):30-37, January 2000.
[58] R. Yavatkar and N. Bhagwat. Improving end-to-end performance of TCP over mobile internetworks. Workshop on Mobile Computing Systems and Applications (Mobile 94), December 1994.
[59] J. A. Cobb and P. Agrawal. Congestion or corruption? A strategy for efficient wireless TCP sessions. IEEE Symposium on Computers and Communications, Alexandria, Egypt, 1995.
[60] C. Barakat and A. Al Fawal. Anlaysis of link-level ybrid FEC/ARQ-SR for wireless links and long-lived TCP traffic. Performance Evaluation Journal, vol. 57, no. 4, pp. 423-500, August 2004.
