The sender attaches a transport layer header to every

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: 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 identifier for the packet. Ideally, this identifier will never be reused for two different packets on the same stream.2 The receiver, upon receiving the packet with identifier k, will send an acknowledgment (ACK) to the sender; the header of this ACK contains k, so 1 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 filtered 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. 2 In an ideal implementation, such reuse will never occur. In practice, however, a transport protocol may use a sequence number field 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 ACK Data S R Data S R Data 1 X 2 2 ACK Data 3 3 ACK Normal behavior (no losses) 1 X ACK 1 lost Timeout Retransmit Da 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 identifiers, how this protocol may deliver duplicate packets to the receiver application, and how to pick the timeout. ￿ 20.2.1 Selecting Unique Identifiers: Sequence Numbers The sender may pick any unique identifier 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 identifier (which for our purposes will be taken to be 1), and then increment the identifier by 1 for each subsequent new packet. Thus, the packet sent after the ACK for k is received by the sender will be have identifier k + 1. These incrementing identifiers 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.

Ask a homework question - tutors are online