Chapter 3 outline

3.1 transport-layer 3.5 connection-oriented

services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

3-1

1
 TCP: Overview RFCs: 793,1122,1323, 2018, 2581

 point-to-point:  full duplex data:

 one sender, one receiver  bi-directional data flow
 reliable, in-order byte in same connection
steam:  MSS: maximum segment
size
 no “message
boundaries”  connection-oriented:
 pipelined:  handshaking (exchange
of control msgs) inits
 TCP congestion and sender, receiver state
flow control set window before data exchange
size
ability of TCP to send multiple segments  flow controlled:
of data before waiting for
acknowledgment of each individual  sender will not
segment. overwhelm receiver
3-2

TCP (Transmission Control Protocol) is a widely used communication protocol in

computer networks, providing a reliable and efficient means of transmitting data
between two endpoints in a point-to-point, full-duplex manner. TCP ensures that
data is delivered in the correct order and without errors by using
acknowledgments, sequence numbers, and retransmissions. It operates on a byte-
stream level, meaning there are no predefined message boundaries, allowing for
the efficient transmission of data of varying sizes. TCP is also pipelined, enabling
the sender to transmit multiple segments without waiting for acknowledgment,
which improves overall efficiency. It employs congestion and flow control
mechanisms, such as window sizes, to prevent network congestion and ensure
that the sender does not overwhelm the receiver. Additionally, TCP is connection-
oriented, establishing a reliable and ordered data exchange between sender and
receiver through a handshaking process, which initializes their respective states
before the data transfer begins. All these features make TCP a fundamental
protocol for ensuring the reliable and orderly transmission of data across the
internet and other computer networks.

2
 TCP segment structure

3-3

A TCP segment header also contains the following fields:

• The 32-bit sequence number field and the 32-bit acknowledgment number field
are used by the TCP sender and receiver in implementing a reliable data
transfer service.
• The 16-bit receive window field is used for flow control. It is used to indicate
the number of bytes that a receiver is willing to accept.
• The 4-bit header length field specifies the length of the TCP header in 32-bit
words. The TCP header can be of variable length due to the TCP options field.
• The optional and variable-length options field is used when a sender and
receiver negotiate the maximum segment size (MSS) or as a window scaling fac-
tor for use in high-speed networks..
• The flag field contains 6 bits. The ACK bit is used to indicate that the value
carried in the acknowledgment field is valid; that is, the segment contains an
acknowledgment for a segment that has been successfully received. The
RST,SYN, and FIN bits are used for connection setup and teardown

3
TCP seq. numbers, ACKs
outgoing segment from sender
sequence numbers: source port # dest port #
sequence number
byte stream “number” of acknowledgement number

first byte in segment’s checksum

rwnd
urg pointer
data window size
acknowledgements: N

seq # of next byte

expected from other side sender sequence number space
cumulative ACK
sent sent, not- usable not
Q: how receiver handles ACKed yet ACKed but not usable
out-of-order segments (“in-
flight”)
yet sent

A: TCP spec doesn’t say, incoming segment to sender

- up to implementor source port # dest port #
sequence number
acknowledgement number
A rwnd
checksum urg pointer

3-4

4
 Sequence number example

if you have a byte stream like this:

Byte Stream: ABCDEFGHIJKLMNOPQRSTUVWXYZ
And you divide it into three TCP segments:
•Segment 1: Sequence Number 1000, containing "ABC"
•Segment 2: Sequence Number 1003, containing "DEF"
•Segment 3: Sequence Number 1006, containing "GHI“

In this example, the sequence number for Segment 1 is 1000 because it contains the first byte
("A") in the byte stream.
The sequence number for Segment 2 is 1003 because it starts with the third byte ("D") in the byte
stream, and so on.

These sequence numbers are crucial for the receiver to correctly reassemble the data in
the correct order, and they are also used for flow control, error recovery, and other aspects of
reliable data transmission in TCP.

5
 Acknowledgements example
Suppose there are two devices communicating using TCP, a sender (S) and a receiver (R). The sender
has a byte stream:
Byte Stream: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Segment 1 (S to R): The sender divides the data into segments and sends the first segment:
Segment 1: Sequence Number 1000, containing "ABC"
Acknowledgment 1 (R to S): The receiver receives Segment 1 and sends an acknowledgment (ACK) back to the sender. In the ACK:
The ACK number is 1003, indicating the next expected sequence number.
The acknowledgment is cumulative, meaning it acknowledges all bytes up to but not including the byte with sequence number 1003.
This ACK indicates to the sender that the receiver has successfully received the bytes up to "C" (inclusive) in the byte stream. The sender can now
continue sending the next data segment.
Segment 2 (S to R): The sender sends the next segment:
Segment 2: Sequence Number 1003, containing "DEF"
Acknowledgment 2 (R to S): The receiver receives Segment 2 and sends another ACK:
The ACK number is 1006, indicating the next expected sequence number.
It's still a cumulative acknowledgment, so it acknowledges all bytes up to but not including the byte with sequence number 1006.
This ACK indicates that the receiver has successfully received the bytes up to "F" (inclusive) in the byte
stream. The process continues for subsequent segments. In this way, the receiver uses ACKs to inform
the sender of the sequence number of the next expected byte and to confirm the receipt of all bytes up to
a specific point in the byte stream. This ensures reliable and ordered data delivery in TCP.

6
Summary of Seq# & ACK#
Sequence numbers are used to keep Acknowledgments (ACKs) are a
track of the bytes in a data stream critical part of the protocol's
being sent over a network reliability mechanism. An
connection. Each byte of data in a acknowledgment in TCP serves to
TCP segment is assigned a unique acknowledge the receipt of data and
sequence number, which is essentially inform the sender about the next
the "number" of the first byte in the sequence number expected from the
segment's data within the byte other side.
stream. This sequence number allows In Cumulative ACK, when the
TCP to order and reassemble the receiver acknowledges a specific
data correctly at the receiving end. sequence number, it implies that all
bytes with lower sequence numbers
have been received successfully.

7
 TCP seq. numbers, ACKs
Host A Host B

User
types
‘C ’ Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
host ACKs
receipt
of echoed
‘C ’ Seq=43, ACK=80

simple telnet scenario

ACK number (43) on the B-to-A segment is one more than the sequence number (42) on the
A-to-B segment that triggered that ACK. ACK number (80) on the last A-to-B segment is one
more than the sequence number (79) on the B-to-A segment that triggered that ACK.
3-8

We assume the starting sequence numbers are 42 and 79 for the client and server, respectively. Recall that the
sequence number of a segment is the sequence number of the first byte in the data field. Thus, the first segment sent
from the client will have sequence number 42; the first segment sent from the server will have sequence number 79.
Recall that the acknowledgment number is the sequence number of the next byte of data that the host is waiting for.
After the TCP connection is established but before any data is sent, the client is waiting for byte 79 and the server is
waiting for byte 42.

As shown in Figure, three segments are sent. The first segment is sent from the client to the server, containing the 1-
byte ASCII representation of the letter ‘C’
in its data field. This first segment also has 42 in its sequence number field. Also, because the client has not yet
received any data from the server, this first segment will have 79 in its acknowledgment number field.

The second segment is sent from the server to the client. It serves a dual purpose. First it provides an
acknowledgment of the data the server has received. By
putting 43 in the acknowledgment field, the server is telling the client that it has successfully received everything up
through byte 42 and is now waiting for bytes 43 onward. The second purpose of this segment is to echo back the
letter ‘C.’ Thus, the second segment has the ASCII representation of ‘C’ in its data field. This second segment has
the sequence number 79, the initial sequence number of the server-to- client data flow of this TCP connection, as
this is the very first byte of data that the server is sending. Note that the acknowledgment for client-to-server data is
carriedin a segment carrying server-to-client data; this acknowledgment is said to be piggybacked on the server-to-
client data segment.

The third segment is sent from the client to the server. Its sole purpose is to acknowledge the data it has received
from the server. (Recall that the second seg-

8
ment contained data—the letter ‘C’—from the server to the client.) This segment has an empty data
field (that is, the acknowledgment is not being piggybacked with any client-to-server data). The
segment has 80 in the acknowledgment number field because the client has received the stream of
bytes up through byte sequence number 79 and it is now waiting for bytes 80 onward. Y

8
 Consider the figure below in which a TCP sender and receiver communicate over a connection in
which the sender->receiver segments may be lost. The TCP sender sends an initial window of 3
segments. Suppose the initial value of the sender->receiver sequence number is 307 and the first 3
segments each contain 476 bytes. The delay between the sender and receiver is 7 time units, and so
the first segment arrives at the receiver at t=8. As shown in the figure below, 1 of the 3 segment(s)
are lost between the segment and receiver.

1. Give the sequence numbers associated with each of the 3

segments sent by the sender. Format your answer as: a,b,c,...

2. Give the ACK numbers the receiver sends in response to each

of the segments. If a segment never arrives use 'x' to denote it,
and format your answer as: a,b,c,...

1. 307, 783,1259
2. 783,X,783

9
 Consider the figure below in which a TCP sender and receiver communicate over a connection in
which the sender->receiver segments may be lost. The TCP sender sends an initial window of 4
segments. Suppose the initial value of the sender->receiver sequence number is 455 and the first 4
segments each contain 493 bytes. The delay between the sender and receiver is 7 time units, and so
the first segment arrives at the receiver at t=8. As shown in the figure below, 2 of the 4 segment(s)
are lost between the segment and receiver.

1. Give the sequence numbers associated with each of the 3

segments sent by the sender. Format your answer as: a,b,c,...

2. Give the ACK numbers the receiver sends in response to each

of the segments. If a segment never arrives use 'x' to denote it,
and format your answer as: a,b,c,...

1. 455,948,1441,1934
2. 948 , X, X,

10
 TCP round trip time, timeout
Q: how to set TCP Q: how to estimate RTT?
timeout value?  SampleRTT: measured
time from segment
 longer than RTT transmission until ACK
 but RTT varies receipt
 too short: premature  ignore retransmissions
timeout, unnecessary  SampleRTT will vary, want
retransmissions estimated RTT “smoother”
 average several recent
 too long: slow reaction measurements, not just
to segment loss current SampleRTT

3-11

The TCP timeout value determines how long the sender waits for an
acknowledgment (ACK) before retransmitting a segment. It's crucial to strike a
balance between being too short and too long

11
 TCP round trip time, timeout
This is how TCP re-computes the estimated RTT each time a new SampleRTT is taken.
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 exponential weighted moving average
  represents the influence of the most recent measurements on the estimated
RTT where its noticed that the effect of the past sample decreases exponentially
fast. typical value:  = 0.125
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250

RTT (milliseconds)
measured RTTs between a host in the
Massachusetts
200

and a host in France, 150

as well as the estimated, “smoothed” RTT

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

SampleRTT Estimated RTT

time (seconds) 3-12

EstimatedRTT: This is an estimate of the RTT between the sender and receiver.
It is continuously updated based on the measured SampleRTT values.

12
 TCP round trip time, timeout
Given this value of the estimated RTT, TCP computes

 timeout interval: EstimatedRTT plus “safety margin”

• large variation in EstimatedRTT: want a larger safety margin
TCP computes the Timeout interval to be the Estimated RTT plus 4 times a measure of deviation in the RTT.

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”

The deviation in the RTT is computed as the eWMA of the difference between the most recently measured
SampleRTT from the Estimated RTT

 DevRTT: EWMA of SampleRTT deviation from EstimatedRTT:

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|
(typically,  = 0.25)

* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/

Given this value of the estimated RTT, TCP computes the timeout interval to be
the estimated RTT plus a “safety margin”. DevRTT: This represents the
deviation or variance in RTT values. It helps account for variations in
SampleRTT.

And the intuition is that if we are seeing a large variation in SAMPLERTT – the
RTT estimates are fluctuating a lot - then we’ll want a larger safety margin

So TCP computes the Timeout interval to be the Estimated RTT plus 4 times a
measure of deviation in the RTT.

The deviation in the RTT is computed as the eWMA of the difference between
the most recently measured SampleRTT from the Estimated RTT

13
 Suppose that TCP's current estimated values for the round trip time (estimatedRTT) and deviation
in the RTT (DevRTT) are 230 msec and 25 msec, respectively. Suppose that the next three
measured values of the RTT are 390 msec, 280 msec, and 290 msec respectively.

Compute TCP's new value of DevRTT, estimatedRTT, and

the TCP timeout value after each of these three
measured RTT values is obtained. Use the values of α =
0.125, and β = 0.25. Round your answers to two decimal
places after leading zeros.

1. What is the estimatedRTT after the first RTT? EstimatedRTT₁ = 0.875 * EstimatedRTT₀ + 0.125 * SampleRTT₁
RTT Deviation₁ = 0.75 * DevRTT₀ + 0.25 * |SampleRTT₁ - EstimatedRTT₁|
2. What is the RTT Deviation for the the first RTT?
3. What is the TCP timeout for the first RTT? TCP Timeout₁ = EstimatedRTT₁ + 4 * RTT Deviation₁
4. What is the estimatedRTT after the second RTT?
5. What is the RTT Deviation for the the second RTT?
6. What is the TCP timeout for the second RTT?
7. What is the estimatedRTT after the third RTT?
8. What is the RTT Deviation for the the third RTT?
9. What is the TCP timeout for the third RTT?

EstimatedRTT₂ = 0.875 * EstimatedRTT₁ + 0.125 * SampleRTT₂

RTT Deviation₂ = 0.75 * DevRTT₁ + 0.25 * |SampleRTT₂ - EstimatedRTT₂|
TCP Timeout₂ = EstimatedRTT₂ + 4 * RTT Deviation₂
1. 250
2. 58.75
3. 485
4. 253.75
5. 51.56
6. 460
7. 258.28
8. 47.73
9. 449.22

14
 Suppose that the five measured SampleRTT values are 106 ms, 120 ms,
140 ms, 90 ms, and 115 ms. Compute the EstimatedRTT after each of
these SampleRTT values is obtained, using a value of a = 0.125 and
assuming that the value of EstimatedRTT was 100 ms just before the first
of these five samples were obtained. Compute also the DevRTT after each
sample is obtained, assuming a value of ẞ = 0.25 and assuming the value
of DevRTT was 5 ms just before the first of these five samples was
obtained. Last, compute the TCP Timeout Interval after each of these
samples is obtained.

Calculate the EstimatedRTT after obtaining the first sample

RTT=106ms,
EstimatedRTT = α * SampleRTT+(1- α) * EstimatedRTT Calculate the EstimatedRTT after obtaining the
EstimatedRTT =0.125 * 106 + (1-0.125) * 100 fourth sample RTT=90ms:
=0.125* 106 + 0.875 * 100 =13.25 + EstimatedRTT = α * SampleRTT+(1- α) *
87.5 =100.75ms EstimatedRTT
Calculate the DevRTT after obtaining the first sample RTT: EstimatedRTT =0.125 * 90 + (1-0.125) * 107.75
DevRTT = β * | SampleRTT- EstimatedRTT|+(1- β)* DevRTT =0.125* 90 + 0.875 * 107.75
=0.25 * |106-100.75| + (1-0.25) *5 =11.25 +94.28
=0.25 *5.25 + 0.75 * 5 =1.3125 + 3.75 =5.0625ms =105.53ms
Calculate the Timeout Interval after obtaining the first Calculate the DevRTT after obtaining the fourth
sample RTT: sample RTT:
TimeoutInterval = EstimatedRTT +4* DevRTT DevRTT = β * | SampleRTT- EstimatedRTT|+(1- β)*
= 100.75 + 4 *5.0625 =121ms DevRTT
Calculate the EstimatedRTT after obtaining the second =0.25 * |90-105.53| + (1-0.25) *14.06
sample RTT=120ms, =0.25 *15.53 + 0.75 * 14.06
EstimatedRTT = α * SampleRTT+(1- α) * EstimatedRTT =3.88 + 10.545
EstimatedRTT =0.125 * 120 + (1-0.125) * 100.75 =14.42ms
=0.125* 120 + 0.875 * 100.75 =15 +
88.15625 =103.15625ms Calculate the Timeout Interval after obtaining the
Calculate the DevRTT after obtaining the second sample fourth sample RTT:
RTT: TimeoutInterval = EstimatedRTT +4* DevRTT
DevRTT = β * | SampleRTT- EstimatedRTT|+(1- β)* DevRTT = 105.53 + 4 *14.42
=0.25 * |120-103.15625| + (1-0.25) *5.0625 =163.21ms
=0.25 *16.84 + 0.75 * 5.0625 =4.21 + 3.79 =8ms
Calculate the EstimatedRTT after obtaining the fifth
Calculate the Timeout Interval after obtaining the second sample RTT=115ms:
sample RTT: EstimatedRTT = α * SampleRTT+(1- α) *
TimeoutInterval = EstimatedRTT +4* DevRTT EstimatedRTT
= 103.15 + 4 *8 EstimatedRTT =0.125 * 115 + (1-0.125) * 105.53
=135.15ms =0.125* 115 + 0.875 * 105.53
Calculate the EstimatedRTT after obtaining the third =14.375 +92.34
sample RTT=140ms: =106.715ms
EstimatedRTT = α * SampleRTT+(1- α) * EstimatedRTT Calculate the DevRTT after obtaining the fifth sample
EstimatedRTT =0.125 * 140 + (1-0.125) * 103.15 RTT:
=0.125* 140 + 0.875 * 103.15 DevRTT = β * | SampleRTT- EstimatedRTT|+(1- β)*
=17.5 +90.26 DevRTT
=107.75ms =0.25 * |115-106.715| + (1-0.25) *14.42
Calculate the DevRTT after obtaining the third sample RTT: =0.25 *8.285 + 0.75 * 14.42
DevRTT = β * | SampleRTT- EstimatedRTT|+(1- β)* DevRTT =2.07 + 10.815
=0.25 * |140-107.75| + (1-0.25) *8 =12.885ms
=0.25 *32.25 + 0.75 * 8 Calculate the Timeout Interval after obtaining the
=8.06 + 6 fifth sample RTT:
=14.06ms TimeoutInterval = EstimatedRTT +4* DevRTT
= 106.715 + 4 *12.885
Calculate the Timeout Interval after obtaining the third =158.255ms
sample RTT:
TimeoutInterval = EstimatedRTT +4* DevRTT
= 107.75 + 4 *14.06
=164ms 15
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

3-16

16
TCP reliable data transfer
 TCP creates rdt service
on top of IP’s unreliable
service
 pipelined segments
 cumulative acks let’s initially consider
 single retransmission simplified TCP sender:
timer  ignore duplicate acks
 retransmissions  ignore flow control,
triggered by: congestion control
 timeout events
 duplicate acks

3-17

17
 TCP sender events:
data rcvd from app: timeout:
 create segment with  retransmit segment
seq # that caused timeout
 seq # is byte-stream  restart timer
number of first data ack rcvd:
byte in segment  if ack acknowledges
 start timer if not previously unacked
already running segments
 think of timer as for  update what is known
oldest unacked to be ACKed
segment
 start timer if there are
 expiration interval: still unacked segments
TimeOutInterval

3-18

Data Received from the Application:

•When data is received from the application layer, the TCP sender creates a TCP segment to transmit this data. The
sequence number (seq #) in the segment is set to the byte-stream number of the first data byte in the segment.
•If a timer for the oldest unacknowledged segment is not already running, the sender starts a timer. This timer is
associated with the segment and is used to track the expiration interval, known as the TimeOutInterval.
Timeout Event:
•When the timer associated with a segment expires, it signifies a timeout event. This typically indicates that the
acknowledgment for that segment was not received within the expected time frame.
•In response to a timeout, the sender retransmits the segment that caused the timeout. This is done to ensure reliable
delivery of the data.
•After retransmitting the segment, the sender restarts the timer associated with that segment, effectively resetting the
timeout interval for retransmission.
Acknowledgment Received (ACK):
•When an acknowledgment (ACK) is received from the receiver, the sender examines the ACK to determine which
segments have been acknowledged.
•If the ACK acknowledges previously unacknowledged segments (i.e., segments that were in flight and not yet
acknowledged), the sender updates its knowledge of what data has been acknowledged. This allows the sender to keep
track of which segments are still outstanding.
•If there are still unacknowledged segments (indicating that not all data has been acknowledged), the sender may start
or continue the timer associated with the oldest unacknowledged segment. This ensures that the sender continues to
monitor for acknowledgment of the remaining segments.

These events and actions are part of TCP's congestion control and reliability mechanisms. They ensure that data is

18
reliably delivered, retransmitted when necessary, and that the sender adjusts its behavior in
response to network conditions and acknowledgments from the receiver. This combination of
mechanisms allows TCP to provide robust and reliable communication over potentially unreliable
network links.

18
 TCP: retransmission scenarios
Host A Host B Host A Host B

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

timeout
ACK=100
X
ACK=100
ACK=120

Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data send
SendBase=120 cumulative
ACK=100 ACK for
ACK=120 120
SendBase=120
lost ACK scenario premature timeout
The receiver has already received the first two segments, and so
When a TCP segment is transmitted and the ACK is lost, and resends a cumulative ACK for both segments received so far, rather
the TCP timeout mechanism results in another copy of being than an ACK for just this fist segment.
transmitted and then re-ACKed atthe sender 3-19

19
TCP: retransmission scenarios
Host A Host B

Seq=92, 8 bytes of data the first ACK is lost but the second ACK, a
cumulative ACK arrives at the sender,
Seq=100, 20 bytes of data
which then can transmit a third segment,
ACK=100 knowing that the first two have arrived,
timeout

X even though the ACK for the first

ACK=120 segment was lost

Seq=120, 15 bytes of data

cumulative ACK
3-20

20
 TCP ACK generation [RFC 1122, RFC 2581]

event at receiver TCP receiver action

arrival of in-order segment with delayed ACK. Wait up to 500ms
expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK

arrival of in-order segment with immediately send single cumulative

expected seq #. One other ACK, ACKing both in-order segments
segment has ACK pending

arrival of out-of-order segment immediately send duplicate ACK,

higher-than-expect seq. # . indicating seq. # of next expected byte
Gap detected

arrival of segment that immediate send ACK, provided that

partially or completely fills gap segment starts at lower end of gap

3-21

•When an in-order segment with the expected sequence number arrives, and all data up to the expected
sequence number has already been acknowledged, the receiver may delay sending an acknowledgment
(ACK).
•The receiver waits for a short period (up to 500 milliseconds) for the possible arrival of the next segment.
If no further segment arrives during this time, the receiver sends an ACK for the received segment.

•If an in-order segment with the expected sequence number arrives, and there is another segment with an
ACK pending (i.e., awaiting acknowledgment), the receiver sends an immediate single cumulative ACK.
•The cumulative ACK acknowledges both the in-order segment and the previously pending segment,
reducing the number of ACKs sent.

•When an out-of-order segment arrives with a sequence number higher than expected, indicating a gap in
the received data, the receiver sends an immediate duplicate ACK.
•The duplicate ACK indicates the sequence number of the next expected byte. This lets the sender know
that there is a gap in the received data.

•If a subsequent segment arrives that partially or completely fills the gap identified by the out-of-order
segment, the receiver sends an immediate ACK.
•This ACK acknowledges the received data and provides feedback to the sender about the updated
reception status.

21
These receiver actions are part of TCP's flow and congestion control mechanisms. They
help in optimizing the communication by minimizing the number of ACKs sent, reducing
network congestion, and ensuring that the sender receives feedback about the status of its
transmitted data. The receiver's behavior helps maintain the reliability and efficiency of
TCP connections.

21
 In this TCP lost ACK scenario, the first two messages get to the receiver and the 1st
message's ACK is dropped. However, the 2nd message's ACK gets through. Answer the
following questions:
a. What is the ACK at a?
b. What is the ACK at b?
c. What is the sequence number at c?

1. 122
2. 142
3. 142

22
 Host A and B are communicating over a TCP connection, and Host B has already received from
A all bytes up through byte 126. Suppose Host A then sends two segments to Host B back-to-
back. The first and second segments contain 80 and 40 bytes of data, respectively. In the first
segment, the sequence number is 127, the source port number is 302, and the destination
port number is 80. Host B sends an acknowledgment whenever it receives a segment from
Host A.
a. In the second segment sent from Host A to B, what are the sequence number, source port
number, and destination port number?
b. If the first segment arrives before the second segment, in the acknowledgment of the first
arriving segment, what is the acknowledgment number, the source port number, and the
destination port number?
c. If the second segment arrives before the first segment, in the acknowledgment of the first
arriving segment, what is the acknowledgment number?
d. Suppose the two segments sent by A arrive in order at B. The first acknowledgment is lost
and the second acknowledgment arrives after the first time- out interval. Draw a timing
diagram, showing these segments and all other segments and acknowledgments sent.
(Assume there is no additional packet loss.) For each segment in your figure, provide the
sequence number and the number of bytes of data; for each acknowledgment that you add,
provide the acknowledgment number.

Given data:
•Host A and B are communicating over a TCP connection, and Host B has
already received from A all bytes up through byte 126.
•The first and second segments contain 80 and 40 bytes of data, respectively.
•The first segment of sequence number is 127.
•The source port number is 302.
•The destination port number is 80
a) Sequence number = first segment of sequence number+ destination port
number =127+80 =207
So, sequence number=207
Source port number = 302
Destination port number= 80
b)Acknowledgement number= 207
Source port number = 80
Destination port number= 302
c) Acknowledgement number=127

23
 TCP fast retransmit
 time-out period often
relatively long: TCP fast retransmit
 long delay before if sender receives 3
resending lost packet ACKs for same data
 detect lost segments ((““triple
triple duplicate
duplicate ACKs
ACKs””),),
via duplicate ACKs. resend unacked
 sender often sends segment with smallest
many segments back- seq #
to-back
 likely that unacked
 if segment is lost, there segment lost, so don’t
will likely be many wait for timeout
duplicate ACKs.

3-24

The "FAST Retransmit" mechanism in TCP is designed to expedite the

retransmission of a lost segment when the sender receives multiple duplicate
acknowledgments (ACKs) for the same data. This mechanism helps reduce the
delay before retransmitting a lost packet, as waiting for the standard timeout
period can introduce unnecessary latency.

24
 TCP fast retransmit
Host A Host B

Seq=92, 8 bytes of data

The sender receives the first ACK 100 it
has been hoping for, but then three
Seq=100, 20 bytes of data
additional duplicate ACK100s arrive.
With fast retransmit, the
X
arrival of three duplicate ACK
causes the sender to
ACK=100
retransmit its oldest unACKed
timeout

segment, without waiting for a ACK=100

timeout event. This allows
ACK=100
TCP to recover more quickly
from what is very likely a loss ACK=100
event Seq=100, 20 bytes of data

fast retransmit after sender

receipt of triple duplicate ACK
3-25

25
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

3-26

26
 TCP flow control
application
application may process
remove data from application
TCP socket buffers ….
TCP socket OS
receiver buffers
… slower than TCP
receiver is delivering
(sender is sending) TCP
code

IP
flow control code
receiver controls sender, so
sender won’t overflow
receiver’s buffer by transmitting from sender
too much, too fast
receiver protocol stack

3-27

Flow control is an essential mechanism in communication protocols like TCP

(Transmission Control Protocol) that ensures that the sender does not overwhelm
the receiver by transmitting data too quickly. Flow control is implemented by the
receiver, and it allows the receiver to control the rate at which data is sent by the
sender.

27
 TCP flow control to application process

 receiver “advertises” free RcvBuffer buffered data

buffer space by including
rwnd value in TCP header rwnd free buffer space
of receiver-to-sender
segments
 RcvBuffer size set via TCP segment payloads
socket options (typical default
is 4096 bytes)
 many operating systems receiver-side buffering
autoadjust RcvBuffer
 sender limits amount of
unacked (“in-flight”) data to
receiver’s rwnd value
 guarantees receive buffer
will not overflow
3-28

TCP flow control is a critical mechanism that ensures that the sender does not overwhelm the receiver by
sending data too quickly. The receiver communicates its available buffer space to the sender through the
use of a "receive window" (rwnd) value included in TCP header fields in acknowledgment (ACK)
segments.

The receiver has a designated amount of buffer space available to hold incoming data, which is
determined by its receive buffer size.
The receiver maintains a buffer, often referred to as the "Receive Buffer" or "RcvBuffer," to store
incoming data.
The receiver advertises its available buffer space to the sender by including an rwnd value in the TCP
header of acknowledgment segments.

•The sender, upon receiving an acknowledgment (ACK) from the receiver, examines the rwnd value in
the ACK segment to determine the available buffer space at the receiver.
•The sender then limits the amount of unacknowledged ("in-flight") data it sends to the receiver based on
the receiver's rwnd value.
•The sender ensures that the amount of data in transit (in-flight data) does not exceed the receiver's
advertised receive window size.

28
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

3-29

29
 Connection Management
before exchanging data, sender/receiver “handshake”:
 agree to establish connection (each knowing the other willing
to establish connection)
 agree on connection parameters

application application

connection state: ESTAB connection state: ESTAB

connection variables: connection Variables:
seq # client-to-server seq # client-to-server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
at server,client at server,client

network network

Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
3-30

TCP connection management is a fundamental aspect of the Transmission

Control Protocol (TCP), which is a reliable, connection-oriented protocol used
for data transmission in computer networks. TCP connection management
involves establishing, maintaining, and terminating connections between two
devices (typically referred to as hosts or endpoints) to enable the reliable
exchange of data.

30
Agreeing to establish a connection

2-way handshake:
Q: will 2-way handshake
always work in
Let’s talk
network?
ESTAB  variable delays
OK
ESTAB  retransmitted messages
(e.g. req_conn(x)) due to
message loss
 message reordering
choose x
req_conn(x)
 can’t “see” other side
ESTAB
acc_conn(x)
ESTAB

3-31

31
Agreeing to establish a connection
2-way handshake failure scenarios:

choose x choose x
req_conn(x) req_conn(x)
ESTAB ESTAB
retransmit acc_conn(x) retransmit acc_conn(x)
req_conn(x) req_conn(x)

ESTAB ESTAB
data(x+1) accept
req_conn(x)
retransmit data(x+1)
data(x+1)
connection connection
client x completes server x completes server
client
terminates forgets x terminates forgets x
req_conn(x)

ESTAB ESTAB
data(x+1) accept
half open connection! data(x+1)
(no client!) dup data
accepted!
3-32

32
 TCP 3-way handshake

client state server state

LISTEN LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
received SYNACK(x)
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1, ACKnum=y+1
client-to-server data
received ACK(y)
indicates client is live
ESTAB

3-33

•Three-Way Handshake: To establish a TCP connection, a three-way handshake

is performed. It involves the following steps:
• SYN (Synchronize): The initiating host (the client) sends a TCP
segment with the SYN flag set to the receiving host (the server).
This initiates the connection establishment process.
• SYN-ACK (Synchronize-Acknowledge): The receiving host (the
server) responds with a TCP segment that has both the SYN and
ACK flags set. It acknowledges the receipt of the client's SYN and
indicates its readiness to establish a connection.
• ACK (Acknowledge): The client responds with a TCP segment that
has the ACK flag set. This acknowledges the server's SYN-ACK,
completing the three-way handshake. The connection is now
established.

33
 TCP: closing a connection
 client, server each close their side of connection
 send TCP segment with FIN bit = 1
 respond to received FIN with ACK
 on receiving FIN, ACK can be combined with own
FIN
 simultaneous FIN exchanges can be handled

3-34

Closing a TCP connection involves a four-way handshake process to ensure a

graceful termination of the connection and to ensure that all remaining data is
transmitted and acknowledged.

34
 TCP: closing a connection
client state server state
ESTAB ESTAB
clientSocket.close()

FIN_WAIT_1 can no longer FINbit=1, seq=x

send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close

LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime

CLOSED

3-35

Initiator Sends FIN Segment:

• The initiator of the connection, whether it's the client or the server, decides to close the connection. This decision is
typically based on the application's logic (e.g., the user closing a web browser or a server application completing its
response).
• The initiator sends a TCP segment with the FIN flag set, indicating that it has finished sending data and wants to
close the connection. This is known as the FIN segment.
Receiver Acknowledges the FIN:
• When the other end (the receiver) receives the FIN segment, it acknowledges it by sending an ACK (Acknowledge)
segment back to the initiator.
• At this point, the receiver can still send any remaining data it has to the initiator, as the connection is not fully
closed yet.
Receiver May Also Send Its Own FIN Segment:
• After the receiver has sent all of its data and is ready to close the connection, it can also initiate the closing of the
connection by sending its own FIN segment.
• This is especially relevant when both the client and server have data to send, and they each want to close the
connection gracefully.
Initiator Acknowledges Receiver's FIN:
 Upon receiving the FIN segment from the receiver, the initiator (whether it's the client or server) sends an ACK
segment to acknowledge the receiver's FIN.
Connection Fully Closed:
• At this point, the connection is fully closed, and both the initiator and receiver have acknowledged the termination
of the connection.

35
• The connection is now in a "TIME_WAIT" state for a short duration to ensure that any
delayed segments from the network are handled properly.
• After the "TIME_WAIT" period expires, the connection is considered fully closed and can be
reused for new connections if needed.

35
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

3-36

36
 Principles of congestion control
congestion:
 informally: “too many sources sending too much
data too fast for network to handle”
 different from flow control!
 manifestations:
 lost packets (buffer overflow at routers)
 long delays (queueing in router buffers)
 a top-10 problem!

3-37

Congestion in computer networks occurs when there is an imbalance between the

volume of data being sent into the network and the network's capacity to handle
that data. It typically arises when "too many sources are sending too much data
too fast for the network to handle." Congestion is a significant issue in
networking and can have various manifestations and negative effects on network
performance.

37
 Causes/costs of congestion: scenario 1
original data: lin throughput: lout
 two senders, two
receivers Host A

 one router, infinite unlimited shared

buffers output link buffers

 output link capacity: R

 no retransmission
Host B

R/2

delay
lout

lin R/2 lin R/2

 maximum per-connection  large delays as arrival rate, lin,
throughput: R/2 approaches capacity
3-38

Without any mechanisms to manage congestion or prioritize traffic, the network experiences increasing
delays, reduced throughput, and potential packet loss as the arrival rate of packets approaches the link
capacity. This scenario demonstrates the importance of congestion control mechanisms and Quality of
Service (QoS) policies to manage and prioritize traffic in networks.
The rate at which Host A offers traffic to the router in this first scenario is thus λin bytes/sec. Host B
operates in a similar manner, and we assume for simplicity that it too is sending at a rate of λin bytes/sec.
Packets from Hosts A and B pass through a router and over a shared outgoing link of capacity R. The router
has buffers that allow it to store incoming packets when the packet-arrival rate exceeds the outgoing link’s
capacity.

The performance of Host A’s connection under this first scenario. The left graph plots the per-connection
throughput (number of bytes per second at the receiver) as a function of the connection-sending rate. For a
sending rate between 0 and R/2, the throughput at the receiver equals the sender’s sending
rate—everything sent by the sender is received at the receiver with a finite delay. When the sending rate is
above R/2, however, the throughput is only R/2. This upper limit on throughput is a consequence of the
sharing of link capacity between two connections. The link simply cannot deliver packets to a receiver at a
steady-state rate that exceeds R/2. No matter how high Hosts A and B set their sending rates, they will each
never see a throughput higher than R/2.

The right-hand graph, shows the consequence of operating near link capacity. As the sending rate
approaches R/2 (from the left), the average delay becomes larger and larger. When the sending rate
exceeds R/2, the average number of queued packets in the router is unbounded, and the average delay

38
between source and destination becomes infinite

38
 Causes/costs of congestion: scenario 2
 one router, finite buffers
 sender retransmission of timed-out packet
 application-layer input = application-layer output: lin =
lout
 transport-layer input includes retransmissions : l‘in lin

lin : original data

lout
l'in: original data, plus
retransmitted data

Host A

finite shared output

Host B
link buffers
3-39

The amount of router buffering is assumed to be finite. A consequence of this

real-world assumption is that packets will be dropped when arriving to an already
full buffer. Second, we assume that each connection is reliable. If a packet
containing a transport-level segment is dropped at the router, the sender will
eventually retransmit it. Because packets can be retransmitted, we must now be
more careful with our use of the term sending rate.
let us denote the rate at which the application sends original data into the socket
by λin bytes/sec. The rate at which the transport layer sends segments (containing
original data and retransmitted data) into the network will be denoted λ’in
bytes/sec

39
 Causes/costs of congestion: scenario 2
R/2
idealization: perfect
knowledge

lout
 sender sends only when
router buffers available
lin R/2

lin : original data

copy lout
l'in: original data, plus
retransmitted data

A free buffer space!

finite shared output

Host B
link buffers
3-40

Consider the unrealistic case that Host A is able to somehow determine whether
or not a buffer is free in the router and thus sends a packet only when a buffer is
free. In this case, no loss would occur, in would be equal to λin , and the
throughput of the connection λout would be equal to λin .

40
Causes/costs of congestion: scenario 2
Idealization: known loss
packets can be lost,
dropped at router due
to full buffers
 sender only resends if
packet known to be lost

lin : original data

copy lout
l'in: original data, plus
retransmitted data

A
no buffer space!

Host B
3-41

41
 Causes/costs of congestion: scenario 2
Idealization: known loss
packets can be lost,
dropped at router due
to full buffers
 sender only resends if
packet known to be lost

lin : original data

lout
l'in: original data, plus
retransmitted data

A
free buffer space!

Host B
3-42

Consider next the slightly more realistic case that the sender retransmits only
when a packet is known for certain to be lost.
Then if the offered load, λin (the rate of original data transmission plus
retransmissions), equals R/2, the rate at which data are delivered to the receiver
application is lesser than R/2..

42
 Causes/costs of congestion: scenario 2
Realistic: duplicates
 packets can be lost, dropped
at router due to full buffers
 sender times out prematurely,
sending two copies, both of
which are delivered

lin
timeout
copy l'in lout

A
free buffer space!

Host B
3-43

The case that the sender may time out prematurely and retransmit a packet that
has been delayed in the queue but not yet lost. In this case, both the original data
packet and the retransmission may reach the receiver.

43
Causes/costs of congestion: scenario 2
Realistic: duplicates
 packets can be lost, dropped
at router due to full buffers
 sender times out prematurely,
sending two copies, both of
which are delivered

“costs” of congestion:
 more work (retrans) for given “goodput”
 unneeded retransmissions: link carries multiple copies of pkt
 decreasing goodput

3-44

44
 Causes/costs of congestion: scenario 3
 four senders Q: what happens as lin and lin’
increase ?
 multihop paths
A: as red lin’ increases, all arriving
 timeout/retransmit blue pkts at upper queue are
dropped, blue throughput g 0
Host A
lin : original data lout
Host B
l'in: original data, plus
retransmitted data
finite shared output
link buffers

Host D
Host C

3-45

Consider the connection from Host A to Host C, passing through routers R1 and
R2. The A–C connection shares router R1 with the D–B connection and
shares router R2 with the B–D connection. For extremely small values of λin ,
buffer overflows are rare and the throughput approximately equals the offered
load. For slightly larger values of λin , the corresponding throughput is also
larger, since more original data is being transmitted into the network and
delivered to the destination, and overflows are still rare.
Consider router R2. The A–C traffic arriving to router R2 (being forwarded from
R1) can have an arrival rate at R2 that is at most R, the capacity of the link from
R1 to R2, regardless of the value of λin . If λin is extremely large for all
connections (including the B–D connection), then the arrival rate of B–D traffic
at R2 can be much larger than that of the A–C traffic. Because the A–C and B–D
traffic must compete at router R2 for the limited amount of buffer space, the
amount of A–C traffic that successfully gets through R2 (that is, is not lost due to
buffer overflow) becomes smaller and smaller as the offered load from B–D gets
larger and larger. In the limit, as the offered load approaches infinity, an empty
buffer at R2 is immediately filled by a B–D packet, and the throughput of the A–
C connection at R2 goes to zero. This, in turn, implies that the A–C end-to-end
throughput goes to zero in the limit of heavy traffic.

45
 Causes/costs of congestion: scenario 3

C/2
lout

lin’ C/2

another “cost” of congestion:

 when packet dropped, any “upstream
transmission capacity used for that packet was
wasted!

3-46

The reason for the eventual decrease in throughput with increasing offered load is
evident when one considers the amount of wasted work done by the net-
work. In the high-traffic scenario outlined above, whenever a packet is dropped at
a second-hop router, the work done by the first-hop router in forwarding a
packet to the second-hop router ends up being “wasted.”

46
Causes/costs of congestion: insights
R/2

 throughput can never exceed capacity

throughput: lout
lin R/2

 delay increases as capacity approached

delay
R/2
lin R/2

lout
 loss/retransmission decreases effective

throughput:
throughput
lin R/2 R/2

 un-needed duplicates further decreases

throughput: lout
effective throughput
R/2
lin

 upstream transmission capacity /

R/2

lout
buffering wasted for packets lost
downstream lin’ R/2

47
 Approaches towards congestion control

two broad approaches towards congestion control:

end-end congestion network-assisted

control: congestion control:
 no explicit feedback  routers provide
from network feedback to end systems
 congestion inferred  single bit indicating
from end-system congestion (SNA,
observed loss, delay DECbit, TCP/IP ECN,
 approach taken by ATM)
TCP  explicit rate for
sender to send at

3-48

End-to-end congestion control. In an end-to-end approach to congestion control,

the network layer provides no explicit support to the transport layer for
congestion control purposes. Even the presence of congestion in the network
must be inferred by the end systems based only on observed network behavior.
TCP must necessarily take this end-to-end approach toward congestion control,
since the IP layer provides no feedback to the end systems regarding network
congestion. TCP segment loss (as indicated by a timeout or a triple duplicate
acknowledgment) is taken as an indication of network congestion and TCP
decreases its window size accordingly.

With network-assisted congestion control, network-layer components (that is,

routers) provide explicit feedback to the sender regarding the congestion state in
the network. This feedback may be as simple as a single bit indicating congestion
at a link.

48
 Case study: ATM ABR congestion control

ABR: available bit rate: RM (resource management)

 “elastic service” cells:
 if sender’s path  sent by sender, interspersed
“underloaded”: with data cells
 sender should use  bits in RM cell set by switches
available bandwidth (“network-assisted”)
 if sender’s path  NI bit: no increase in rate
congested: (mild congestion)
 sender throttled to  CI bit: congestion
minimum guaranteed indication
rate  RM cells returned to sender
by receiver, with bits intact

3-49

ATM (Asynchronous Transfer Mode) ABR (Available Bit Rate) congestion

control is a set of mechanisms designed to manage and control network
congestion in an ATM network for ABR traffic. ABR is a service category in
ATM networks that is used for data traffic, particularly in scenarios where
variable bit rates and best-effort services are required.
ABR congestion control mechanisms aim ATM takes a virtual-circuit (VC)
oriented approach toward packet switching to provide efficient and fair resource
utilization while maintaining network stability. This per-VC state allows a switch
to track the behavior of individual senders (e.g., tracking their average
transmission rate) and to take source-specific congestion-control actions (such as
explicitly signaling to the sender to reduce its rate when the switch becomes
congested). This per-VC state at network switches makes ATM ideally suited to
perform network-assisted congestion control

49
 Case study: ATM ABR congestion control

RM cell data cell

 two-byte ER (explicit rate) field in RM cell

 congested switch may lower ER value in cell
 senders’ send rate thus max supportable rate on path
 EFCI bit in data cells: set to 1 in congested switch
 if data cell preceding RM cell has EFCI set, receiver sets
CI bit in returned RM cell
3-50

With ATM ABR service, data cells are transmitted from a source to a destination
through a series of intermediate switches. Interspersed with the data cells are
resource-management cells (RM cells); these RM cells can be used to convey
congestion-related information among the hosts and switches. When an RM cell
arrives at a destination, it will be turned around and sent back to the sender
(possibly after the destination has modified the contents of the RM cell). It is also
possible for a switch to generate an RM cell itself and send this RM cell directly
to a source. RM cells can thus be used to provide both direct network feedback
and network feedback via the receiver.
A congested network switch can set the EFCI bit in a data cell to 1 to signal
congestion to the destination host. RM cells have a congestion indication (CI) bit
and a no increase (NI) bit that can be set by a Switch.
Each RM cell also contains a 2-byte explicit rate (ER) field. A congested switch
may lower the value contained in the ER field in a passing RM cell.

50
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

3-51

51
 TCP congestion control: additive increase
multiplicative decrease
 approach: sender increases transmission rate (window
size), probing for usable bandwidth, until loss occurs
 additive increase: increase cwnd by 1 MSS every
RTT until loss detected
 multiplicative decrease: cut cwnd in half after loss
additively increase window size …
…. until loss occurs (then cut window in half)
congestion window size
cwnd: TCP sender

AIMD saw tooth

behavior: probing
for bandwidth

time
3-52

AIMD is a mechanism to help TCP manage its sending rate to find an optimal
balance between utilizing available bandwidth and avoiding network congestion.

52
TCP AIMD: more
Multiplicative decrease detail: sending rate is
 Cut in half on loss detected by triple duplicate ACK (TCP Reno)
 Cut to 1 MSS (maximum segment size) when loss detected by
timeout (TCP Tahoe)

Why AIMD?
 AIMD – a distributed, asynchronous algorithm – has been
shown to:
• optimize congested flow rates network wide!
• have desirable stability properties

53
 TCP Congestion Control: details
sender sequence number space
cwnd TCP sending rate:
 roughly: send cwnd
bytes, wait RTT for
last byte last byte
ACKS, then send
ACKed sent, not-
yet ACKed
sent more bytes
(“in-
flight”) cwnd
 sender limits transmission: rate ~
~
RTT
bytes/sec

LastByteSent- < cwnd

LastByteAcked

 cwnd is dynamic, function

of perceived network
congestion
3-54

TCP regulates its sending rate based on the current network conditions and
congestion levels.
LastByteSent: This represents the sequence number of the last byte sent by the
sender.
LastByteAcked: This represents the sequence number of the last byte that has
been acknowledged by the receiver.
cwnd (Congestion Window) determines the maximum number of
unacknowledged bytes (segments) that can be in flight at any given time.

54
TCP Slow Start
Host A Host B
 when connection begins,
increase rate
exponentially until first
loss event:

RTT
 initially cwnd = 1 MSS
 double cwnd every RTT
 done by incrementing
cwnd for every ACK
received
 summary: initial rate is
slow but ramps up
exponentially fast time

3-55

55
TCP: detecting, reacting to loss
 loss indicated by timeout:
 cwnd set to 1 MSS;
 window then grows exponentially (as in slow start)
to threshold, then grows linearly
 loss indicated by 3 duplicate ACKs: TCP RENO
 dup ACKs indicate network capable of delivering
some segments
 cwnd is cut in half window then grows linearly

 TCP Tahoe always sets cwnd to 1 (timeout or 3

duplicate acks)
3-56

56
57
 TCP Tahoe and TCP Reno are two congestion control algorithms.
 TCP Tahoe:It uses a simple
approach known as "slow start" and
"congestion avoidance" to manage
network congestion.
Slow start - It begins by sending a small
number of packets and doubles the
sending rate with each successful
acknowledgment. This phase continues
until a predefined congestion
threshold (ssthresh) is reached.
Congestion avoidance phase - it
increases the sending rate linearly by
only one packet per round trip time.
results in inefficient use of network
resources and can lead to poor
performance

58
  TCP Reno: uses “Slow start &fast
recovery“ and “congestion avoidance”
to handle congestion.
Slow Start & Fast Recovery - It begins by
sending a small number of packets and
doubles the sending When a packet is
lost, it reduces the sending rate slightly
and enters the fast recovery state.
Congestion avoidance -, TCP Reno increases
the sending rate linearly by only one packet
per round trip time.
avoids unnecessary rate reductions, leading to
improved network efficiency by balancing
between responsiveness to congestion and
efficient use of available bandwidth.

59
TCP: switching from slow start to CA
Q: when should the
exponential
increase switch to
linear?
A: when cwnd gets
to 1/2 of its value
before timeout.

Implementation:
 variable ssthresh
 on loss event, ssthresh
is set to 1/2 of cwnd just
before loss event

3-60

60
Slow start, exponential increase Congestion avoidance, additive increase

61
TCP Congestion policy summary
Congestion Policy in TCP
1.Slow Start Phase: Starts
slow increment is exponential
to the threshold.
2.Congestion Avoidance
Phase: After reaching the
threshold increment is by 1.
After this, The sender goes
back to the Slow start phase or
the Congestion avoidance
phase.

62
 Assuming TCP Reno is the protocol experiencing the behaviour shown below, Answer the
following:

a. Identify the intervals of time when TCP slow start is

operating.
b. Identify the intervals of time when TCP congestion avoidance
is operating.
c. After the 16th transmission round, is segment loss detected
by a triple duplicate ACK or by a timeout?
d. After the 22nd transmission round, is segment loss detected
by a triple duplicate ACK or by a timeout?
e. What is the initial value of ssthresh at the first transmission
round? f. What is the value of ssthresh at the 18th transmission
round?
g. What is the value of ssthresh at the 24th transmission round?
h. During what transmission round is the 70th segment sent?
i. Assuming a packet loss is detected after the 26th round by
the receipt of a triple duplicate ACK, what will be the values
of the congestion window size and of ssthresh?
j. Suppose TCP Tahoe is used (instead of TCP Reno), and
assume that triple duplicate ACKs are received at the 16th
round. What are the ssthresh and the congestion window
size at the 19th round?

a. In the Slow Start state, cwnd is initialized to a small value of 1MSS (Maximum Segment Size => the maximum
amount of data that can be grabbed and placed in a segment) and rapidly increased by a value of 1MSS for each
transmission round, i.e. cwnd = cwnd + MSS, and sets the duplicate ACK count AKA dupACKcount = 0. This results
in an effective doubling of the sending rate exponentially. In this figure, this is happening between the first & sixth
transmission rounds. It also kicks back into Slow Start at the 23 transmission round, setting MSS = 1 and increments
up to the end of the data, at transmission round 26.
b. In the Congestion Avoidance state, the system assumes congestion, indicated when the ssthresh (slow start threshold)
is equal to cwnd. ssthresh should always be half the value of cwnd. However, once cwnd >= ssthresh, congestion
avoidance starts, at which point cwnd is increased at a more conservative, linear rate of MSS bytes, i.e. MSS/cwnd,
or by the statement cwnd = cwnd + [MSS·(MSS/cwnd)]. This is between transmission rounds 6 & 16. and and [17,22]
c. After the 16th tranmission round, cwnd is decreased from ~42MSS to ~24MSS (0.5 cwnd + 3 MSS), ~half of the
cwnd after the event in question. If it was a timeout event, it would start at the Slow Start state at 1MSS and increase
exponentially. However, this is clearly a triple duplicate ACK event as it halves the value of cmd and increases in a
linear fashion. If there was a timeout, the congestion window size would have dropped to 1.
d. After the 22nd transmission round, cwnd is reduced to the initial state of cwnd, i.e. cwnd is set to 1MSS and increased
exponentially, indicating that the causal event is a timeout event.
e. The threshold is initially 32, since it is at this window size that slow start stops and congestion avoidance begins
f. The threshold is set to half the value of the congestion window when packet loss is detected. When loss is detected
during transmission round 16, the congestion windows size is 42. Hence the threshold is 21 during the 18th
transmission round.
g. The threshold is set to half the value of the congestion window when packet loss is detected. When loss is detected
during transmission round 22, the congestion windows size is 29. Hence the threshold is 14 (taking lower floor of
14.5) during the 24th transmission round.
h. During the 1st transmission round, packet 1 is sent; packet 2-‐3 are sent in the 2nd transmission round; packets 4-‐7 are
sent in the 3rd transmission round; packets 8-‐15 are sent in the 4th transmission round; packets 16-‐31 are sent in the
5th transmission round; packets 32-‐63 are sent in the 6th transmission round; packets 64 – 96 are sent in the 7th
transmission round. Thus packet 70 is sent in the 7th transmission round.

63
i. The threshold will be set to half the current value of the congestion window (8) when the loss
occurred and congestion window will be set to the new threshold value . Thus the new values
of the threshold and window will be 4.
j. Threshold would be 21, and congestion window size 1.

63
 Consider sending a large file from a host to another over a TCP connection that
has no loss.
a. Suppose TCP uses AIMD for its congestion control without slow start.
Assuming cwnd increases by 1 MSS every time a batch of ACKs is received and
assuming approximately constant round-trip times, how long does it take for
cwnd increase from 6 MSS to 12 MSS (assuming no loss events)?
b. What is the average throughout (in terms of MSS and RTT) for this
connection up through time = 6 RTT?

3-64

a)
Given data:
Assuming cwnd increases by 1 MSS every time a batch of ACKs is received and
assuming approximately constant round-trip times.
Then transmission rate of TCP is =w bytes/RTT
cwnd increases by 1 MSS if every batch of ACKs received.

The below steps are take for cwnd to increase from 6 MSS to 12 MSS:
•1 RTTs to to 7 MSS.
•2 RTTs to 8 MSS.
•3 RTTs to 9 MSS.
•4 RTTs to 10 MSS.
•5 RTTs to 11MSS.
•6 RTTs to 12 MSS.
b)
Given data:
Connection up through time = 6 RTT
Average throughout (in terms of MSS and RTT) =(6+7+8+9+10+11)/6
=8.5 MSS/RTT

64
Host A sends a file consisting of 9 MSS-sized segments to a host B using TCP. Assume
that the 4th segment in the transmission is lost. Assume the retransmission timeout is
T, the one-way latency is d, and that T > 4*d. Ignore the transmission time of the
segments and of the acknowledgements. Also, assume the TCP three-way handshake
has completed, but no data has been transmitted.
Assume no fast retransmission or fast recovery. Draw the time diagram showing each
segment and acknowledgement until the entire file is transferred. Indicate on the
diagram all changes in the cwnd and ssthresh. How long does it take to transfer the
file?

NOTE:
• For Fast Recovery, assume that each duplicate acknowledgment increases cwnd by 1.
• For Fast Recovery, assume that, upon receiving a non-duplicate acknowledgment, cwnd drops back to ssthresh.
• If the value of cwnd is fractional, you should round it to the closest larger integer.
• The transfer time is the time interval measure at source A from the time the first segment is sent until the acknowledgement of
the last segment is received

3-65

65
 Consider the figure below, which plots the evolution of TCP's congestion window at the beginning of each time unit
(where the unit of time is equal to the RTT). In the abstract model for this problem, TCP sends a "flight" of packets
of size cwnd at the beginning of each time unit. The result of sending that flight of packets is that either (i) all packets
are ACKed at the end of the time unit, (ii) there is a timeout for the first packet, or (iii) there is a triple duplicate
ACK for the first packet. In this problem, you are asked to reconstruct the sequence of events (ACKs, losses) that
resulted in the evolution of TCP's cwnd shown below.
1. Give the times at which TCP is in slow start.
2. Give the times at which TCP is in congestion avoidance.
3. Give the times at which TCP is in fast recovery.
4. Give the times at which packets are lost via timeout.
5. Give the times at which packets are lost via triple ACK.
6. Give the times at which the value of ssthresh changes.

1. The times where TCP is in slow start are: 1,2,3,37,38,39,40

2. The times where TCP is in congestion avoidance are:
4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36
3. The times where TCP is in fast recovery are: 20
4. The times where TCP has a loss by timeout are: 36
5. The times where TCP has a loss by triple duplicate ACK are: 19
6. The times where the ssthresh changes are: 20,37
The complete solution is shown in the figure below:

66
 TCP throughput
 avg. TCP thruput as function of window size, RTT?
 ignore slow start, assume always data to send
 W: window size (measured in bytes) where loss occurs
 avg. window size (# in-flight bytes) is ¾ W
 avg. thruput is 3/4W per RTT
3 W
avg TCP thruput = bytes/sec
4 RTT

W/2

3-67

if you want to express the throughput in bits per second (bps), you can convert
bytes to bits by multiplying by 8 (since there are 8 bits in 1 byte):
Average Throughput (in bps) = (3/4) * W * 8 bits per byte

67
TCP Futures: TCP over “long, fat pipes”

 example: 1500 byte segments, 100ms RTT, want

10 Gbps throughput
 requires W = 83,333 in-flight segments
 throughput in terms of segment loss probability, L
[Mathis 1997]:
.
TCP throughput = 1.22 MSS
RTT L

➜ to achieve 10 Gbps throughput, need a loss rate of L

= 2·10-10 – a very small loss rate!
 new versions of TCP for high-speed

3-68

68
TCP Fairness
fairness goal: if K TCP sessions share same
bottleneck link of bandwidth R, each should have
average rate of R/K

TCP connection 1

bottleneck
router
capacity R
TCP connection 2

3-69

69
Why is TCP fair?
two competing sessions:
 additive increase gives slope of 1, as throughout increases
 multiplicative decrease decreases throughput proportionally

R equal bandwidth share

loss: decrease window by factor of 2

congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase

Connection 1 throughput R

3-70

70
Fairness (more)
Fairness and UDP Fairness, parallel TCP
 multimedia apps often connections
do not use TCP  application can open
 do not want rate multiple parallel
throttled by congestion connections between two
control
hosts
 instead use UDP:
 web browsers do this
 send audio/video at
constant rate, tolerate  e.g., link of rate R with 9
packet loss existing connections:
 new app asks for 1 TCP, gets rate
R/10
 new app asks for 11 TCPs, gets R/2

3-71

71