This preview shows page 1. Sign up to view the full content.
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 ﬁxed 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 ﬁne-grained timer, which we assume ﬁres each slot), it ﬁrst 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 ﬁlters 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 ﬁrst 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
the order of 1− p − 1, assuming that each packet is lost independently and with the same
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
Second, the number of outstanding packets might be larger than the conﬁgured 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 conﬁgured
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.
- Fall '13