Computer Networks: A Systems Approach, 5e

Larry L. Peterson and Bruce S. Davie

Chapter 5
End-to-End Protocols

Copyright © 2010, Elsevier Inc. All rights Reserved 1

 Chapter 5
Problem
 How to turn this host-to-host packet delivery service
into a process-to-process communication channel

2
 Chapter 5
2 main protocols
 Simple Demultiplexer (UDP)
 Reliable Byte Stream (TCP)

3
 Chapter 5
End-to-end Protocols
 Common properties that a transport protocol can be expected
to provide
 Guarantees message delivery

 Delivers messages in the same order they were sent

 Delivers at most one copy of each message

 Supports arbitrarily large messages

 Supports synchronization between the sender and the

receiver
 Allows the receiver to apply flow control to the sender

 Supports multiple application processes on each host

4
 Chapter 5
End-to-end Protocols
 Typical limitations of the network on which transport
protocol will operate
 Drop messages

 Reorder messages

 Deliver duplicate copies of a given message

 Limit messages to some finite size

 Deliver messages after an arbitrarily long delay

5
 Chapter 5
Simple Demultiplexer (UDP)
 Simplest protocol in transport layer that extends host-to-host
delivery service of the underlying network into a process-to-
process communication service is called UDP(User Datagram
Protocol)

 There are likely to be many processes running on any given host.

 Adds a level of demultiplexing which allows multiple application

processes on each host to share the network.

 The User Datagram Protocol (UDP) is called a connectionless,

unreliable(does not guarantee message delivery) transport
protocol.
6
 Chapter 5
 Port numbers or Port addresses are used for process to process
communication.

 A process is really identified by a port on some particular host—a

port, host pair(Socket Address).

 The next issue is how a process learns the port for the process to
which it wants to send a message.

 Typically, a client process initiates a message exchange with a

server process.

7
 Chapter 5
 Once a client has contacted a server, the server knows the
client’s port (it was contained in the message header) and can
reply to it.

 The real problem, therefore, is how the client learns the server’s
port in the first place. A common approach is for the server to
accept messages at a well-known port.

 Sometimes a well-known port is just the starting point for

communication: The client and server use the well-known port to
agree on some other port that they will use for subsequent
communication, leaving the well-known port free for other
clients.

8
 Chapter 5
 Well-known ports used with UDP

9
 Chapter 5
 TCP Well-known port numbers

10
 Chapter 5
UDP Packet Format

Format for UDP header (Note: length and checksum fields

should be switched)

11
 Chapter 5
 Source port number:
 This is the port number used by the process running on the
source host. It is 16 bits long, which means that the port
number can range from 0 to 65,535.

 If the source host is the client (a client sending a request), the

port number, in most cases chosen by the UDP software
running on the source host.

 If the source host is the server (a server sending a response),

the port number, in most cases, is a well-known port number.

12
 Chapter 5
 Destination port number:
 This is the port number used by the process running on the
destination host. It is also 16 bits long.

 If the destination host is the server (a client sending a request),

the port number, in most cases, is a well-known port number.

 If the destination host is the client (a server sending response),

the port number is the number that has received in the request
packet.

13
 Chapter 5
 Length:
 This is a 16-bit field that defines the total length of the user
datagram, header plus data.

 A user datagram is encapsulated in an IP datagram.

 UDP length = IP length - IP header's length

 Checksum:
 This field is used to detect errors over the entire user datagram
(header plus data).

14
 Chapter 5
Simple Demultiplexer (UDP)

UDP Message Queue

15
 Chapter 5
 UDP does not implement flow control or reliable/ordered
delivery.

 It ensures only the correctness of the message by the use of a

checksum and demultiplexing of datagrams to different
application processes.

16
 Chapter 5
UDP Operations
 In UDP, a process (an application program) sends messages,
with predefined boundaries, to UDP for delivery.

 UDP adds its own header to each of these messages and delivers
them to IP for transmission.

 Each message from the process is called a user datagram and

becomes, eventually, one IP datagram.

 Neither IP nor UDP recognizes any relationship between the

datagrams.

17
 Chapter 5
Reliable Byte Stream (TCP)
 In contrast to UDP, Transmission Control Protocol (TCP)
offers the following services
 Reliable
 Connection oriented
 Byte-stream service
 CP will deliver segments to the applications in order and
without error, lost, or duplicates.

18
 Chapter 5
 TCP establishes a virtual connection.
 TCP connection ensures that the receiving process is
available and ready before the data is sent.

19
 Chapter 5
Stream Delivery Service
 TCP, allows the sending process to deliver data as a stream of
bytes and allows the receiving process to obtain data as a stream
of bytes.

 TCP creates an environment in which the two processes seem to

be connected by an imaginary "tube“ that carries their data
across the Internet.

 The sending process produces (writes to) the stream of bytes, and
the receiving process consumes (reads from) them.

20
 Chapter 5
 Sending and Receiving Buffers
 Because the sending and the receiving processes may not write
or read data at the same speed, TCP needs buffers for storage.

 There are two buffers, the sending buffer and the receiving
buffer, one for each direction.

21
Chapter 5
22
 Chapter 5
 At the sending site, the buffer has three types of chambers.

 The white section contains empty chambers that can be filled

by the sending process (producer).

 The gray area holds bytes that have been sent but not yet
acknowledged.

 TCP keeps these bytes in the buffer until it receives an

acknowledgment.

 The colored area contains bytes to be sent by the sending TCP.

23
 Chapter 5
 After the bytes in the gray chambers are acknowledged, the
chambers are recycled and available for use by the sending process.
 The operation of the buffer at the receiver site is simpler.
 The circular buffer is divided into two areas (shown as white and
colored).

 The white area contains empty chambers to be filled by bytes

received from the network.

 The colored sections contain received bytes that can be read by the
receiving process.
 When a byte is read by the receiving process, the chamber is
recycled and added to the pool of empty chambers.

24
 Chapter 5
 Segments:
 The IP layer, as a service provider for TCP, needs to send data
in packets, not as a stream of bytes.

 At the transport layer, TCP groups a number of bytes together

into a packet called a segment.

 TCP adds a header to each segment (for control purposes) and

delivers the segment to the IP layer for transmission.

 The segments are encapsulated in IP datagrams and

transmitted.
25
Chapter 5
26
 Chapter 5
 Segments may be received out of order, lost, or corrupted and
resent. All these are handled by TCP.

 Full-Duplex Communication:
 TCP offers full-duplex service, in which data can flow in both
directions at the same time.
 Each TCP then has a sending and receiving buffer, and
segments move in both directions.

27
 Chapter 5
 Connection-Oriented Service:
 TCP, unlike UDP, is a connection-oriented protocol.

 When a process at site A wants to send and receive data from

another process at site B, the following occurs:
1. The two TCPs establish a virtual connection between them.
2. Data are exchanged in both directions.
3. The connection is terminated.

28
 Chapter 5
 Reliable Service:
 TCP is a reliable transport protocol.
 It uses an acknowledgment mechanism to check the safe and
sound arrival of data.

29
 Chapter 5
TCP Segment Format

30
 Chapter 5
 Minimum header length is 20 bytes and the maximum is 60
bytes when there are options .
 Source port address : This is a 16-bit field that defines the port
number of the application program in the host that is sending
the segment.
 Destination port address : This is a 16-bit field that defines the
port number of the application program in the host that is
receiving the segment.
 Sequence number: This 32-bit field defines the number
assigned to the first byte of data contained in this segment.

31
 Chapter 5
 Acknowledgment number: This 32-bit field defines the byte
number that the receiver of the segment is expecting to receive
from the other party.

 If the receiver of the segment has successfully received byte

number x from the other party, it defines x + 1 as the
acknowledgment number.

 Acknowledgment and data can be piggybacked together.

32
 Chapter 5
 Header length: This 4-bit field indicates the number of 4-byte
words in the TCP header. The length of the header can be
between 20 and 60 bytes.

 Reserved: This is a 6-bit field reserved for future use.

 Control: This field defines 6 different control bits or flags.

33
Chapter 5
34
 Chapter 5
 Window size: This field defines the size of the window, in bytes,
that the other party must maintain.
 Checksum: This 16-bit field contains the checksum for error
detection.
 Urgent pointer: This l6-bit field, which is valid only if the
urgent flag is set, is used when the segment contains urgent
data.
 It defines the number that must be added to the sequence
number to obtain the number of the last urgent byte in the data
section of the segment.
 Options: There can be up to 40 bytes of optional information
in the TCP header.

35
 Chapter 5
Flow control VS Congestion control
 Flow control involves preventing senders from overrunning the
capacity of the receivers.
 Congestion control involves preventing too much data from being
injected into the network, thereby causing switches or links to
become overloaded.

36
 Chapter 5
End-to-end Issues(TCP Issues)
 The heart of TCP is the sliding window algorithm

 As TCP runs over the Internet rather than a point-to-point link,

the following issues need to be addressed by the sliding
window algorithm.
 TCP supports logical connections between processes that

are running on two different computers in the Internet

 TCP connections are likely to have widely different RTT

times(Timeout mechanism must be adaptive)

 Packets may get reordered in the Internet (Maximum

Segment Lifetime is needed. Eg:120s)

37
 Chapter 5
End-to-end Issues
 TCP needs a mechanism using which each side of a connection
will learn what resources(how much buffer space) the other side is
able to apply to the connection. This is flow control issue.

 TCP needs a mechanism using which the sending side will learn
the capacity of the network.

38
 Chapter 5
A TCP Connection
 TCP is connection-oriented.

 A connection-oriented transport protocol establishes a virtual

path between the source and destination.

 All the segments belonging to a message are then sent over

this virtual path.

 In TCP, connection-oriented transmission requires three

phases: connection establishment, data transfer, and
connection termination.

39
 Chapter 5
Connection Establishment
 TCP transmits data in full-duplex mode.

When two TCPs in two machines are connected, they are able to
send segments to each other simultaneously.

This implies that each party must initialize communication and

get approval from the other party before any data are
transferred.

40
 Chapter 5
 Three-Way Handshaking
 The connection establishment in TCP is called three-way
handshaking.

 In our example, an application program, called the client,

wants to make a connection with another application
program, called the server, using TCP as the transport layer
protocol.

 The process starts with the server. The server program tells
its TCP that it is ready to accept a connection. This is called a
request for a passive open.

41
 Chapter 5
 Although the server TCP is ready to accept any
connection from any machine in the world, it cannot
make the connection itself.

 The client program issues a request for an active open.

 A client that wishes to connect to an open server tells its

TCP that it needs to be connected to that particular
server.

42
Chapter 5
43
 Chapter 5
First Step
The client sends the first segment, a SYN segment, in which

only the SYN flag is set.

This segment is for synchronization of sequence numbers.

 It consumes one sequence number.

When the data transfer starts, the sequence number is

incremented by 1.

We can say that the SYN segment carries no real data.
A SYN segment cannot carry data, but it consumes one

sequence number.
44
 Chapter 5
 Second Step
 The server sends the second segment, a SYN +ACK
segment, with 2 flag bits set: SYN and ACK.

 This segment has a dual purpose.

 It is a SYN segment for communication in the other
direction and serves as the acknowledgment for the SYN
segment.
 It consumes one sequence number.
 A SYN +ACK segment cannot carry data, but does consume
one sequence number.

45
 Chapter 5
 Third step
 The client sends the third segment. This is just an ACK
segment.
 It acknowledges the receipt of the second segment with the
ACK flag and acknowledgment number field.

 Note that the sequence number in this segment is the same as

the one in the SYN segment; the ACK segment does not
consume any sequence numbers.

 An ACK segment, if carrying no data, consumes no sequence

number.

46
 Chapter 5
 Data Transfer
 After connection is established, bidirectional data transfer
can take place.
 The client and server can both send data and
acknowledgments.

47
Chapter 5
48
 Chapter 5
 After connection is established , the client sends 2000 bytes
of data in two segments.

 The server then sends 2000 bytes in one segment.

 The client sends one more segment.

 The first three segments carry both data and

acknowledgment, but the last segment carries only an
acknowledgment because there are no more data to be sent.

49
 Chapter 5
 The data segments sent by the client have the PSH (push)
flag set so that the server TCP knows to deliver data to the
server process as soon as they are received.

 The segment from the server, on the other hand, does not
set the push flag.
 Pushing Data
 The sending TCP uses a buffer to store the stream of data
coming from the sending application program.
 The sending TCP can select the segment size.

50
 Chapter 5
 The receiving TCP also buffers the data when they arrive
and delivers them to the application program when the
application program is ready or when it is convenient for
the receiving TCP.

 This type of flexibility increases the efficiency of TCP.

51
 Chapter 5
Connection Termination
Any of the two parties involved in exchanging data (client or
server) can close the connection, although it is usually initiated
by the client.
Three way and four way handshaking techniques are available.

Three-way Handshaking:
First step

In a normal situation, the client TCP, after receiving a close

command from the client process, sends the first segment, a FIN
segment in which the FIN flag is set.

52
 Chapter 5
 Note that a FIN segment can include the last chunk of data
sent by the client, or it can be just a control segment.

 The FIN segment consumes one sequence number ifit does

not carry data.
 Second Step
 The server TCP, after receiving the FIN segment, informs
its process of the situation and sends the second segment, a
FIN +ACK segment, to confirm the receipt of the FIN
segment from the client and at the same time to announce
the closing of the connection in the other direction.

53
 Chapter 5
 This segment can also contain the last chunk of data from the
server.
 If it does not carry data, it consumes only one sequence
number.
 Third Step
 The client TCP sends the last segment, an ACK segment, to
confirm the receipt of the FIN segment from the TCP server.

 This segment contains the acknowledgment number, which is 1

plus the sequence number received in the FIN segment from
the server.
 This segment cannot carry data and consumes no sequence
numbers.

54
Chapter 5
55
 Chapter 5
Sliding Window Revisited
 TCP’s variant of the sliding window algorithm, which serves
several purposes:
 (1) it guarantees the reliable delivery of data,

 (2) it ensures that data is delivered in order, and

 (3) it enforces flow control between the sender and the receiver.

56
 Chapter 5
 Rather than having a fixed-size sliding window, the receiver
advertises a window size to the sender.

 This is done using the Advertised Window field(window size) in

the TCP header.

 The receiver selects a suitable value for Advertised Window

based on the amount of memory allocated to the connection for
the purpose of buffering data.

57
 Chapter 5
 Reliable and Ordered Delivery
 TCP on the sending side maintains a send buffer.

 This buffer is used to store data that has been sent but not yet
acknowledged, as well as data that has been written by the
sending application, but not transmitted.

 On the receiving side, TCP maintains a receive buffer.

 This buffer holds data that arrives out of order, as well as data
that is in the correct order but that the application process has
not yet had the chance to read.
58
 Chapter 5
Sliding Window Revisited

Relationship between TCP send buffer (a) and receive buffer (b).

59
 Chapter 5
 At the sending side, three pointers are maintained into the send
buffer, each with an obvious meaning:

 LastByteAcked, LastByteSent, and LastByteWritten.



 LastByteAcked ≤ LastByteSent
 LastByteSent ≤ LastByteWritten

 None of the bytes to the left of LastByteAcked need to be saved in

the buffer because they have already been acknowledged.

 Buffer stores bytes between LastByteAcked and LastByteWritten

60
 Chapter 5
 At the receiving side, similar three pointers are maintained into
the receive buffer, each with an obvious meaning:
 LastByteRead, NextByteExpected, and LastByteRcvd.

 LastByteRead < NextByteExpected

 NextByteExpected ≤ LastByteRcvd+1

 Since, if data has arrived in order, NextByteExpected points to

the byte after LastByteRcvd, whereas if data has arrived out of
order, NextByteExpected points to the start of the first gap in the
data.

61
 Chapter 5
 Note that bytes to the left of LastByteRead need not be buffered
because they have already been read by the local application
process.

 Flow Control
 The size of the window sets the amount of data that can be sent
without waiting for acknowledgment from the receiver.

 Thus, the receiver limits the sender by advertising a window

that is no larger than the amount of data that it can buffer.

62
 Chapter 5
 TCP on the receive side must keep,
 LastByteRcvd− LastByteRead ≤ MaxRcvBuffer
 to avoid overflowing its buffer.

 It therefore advertises a window size of

 AdvertisedWindow= MaxRcvBuffer−((NextByteExpected− 1)
−LastByteRead)

 which represents the amount of free space remaining in its

buffer.

63
 Chapter 5
Triggering Transmission
 Issue : how TCP decides to transmit a segment.
 If we ignore the possibility of flow control—that is, we assume the
window is wide open, as would be the case when a connection first
starts—then TCP has three mechanisms to trigger the
transmission of a segment.

 First, TCP maintains a variable, typically called the maximum

segment size (MSS), and it sends a segment as soon as it has
collected MSS bytes from the sending process.

 MSS is usually set to the size of the largest segment TCP can send
without causing the local IP to fragment.

64
 Chapter 5
 The second thing that triggers TCP to transmit a segment is
that the sending process has explicitly asked it to do so.

 The final trigger for transmitting a segment is that a timer

fires; the resulting segment contains as many bytes as are
currently buffered for transmission.

 Silly Window Syndrome

 We can’t just ignore flow control

65
 Chapter 5
 Silly Window Syndrome (SWS) is a problem that can arise in
poor implementations of TCP when the receiver is only able to
accept a few bytes at a time or when the sender transmits data in
small segments repeatedly.

 The resulting number of small packets, or tinygrams, on the

network can lead to a significant reduction in network
performance and can indicate an overloaded server or a sending
application that is limiting throughput.

66
 Chapter 5
Nagle's algorithm:
It is a means of improving the efficiency of TCP/IP networks by
reducing the number of packets that need to be sent over the
network.

To reduce the no of small packets, the TCP sender needs to wait
until the receiver buffer size is equal to MSS.

 Issue: How long it has to wait.?

 Solution: Nagle’s Algorithm

67
 Chapter 5
 Nagle introduced an elegant self-clocking solution-a clock-
based timer—ACK.

 The idea is that as long as TCP has any data in flight, the
sender will eventually receive an ACK.

 This ACK can be treated like a timer firing, triggering the

transmission of more data.

68
 Chapter 5
 When the application produces data to send
if both the available data and the window ≥ MSS
send a full segment
else
if there is unACKed data in flight
buffer the new data until an ACK arrive
else
send all the new data now

69
 Chapter 5
 In other words, it’s always OK to send a full segment if the
window allows.

 It’s also alright to immediately send a small amount of data if

there are currently no segments in transit, but if there is
anything in flight, the sender must wait for an ACK before
transmitting the next segment.

 This algorithm interacts badly with TCP delayed

acknowledgments.

70
 Chapter 5
Adaptive Retransmission
 TCP guarantees the reliable delivery of data, it retransmits each
segment if an ACK is not received in a certain period of time.

 TCP sets this timeout as a function of the RTT it expects between

the two ends of the connection.

 But with TCP RTT is different for different logical connections.

 To address this problem, TCP uses an adaptive retransmission

mechanism.

71
 Chapter 5
 Original Algorithm
 A simple algorithm for computing a timeout value between a
pair of hosts.
 Every time TCP sends a data segment, it records the time.

 When an ACK for that segment arrives, TCP reads the time
again, and then takes the difference between these two times as
a SampleRTT.

 TCP then computes an EstimatedRTT as a weighted average

between the previous estimate and this new sample.

72
 Chapter 5
 EstimatedRTT = α ×EstimatedRTT+(1−α)×SampleRTT
 The parameter α is used to smoothen Estimated RTT
(represents changes in the RTT).

 Timeout =2 X Estimated RTT

Karn/Partridge Algorithm
 In other words, whenever a segment is retransmitted and then

an ACK arrives at the sender, it is impossible to determine if

this ACK should be associated with the first or the second
transmission of the segment for the purpose of measuring the
sample RTT.

73
Chapter 5
74
 Chapter 5
 if you assume that the ACK is for the original transmission but it
was really for the second, then the SampleRTT is too large(a),

 while if you assume that the ACK is for the second transmission
but it was actually for the first, then the SampleRTT is too small
(b).

 Solution: Whenever TCP retransmits a segment, it stops taking

samples of the RTT; it only measures SampleRTT for segments
that have been sent only once.

 Each time TCP retransmits, it sets the next timeout to be twice the
last timeout, rather than basing it on the last EstimatedRTT.

75
 Chapter 5
Jacobson/Karels Algorithm
The Karn/Partridge algorithm was designed to fix some of the

causes of the network congestion but the congestion was not

eliminated.

 Aim: To find an accurate timeout value

The main problem with the original computation is that it does not
take the variance of the sample RTTs into account.

If the variation among samples is small, then the Estimated RTT
can be better trusted and there is no reason for multiplying this
estimate by 2 to compute the timeout.
76
 Chapter 5
 A large variance in the samples suggests that the timeout value
should not be too tightly coupled to the EstimatedRTT.

 SampleRTT(Calculation same as in Karn/Partridge algorithm)

 Timeout Calculation:

 Difference = SampleRTT−EstimatedRTT
 EstimatedRTT = EstimatedRTT+(δ ×Difference)
 Deviation = Deviation+δ(|Difference| − Deviation)

 where δ is a fraction between 0 and 1.

77
 Chapter 5
 TCP then computes the timeout value as a function of both
EstimatedRTT and Deviation as follows:

 TimeOut = μ×EstimatedRTT+φ ×Deviation

where based on experience, μ is typically set to 1 and φ is set to 4.

 Thus, when the variance is small, TimeOut is close to

EstimatedRTT; a large variance causes the Deviation term to
dominate the calculation.

78
 Chapter 5
TCP Congestion Control
 The essential strategy of TCP is to send packets into the network
without a reservation and then to react to observable events that
occur.

 The idea of TCP congestion control is for each source to

determine how much capacity is available in the network, so that
it knows how many packets it can safely have in transit.

 Once a given source has this many packets in transit, it uses the
arrival of an ACK as a signal that one of its packets has left the
network, and that it is therefore safe to insert a new packet into
the network without adding to the level of congestion.

79
 Chapter 5
 Three independent mechanisms
 Additive Increase/Multiplicative Decrease

 Slow Start

 Fast Retransmit and Fast Recovery

 Additive Increase/Multiplicative Decrease

 TCP maintains a new state variable for each connection, called
Congestion Window, which is used by the source to limit how
much data it is allowed to have in transit at a given time.

 The congestion window is congestion control’s counterpart to

flow control’s advertised window.

80
 Chapter 5
 TCP is modified such that the maximum number of bytes of
unacknowledged data allowed is now the minimum of the
congestion window and the advertised window.

 TCP’s effective window is revised as follows:

 MaxWindow = MIN(CongestionWindow , AdvertisedWindow)

 EffectiveWindow = MaxWindow−(LastByteSent− LastByteAcked)

 The TCP source sets the CongestionWindow based on the level of

congestion it perceives to exist in the network.

81
 Chapter 5
 This involves decreasing the congestion window when the level
of congestion goes up and increasing the congestion window
when the level of congestion goes down.

 Taken together, the mechanism is commonly called additive

increase/multiplicative decrease (AIMD).

 The source determines that the network is congested and

decrease the congestion window based on the observation that
the main reason packets are not delivered, and a timeout
results, is that a packet was dropped due to congestion.

82
 Chapter 5
 TCP interprets timeouts as a sign of congestion and reduces the
rate at which it is transmitting.

 Specifically, each time a timeout occurs , the source sets

CongestionWindow to half of its previous value.

 This halving of the CongestionWindow for each timeout

corresponds to the “multiplicative decrease” part of AIMD.

 For example, suppose the CongestionWindow is currently set to

16 packets. If a loss is detected, CongestionWindow is set to 8.

83
 Chapter 5
 Additional losses cause CongestionWindow to be reduced to 4,
then 2, and finally to 1 packet.

 CongestionWindow is not allowed to fall below the size of a

single packet, or in TCP terminology, the maximum segment size
(MSS).

 Packets in transit during additive increase, with one packet being

added each RTT.

84
 Chapter 5
Packets in transit during additive increase, with one packet being added each
RTT.

85
 Chapter 5
 It works as follows:

 Every time the source successfully sends a

CongestionWindow’s worth of packets—that is, each packet
sent out during the last RTT has been ACKed—it adds the
equivalent of 1 packet to CongestionWindow.

 This linear increase is illustrated in Figure.

86
Chapter 5
87
 Chapter 5
 AIMD operation can be represented as a sawtooth pattern.

 This pattern of continually increasing and decreasing the

congestion window continues throughout the lifetime of the
connection.

 The important concept to understand about AIMD is that the

source is willing to reduce its congestion window at a much
faster rate than it is willing to increase its congestion window.

88
 Chapter 5
Slow Start
 The additive increase mechanism just described is the right
approach to use when the source is operating close to the
available capacity of the network, but it takes too long to ramp up
a connection when it is starting from scratch.

 Slow start effectively increases the congestion window

exponentially, rather than linearly.

 Specifically, the source starts out by setting CongestionWindow to

one packet.

 When the ACK for this packet arrives, TCP adds 1 to

CongestionWindow and then sends two packets.

89
 Chapter 5
 Upon receiving the corresponding two ACKs, TCP increments
CongestionWindow by 2—one for each ACK—and next sends
four packets.

 The end result is that TCP effectively doubles the number of

packets it has in transit every RTT.

90
Chapter 5
91
 Chapter 5
 There are actually two different situations in which slow start
runs.

 The first is at the very beginning of a connection, at which time

the source has no idea how many packets it is going to be able
to have in transit at a given time.

 In this situation, slow start continues to double

CongestionWindow each RTT until there is a loss, at which
time a timeout causes multiplicative decrease to divide
CongestionWindow by 2

92
 Chapter 5
 The second situation in which slow start is used is a bit more
subtle; it occurs when the connection goes dead while waiting for
a timeout to occur.

 When a packet is lost, the source eventually reaches a point

where it has sent as much data as the advertised window allows,
and so it blocks while waiting for an ACK that will not arrive.

 Eventually, a timeout happens, but by this time there are no

packets in transit, meaning that the source will receive no ACKs
to “clock” the transmission of new packets.

93
 Chapter 5
 The source will instead receive a single cumulative ACK that
reopens the entire advertised window, but as explained above,
the source then uses slow start to restart the flow of data
rather than dumping a whole window’s worth of data on the
network all at once.

94
Chapter 5
95
 Chapter 5
Fast Retransmit and Fast Recovery
 The mechanisms described so far were part of the original
proposal to add congestion control to TCP.

 It was soon discovered, however, that the coarse-grained

implementation of TCP timeouts led to long periods of time
during which the connection went dead while waiting for a timer
to expire.

 Because of this, a new mechanism called fast retransmit was

added to TCP.

96
 Chapter 5
 Fast retransmit is a heuristic that sometimes triggers the
retransmission of a dropped packet sooner than the regular
timeout mechanism.

 The fast retransmit mechanism does not replace regular

timeouts; it just enhances that facility.

 The idea of fast retransmit is straightforward.

 Every time a data packet arrives at the receiving side, the

receiver responds with an acknowledgment, even if this
sequence number has already been acknowledged.

97
 Chapter 5
 Thus, when a packet arrives out of order—that is, TCP cannot
yet acknowledge the data the packet contains because earlier
data has not yet arrived—TCP resends the same
acknowledgment it sent the last time.

 This second transmission of the same acknowledgment is

called a duplicate ACK.

 When the sending side sees a duplicate ACK, it knows that the
other side must have received a packet out of order, which
suggests that an earlier packet might have been lost.

98
 Chapter 5
 Since it is also possible that the earlier packet has only been
delayed rather than lost, the sender waits until it sees some
number of duplicate ACKs and then retransmits the missing
packet.

 In practice, TCP waits until it has seen three duplicate ACKs

before retransmitting the packet.

99
Chapter 5
100
 Chapter 5
 In this example, the destination receives packets 1 and 2, but
packet 3 is lost in the network.

 Thus, the destination will send a duplicate ACK for packet 2

when packet 4 arrives, again when packet 5 arrives, and so on.

 When the sender sees the third duplicate ACK for packet 2—
the one sent because the receiver had gotten packet 6—it
retransmits packet 3.

 Note that when the retransmitted copy of packet 3 arrives at

the destination, the receiver then sends a cumulative ACK for
everything up to and including packet 6 back to the source.

101
 Chapter 5
 When the fast retransmit mechanism signals congestion, rather
than drop the congestion window all the way back to one
packet and run slow start, it is possible to use the ACKs that
are still in the pipe to clock the sending of packets.

 This mechanism, which is called fast recovery, effectively

removes the slow start phase that happens between when fast
retransmit detects a lost packet and additive increase begins.

102
 Chapter 5
 Trace of TCP with fast retransmit. Colored line =
CongestionWindow; solid bullet = timeout; hash marks = time
when each packet is transmitted; vertical bars = time when a
packet that was eventually retransmitted was first transmitted.

103