Copyright Hari Balakrishnan, 1998-2005, all rights reserved. Please do n ot redistributewithout permission.LECTURE 3Coping with Best-Effort: ReliableTransportThis lecture discusses how e n d systems in the Internet cope with the best-effort propertiesof the Internet ’s network layer. We study the key reliability techniques in TCP, includ-ing TCP’s cumulative acknowledgment feedback, and two forms of retransmission uponencountering a loss: timer-driven and data-driven retransmissions. The former relies o n es-timating the connection round-trip time (RTT) to set a timeout, whereas the latter relieson the successful receipt of later packets to initiate a packet recovery without waiting fora timeout. Examples of data-driven retransmissions include the fast retransmission mech-anism and selective acknowledgment (SACK) mechanism. Because it is helpful to view thevarious techniques used in TCP through the lens of history, we structure our discus sion interms of various TCP variants.We then discuss application-level framing (ALF) [3], an approach that helps achieveselective reliability by being more integrated with the application than TCP is with applica-tions.! 3.1 The Problem: A Best-Effort NetworkA best-effort network greatly simplifies the internal design o f the ne twork, but implies thatthere may be times when a packet sent from a sender does not reach the receiver, or doesnot reach the receiver in a timely manner, or is reordered behind packets sent later, or isduplicated. A transport protocol must deal with these problems:1. Losses, w h ich typically because of congestion, packet corruption due to noise or in-terference, routing anomalies, or link/path failures.Congestion losses are a consequence of using a packet-switched network fo r statisti-cal multiplexing, because a burst of packets arriving into a qu eue may e x h aust bufferspace. It is usually a bad idea to maintain a really large queue buffer, be cause an ex-cessively large buffer only causes packets to be delayed and doe sn’t make them movethrough the network any faster! We will discuss the factors governing queue bufferspace during our discussions on router design and congestion control.12 LECTURE 3. COPING WITH BEST-EFFORT: RELIABLE TR ANSPORT2. Variable delays for packet delivery.3. Packet reordering, which typically arises because of multiple paths between end-points, or pathologies in router implementations.4. Duplicate packets, which occasionally arrive at a receiver because of bugs in netw orkimplementations or lower-layer data retransmissions.Many applications, including file transfer s, interactive t erminal sessions, etc. requirereliable data delivery, with packets arriving in-order, in the same order in which the sendersent them. These applications will ben efit from a reliable transport protocol, which is imple-mented in a layer below the application (typically in th e kernel) and provides an in-order,reliable, byte-stream abst r action to higher-layer applications via a well-defined “socket”interface. TCP provides such semantics.However, this layered in-order TCP model is no t always the best way to transport ap-plication data. First, many app lications can process data that arrives out-of-order. Forexample, consider the delivery of video or audio streams on the Inte r n et. The loss of apacket in a video or audio stream may not be important, because the receiver is capableof “hiding” this loss by averaging neighboring samples, with only a small degradation inquality to the end user. However, it might be the case that some video packets are impor-tant, because they contain information useful both to th e current frame and to subsequentframes. These lost packets may need to be recovere d. Hence, selective reliability is a usefulgoal.Second, if data is provided to the application only in-order as with TCP, a missing packetcauses a stall in data delivery until it is retransmitted by the sender, after which the receiverapplication has to process a number of packets. If the receiver application cares about inter-active response, or if receiver processing befo re the user looks at the presented informationis a bottleneck, a TCP-like approach is sub-optimal.The above observations motivate a different (non-layered) approach to transport proto-col design, called ALF, application-level framing.This lecture discuss es bo th approaches to transport protocol design. Our goal, as men-tioned before, is to cope with the vagaries of a best-effort network.! 3.2 Tr ansmission Control Protocol (TCP)The TCP service model is that of an in-order, reliable, du plex, byte-stream abstraction. Itdoesn’t treat datagrams as atomic units, but instead treats by tes as the fundamental unit ofreliability. The TCP abstraction is for unicast transport, between two n etwork attachmentpoints (IP addresses, not end hosts). “Duplex” refers to the fact that the same connectionhandles reliable data delivery in both directions.In general, reliable transmission protocols can use one or both of two kinds of tech-niques to achieve reliability in the face of packet loss. The first, called Forward Error Correc-tion (FEC), is to use redundancy in th e packet stream to overcome the effects of some losses.The second is called Automatic Repeat reQuest (ARQ), and uses packet retransmissions. Theidea is for the sender to infer the receiver’s state us ing acknowledgments (ACKs) it gets,and determine that packets are lost if an ACK hasn’t arrived for a while, and retransmit ifnecessary.SECTION 3.2. TRANSMISSION CONTROL PROTOCOL (TCP) 3In TCP, the receiver periodically1informs the sender about what data it has receivedvia cumulative ACKs. For example, the s equence of bytes:1:1000 1001:1700 2501:3000 3001: 4000 4001:4576received at the receiver will cause the ACKs1001 1701 1701 1701 1701to be sent by the receiver after each segment arrival. Each ACK acknowledges all t h e by tesreceived in-sequence thus far, and tells the sender what the next expe cted in-sequence byteis.Each TCP ACK includes in it a receiver-advertised window that tells the sender ho wmuch space is available in its s ocket buffer at any point in time. This window is u sed forend-to-end flow control, and should not be confused with congestion control, which is howresource contention for “inside-the-netw ork” router resources (bandwidth, buffer space)is dealt with. Flow control only deals with making s ure that the sender doesn’t overrunthe receiver at any stage