This preview shows page 1. Sign up to view the full content.
Unformatted text preview: Wait Protocol The high-level idea is quite simple. The sender attaches a transport-layer header to every
packet (distinct from the network-layer packet header that contains the destination address,
hop limit, and header checksum discussed in the previous lectures), which includes a
unique identiﬁer for the packet. Ideally, this identiﬁer will never be reused for two different packets on the same stream.2 The receiver, upon receiving the packet with identiﬁer
k, will send an acknowledgment (ACK) to the sender; the header of this ACK contains k, so
The reason for the “exactly one copy” requirement is that the mechanism used to solve the problem will
end up retransmitting packets, so duplicates may occur that need to be ﬁltered out. In some networks, it is
possible that some links may end up duplicating packets because of mechanisms they employ to improve the
packet delivery probability or bit-error rate over the link.
In an ideal implementation, such reuse will never occur. In practice, however, a transport protocol may
use a sequence number ﬁeld whose width is not large enough and sequence numbers may wrap-around. In
this case, it is important to ensure that two distinct unacknowledged packets never have the same sequence
number. 3 SECTION 20.2. STOP-AND-WAIT PROTOCOL Sender Receiver
Data 1 RTT 1 1
Data S R
Data S R
Data 1 X 2 2
ACK Normal behavior
(no losses) 1 X
ACK 1 lost Timeout
ta 1 Data loss +
retransmission Data 1 Duplicate
packet reception Figure 20-1: The stop-and-wait protocol. Each picture has a sender timeline and a receiver timeline. Time
starts at the top of each vertical line and increases moving downward. The picture on the left shows what
happens when there are no losses; the middle shows what happens on a data packet loss; and the right
shows how duplicate packets may arrive at the receiver because of an ACK loss. the receiver communicates “I got packet k” to the sender.
The sender sends the next packet on the stream if, and only if, it receives an ACK for
k. If it does not get an ACK within some period of time, called the timeout, the sender
retransmits packet k.
The receiver’s job is to deliver each packet it receives to the receiver application. Figure 20-1 shows the basic operation of the protocol when packets are not lost (left) and when
data packets are lost (right).
Three properties of this protocol bear some discussion: how to pick unique identiﬁers,
how this protocol may deliver duplicate packets to the receiver application, and how to
pick the timeout.
20.2.1 Selecting Unique Identiﬁers: Sequence Numbers The sender may pick any unique identiﬁer for a packet, but in most transport protocols,
a convenient (and effective) way of doing so is to use incrementing sequence numbers.
The simplest way to achieve this goal is for the sender and receiver to somehow agree on
the initial value of the identiﬁer (which for our purposes will be taken to be 1), and then
increment the identiﬁer by 1 for each subsequent new packet. Thus, the packet sent after
the ACK for k is received by the sender will be have identiﬁer k + 1. These incrementing
identiﬁers are called sequence numbers. 4 CHAPTER 20. RELIABLE DATA TRANSPORT PROTOCOLS In practice, transport protocols like TCP (Transmission Control Protocol), the standard
Internet protocol for reliable data delivery, devote considerable effort to picking a good
initial sequence number to avoid overlaps with previous instantiations of reliable streams
between the same communicating processes. We won’t worry about these complications
in this chapter, except to note that establishing and properly terminating these streams
(aka connections) reliably is a non-trivial problem.
20.2.2 Semantics of Our Stop-and-Wait Protocol It is easy to see that the stop-and-wait protocol achieves reliable data delivery as long as
each of the links along the path have a non-zero packet delivery probability. However, it
does not achieve exactly once semantics; its semantics are at least once—i.e., each packet will
be delivered to the receiver application either once or more than once.
One reason is that the network could drop ACKs, as shown in Figure 20-1 (right). A
packet may have reached the receiver, but the ACK doesn’t reach the sender, and the
sender will then timeout and retransmit the packet. The receiver will get multiple copies of
the packet, and deliver both to the receiver application. Another reason is that the sender
might have timed out, but the original packet may not actually have been lost. Such a
retransmission is called a spurious retransmission, and is a waste of bandwidth.
Preventing duplicates: The solution to this problem is for the receiver to keep track of
the last in-sequence packet it has delivered to the application. We will maintain the lastinsequence packet in the variable rcv seqnum. If a packet with sequence number less
than or equal to rcv seqnum arrives, then the receiver sends an ACK for the packet and
discards it (the only way a packet with sequence number smaller than rcv seqnum can
arrive is if there was reordering in the network and the receiver gets an old packet; for
such packets, the receiver can safely not send an ACK because it knows that...
View Full Document
This document was uploaded on 02/26/2014 for the course CS 6.02 at MIT.
- Fall '13