ISBN: 0-471-41405 -0
Download (direct link):
Resending Lost Packets
Packets that travel over any network (not only the wireless ones) will occasionally be lost along the way. This can be due to overloaded routers or just physical disturbances in the transmission. TCP provides a means for overcoming this problem by resending packets that are lost or severely delayed. Timeouts and packet acknowledgements help track the losses of packets. As we saw in the previous example of establishing a connection, TCP responds to a received packet with an acknowledgement packet. This packet indicates the order of the last received packet. When the sender sends a packet, it starts a timer that indicates how long it has taken for the packet to reach the destination and how long it took for the destination to send an acknowledgement back. When the senderís timeout expires, the packet is resent. In Figure 6.4, we show a simplified example of retransmission caused by timeouts. Here, we see that only one packet is sent, while in reality, TCP will send several packets while waiting for acknowledgements.
Sometimes it can be good to detect losses earlier than what the timeout enables by tracking the acknowledgements. By using cumulative acknowledgements, the destination can indicate the last packet that was successfully received. Then, if a packet is not received, the next one in line will arrive before it. To indicate that a packet is missing at the destination end, the last packet in sequence that was received is acknowledged. Figure 6.5 illustrates how losing packet 2 makes the recipient send a duplicated acknowledgement of packet 1, because that was the last-in-order packet that it received.
Figure 6.4 TCP retransmission due to timeout.
As the sender receives this indication, he or she knows that other packets have arrived before packet 2ópossibly indicating that this packet was lost. Packet 2 is therefore resent, and the sender does not have to wait until the timer expires. By detecting double acknowledgements in this way, TCP can detect lost packets and resend them more quickly.
If we now look at this retransmission scheme in a wireless system, however, there is a potential problem. TCP facilitates reliable connectivity between two hosts, end-to-end. In a typical scenario with a user in New York surfing a Web site that is based in California on his GPRS-enabled laptop, the wireless link might be 1km out of a total of 1000km. Because the wireless link is subjected to disturbances and losses to a much larger magnitude, covering losses with an end-to-end protocol might not be the best idea. Most wireless systems, therefore, have their own link-layer retransmission protocols that can operate over the air link only and quickly resend lost packets. In other words, the TCP session will not notice that packets got lost over the air. As an example, General Packet Radio Services (GPRS) uses the RLC protocol over the air interface in order to hide the packet loss from the end-to-end protocols. The retransmission over the air link then removes most of the packet loss, but the price paid is
Figure 6.5 TCP retransmission with double acknowledgments.
the delay that the retransmissions cause. In cases where the bit-error rate is high, the latency that the retransmission protocol adds will be significant. In CDMA systems, where the target signal quality can be adjusted in the system, it is useful to make sure that a high enough target value is chosen so that retransmissions over the air are minimized.
Flow and Congestion Control
On the Internet, there are hundreds of hosts in each subnet, all of which are trying to get their data through to its destination. This chaotic setup can only work if each computer acts with a certain amount of manners and follows a common set of rules. When we analyze this way of designing a network, the biggest potential problem is if everybody tries to send massive amounts of data at the same time. This phenomenon is commonly called congestion (when everybody sends and no one gets anything through). To get around this problem, TCP takes note if it receives indications that packets have been lost or severely delayed (signs of congestion). TCP reacts by retransmitting missing data and simultaneously invoking congestion control (both proactive and reactive).
In order to avoid getting into a congested situation, the sender and receiver both keep a dialogue regarding how much to send. This dialogue is the size of the sending window. Factors that limit this throughput are the current load of the link and the available space in the receiverís buffer. The TCP header has a
field in which the receiver can suggest a window size. The sender uses the window that the receiver suggests (after the receiver has considered the available buffer space) in order to estimate the maximum throughput of the link and a corresponding sending window. As long as the sender keeps the window below that maximum, it knows that the receiverís buffer can handle it.