We will use a xed size window in our discussion in

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: additional new packet will get sent with even higher sequence number. But somewhere in the midst of these new packet transmissions, the sender’s timeout for packet k will occur, and the sender will retransmit that packet. If that packet reaches, then it will trigger an ACK, and if that ACK reaches the sender, yet another new packet with a new sequence number one larger than the last sent so far will be sent. Hence, this protocol tries hard to keep as many packets outstanding as possible, but not exceeding the window size, W . If ￿ packets (or ACKs) get lost, then the effective number of outstanding packets reduces to W − ￿, until one of them times out, is received successfully by the receiver, and its ACK received successfully at the sender. We will use a fixed size window in our discussion in this course. The sender picks a maximum window size and does not change that during a stream. ￿ 20.5.1 Sliding Window Sender We now describe the salient features of the sender side of this protocol. The sender maintains unacked pkts, a buffer of unacknowledged packets. Every time the sender is called (by a fine-grained timer, which we assume fires each slot), it first checks to see whether any packets were sent greater than TIMEOUT slots ago (assuming time is maintained in “slots”). If so, the sender retransmits each of these packets, and takes care to change the packet transmission time of each of these packets to be the current time. For convenience, we usually maintain the time at which each packet was last sent in the packet data struc- SECTION 20.5. SLIDING WINDOW PROTOCOL 13 ture, though other ways of keeping track of this information are also possible. After checking for retransmissions, the sender proceeds to see whether any new packets can be sent. To properly check if any new packets can be sent, the sender maintains a variable, outstanding, which keeps track of the current number of outstanding packets. If this value is smaller than the maximum window size, the sender sends a new packet, setting the sequence number to be max seq + 1, where max seq is the highest sequence number sent so far. Of course, we should remember to update max seq as well, and increment outstanding by 1. Whenever the sender gets an ACK, it should remove the acknowledged packet from unacked pkts (assuming it hasn’t already been removed), decrement outstanding, and call the procedure to calculate the timeout (which will use the timestamp echoed in the current ACK to update the EWMA filters and update the timeout value). We would like outstanding to keep track of the number of unackowledged packets between sender and receiver. We have described the method to do this task as follows: increment it by 1 on each new packet transmission, and decrement it by 1 on each ACK that was not previously seen by the sender, corresponding to a packet the sender had previously sent that is being acknowledged (as far as the sender is concerned) for the first time. The question now is whether outstanding should be adjusted when a retransmission is done. A little thought will show that it does not. The reason is that it is precisely on a timeout of a packet that the sender believes that the packet was actually lost, and in the sender’s view, the packet has left the network. But the retransmission immediately adds a packet to the network, so the effect is that the number of outstanding packets is exactly the same. Hence, no change is required in the code. Implementing a sliding window protocol is sometimes error-prone even when one completely understands the protocol in one’s mind. Three kinds of errors are common. First, the timeouts are set too low because of an error in the EWMA estimators, and packets end up being retransmitted too early, leading to spurious retransmissions. In addition to keeping track of the sender’s smoothed round-trip time (srtt), RTT deviation, and timeout estimates,6 it is a good idea to maintain a counter for the number of retransmissions done for each packet. If the network has a certain total loss rate between sender and receiver and back (i.e., the bi-directional loss rate), pl , the number of retransmissions should be on 1 the order of 1− p − 1, assuming that each packet is lost independently and with the same l probability. (It is a useful exercise to work out why this formula holds.) If your implementation shows a much larger number than this prediction, it is very likely that there’s a bug in it. Second, the number of outstanding packets might be larger than the configured window, which is an error. If that occurs, and especially if a bug causes the number of outstanding packets to grow unbounded, delays will increase and it is also possible that packet loss rates caused by congestion will increase. It is useful to place an assertion or two that checks that the outstanding number of packets does not exceed the configured window. Third, when retransmitting a packet, the sender must take care to modify the time at which the packet is sent. Otherw...
View Full Document

This document was uploaded on 02/26/2014 for the course CS 6.02 at MIT.

Ask a homework question - tutors are online