Chapter 3 outline

3.1 transport-layer services

3.5 connection-
oriented
3.2 multiplexing and demultiplexing
transport:
3.3 connectionless transport: UDP TCP
 segment
3.4 principles of reliablestructure
data
transfer  reliable data
transfer
 flow control
 connection
management
3.6 principles of
congestion 3-1
TCP: Overview RFCs: 793,1122,1323,
2018, 2581

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

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

3-4
TCP seq. numbers, ACKs
outgoing segment from sender
sequence numbers: source port # dest port #
sequence number
byte stream acknowledgement number
rwnd
“number” of first checksum urg pointer

byte in segment’s window size

N
data
acknowledgements:
seq # of next sender sequence number space

byte expected sent sent, not- usable not

from other side ACKed yet
ACKed
but not usable
yet sent
cumulative ACK (“in-
flight”)
incoming segment to sender
Q: how receiver source port # dest port #
sequence number
handles out-of-order acknowledgement number
segments A rwnd

A: TCP spec

checksum urg pointer

3-5
 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.
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.

Transport Layer: 3-7

Summary of Seq# & ACK#
Sequence numbers are used Acknowledgments (ACKs) are
to keep track of the bytes in a a critical part of the protocol's
data stream being sent over a reliability mechanism.
network connection.

Each byte of data in a TCP An acknowledgment in TCP

segment is assigned a unique serves to acknowledge the
sequence number, which is receipt of data and inform the
essentially the "number" of sender about the next
the first byte in the segment's sequence number expected
data within the byte stream. from the other side.

This sequence number allows In Cumulative ACK, when the

TCP to order and reassemble receiver acknowledges a
the data correctly at the specific sequence number, it
receiving end. implies that all bytes with
lower sequence numbers have
been received successfully.
 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-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 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,...
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,...
TCP round trip time,
timeout
Q: how to set Q: how to
TCP timeout estimate RTT?
value?  SampleRTT: measured
 longer than time from segment
transmission until ACK
RTT receipt
 but RTT varies  ignore
retransmissions
 too short:  SampleRTT will vary,
premature want estimated RTT
timeout, “smoother”
unnecessary  average several
retransmission recent
measurements,
s 3-12
 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 3-13
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 measure
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: h ttp://gaia.cs.umass.edu/kurose_ross/interactive/
 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₁
2. What is the RTT Deviation₁ = 0.75 * DevRTT₀ + 0.25 * |SampleRTT₁ - EstimatedRTT₁|
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?
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.
Chapter 3 outline
3.1 transport-layer services
3.5 connection-
oriented
3.2 multiplexing and demultiplexing
transport:
3.3 connectionless transport: UDP TCP
 segment
3.4 principles of reliablestructure
data
transfer  reliable data
transfer
 flow control
 connection
management
3.6 principles of
congestion 3-17
TCP reliable data transfer
 TCP creates rdt
service on top of
IP’s unreliable
service let’s initially
 pipelined
consider
segments
 cumulative acks
simplified TCP
sender:
 single
 ignore duplicate
retransmission
acks
timer
 ignore flow
 retransmissions control,
triggered by: congestion
 control
3-18
TCP sender events:
data rcvd from timeout:
app:  retransmit
 create segment segment that
with seq # caused timeout
 seq # is byte-  restart timer
stream number ack rcvd:
of first data  if ack
byte in acknowledges
segment previously
 start timer if
unacked
not already segments
running  update what is
 think of timer as known to be 3-19
 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
timeout

timeout
Seq=100, 20 bytes of data
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,
When a TCP segment is transmitted and the ACK is and so resends a cumulative ACK for both segments
lost, and the TCP timeout mechanism results in received so far, rather than an ACK for just this3-20
fist
another copy of being transmitted and then re-ACKed segment.
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
Seq=100, 20 bytes of data
sender, which then can transmit a
timeout

ACK=100 third segment, knowing that the first

X two have arrived, even though the
ACK=120 ACK for the first segment was lost

Seq=120, 15 bytes of data

cumulative ACK
3-21
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-22
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?
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.
TCP fast
retransmit
 time-out period
TCP fast retransmit
often relatively
long: if sender receives
 long delay 3 ACKs for same
data duplicate
(“triple
before ACKs”),
(“triple duplicate
resending lost ACKs”), resend
packet unacked segment
 detect lost with smallest seq
segments via #
duplicate ACKs.  likely that unacked
 sender often segment lost, so
don’t wait for
sends many timeout
segments back- 3-25
 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
Seq=100, 20 bytes of data
three additional duplicate ACK100s
arrive. With fast retransmit,
X
the arrival of three
duplicate ACK causes the
ACK=100
sender to retransmit its
timeout

oldest unACKed segment, ACK=100

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

fast retransmit after sender

receipt of triple duplicate ACK
3-26
Chapter 3 outline
3.1 transport-layer services
3.5 connection-
oriented
3.2 multiplexing and demultiplexing
transport:
3.3 connectionless transport: UDP TCP
 segment
3.4 principles of reliablestructure
data
transfer  reliable data
transfer
 flow control
 connection
management
3.6 principles of
congestion 3-27
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 TCP
(sender is code
sending)

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

3-28
TCP flow control to application process

 receiver “advertises” RcvBuffer buffered data

free buffer space by
including rwnd value in rwnd free buffer space
TCP header of
receiver-to-sender
segments TCP segment payloads
 RcvBuffer size set via
socket options (typical
default is 4096 bytes) receiver-side buffering
 many operating systems
autoadjust RcvBuffer
 sender limits amount
of unacked (“in-flight”)
data to receiver’s rwnd
value
 guarantees receive
buffer will not overflow 3-29
Chapter 3 outline
3.1 transport-layer services
3.5 connection-
oriented
3.2 multiplexing and demultiplexing
transport:
3.3 connectionless transport: UDP TCP
 segment
3.4 principles of reliablestructure
data
transfer  reliable data
transfer
 flow control
 connection
management
3.6 principles of
congestion 3-30
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: connection state:

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

Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
3-31
Agreeing to establish a
connection
2-way handshake:
Q: will 2-way
handshake
Let’s talk always work in
ESTAB
OK
ESTAB
network?
 variable delays
 retransmitted
messages (e.g.
req_conn(x)) due to
choose x message loss
req_conn(x)

acc_conn(x)
ESTAB  message reordering
ESTAB  can’t “see” other side

3-32
 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( req_conn(
x) 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
terminat forgets x terminat forgets x
es req_conn(x)
es

ESTAB ESTAB
data(x+1) accept
half open connection! data(x+1
(no client!) dup data
)
accepted!
3-33
 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-34
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-35
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-36
Chapter 3 outline
3.1 transport-layer services
3.5 connection-
oriented
3.2 multiplexing and demultiplexing
transport:
3.3 connectionless transport: UDP TCP
 segment
3.4 principles of reliablestructure
data
transfer  reliable data
transfer
 flow control
 connection
management
3.6 principles of
congestion 3-37
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-38
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-  large delays as arrival
connection rate, lin, approaches
throughput: R/2 capacity 3-39
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
lin : original data includes
lout
retransmissions : ldata,
l'in: original
in l
plus
in
retransmitted data

Host A

finite shared output

Host B
link buffers
3-40
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 l'in: original data, plus lout
retransmitted data

A free buffer space!

finite shared output

Host B
link buffers
3-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 lin : original data
packet
copy lout
known to be lostl'in: original data, plus
retransmitted data

A no buffer space!

Host B
3-42
Causes/costs of congestion:
scenario 2
Idealization:
known loss
packets can be
lost, dropped at
router due to full
buffers
 sender only
resends if packetlin : original data lout
known to be lostl'in: original data, plus
retransmitted data

A free buffer space!

Host B
3-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
lin
copy
timeo lout
ut l'in

A free buffer space!

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

Host D
Host C

3-46
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-47
Causes/costs of congestion: insights
 throughput can never exceed capacity

 delay increases as capacity approached

 loss/retransmission decreases effective

throughput
 un-needed duplicates further decreases
effective throughput
 upstream transmission capacity /
buffering wasted for packets lost
downstream
Approaches towards congestion
control
two broad approaches towards congestion
control:
end-end network-
congestion assisted
control: congestion
 no explicit control:
feedback from  routers provide
network feedback to end
 congestion systems
inferred from  single bit
end-system
observed loss, indicating
delay congestion
 approach taken (SNA, DECbit, 3-49
Chapter 3 outline
3.1 transport-layer services
3.5 connection-
oriented
3.2 multiplexing and demultiplexing
transport:
3.3 connectionless transport: UDP TCP
 segment
3.4 principles of reliablestructure
data
transfer  reliable data
transfer
 flow control
 connection
management
3.6 principles of
congestion 3-50
 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
additively increase window size …
after loss …. until loss occurs (then cut window in half)
congestion window size
cwnd: TCP sender

AIMD saw tooth

behavior: probing
for bandwidth

time
3-51
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
TCP Congestion Control:
details
sender sequence number space
cwnd TCP sending rate:
 roughly: send
cwnd bytes,
last byte
ACKed sent, not-
last byte
sent wait RTT for
yet
ACKed
(“in-
ACKS, then
rate ~ more
send cwnd
 sender limits
flight”) ~
RTT
bytes/sec

transmission:
LastByteSent-
bytes
< cwnd
LastByteAcked

 cwnd is dynamic,
function of 3-53
TCP Slow Start
Host A Host B
 when connection
begins, increase
rate exponentially one s e gm
ent

RTT
until first loss
event:
two segm
en ts

 initially cwnd = 1
MSS four segm
ents
 double cwnd every
RTT
 done by
incrementing cwnd time

for every ACK

received 3-54
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
3-55

 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
 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.
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
Implementation:
before
 timeout.
variable ssthresh
 on loss event,
ssthresh is set to
1/2 of cwnd just
before loss event

3-59
Slow start, exponential increase Congestion avoidance,
additive increase
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.
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?
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-63
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-64
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
1. Give shown
the times below.
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.
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
3 W bytes) is ¾ W
avg TCP thruput =
 avg. thruput bytes/sec
is 3/4W per RTT
4 RTT

W/2

3-66
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]:
1.22 . MSS
TCP throughput =
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-67
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-68
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
Connection 2 throughput

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-69
Fairness (more)
Fairness and UDP Fairness, parallel TCP
 multimedia connections
apps often do  application can
not use TCP open multiple
 do not want parallel
rate throttled by connections
congestion
control between two hosts
 instead use  web browsers do

UDP: this
 send  e.g., link of rate R
audio/video at with 9 existing
constant rate, connections: 3-70
 Consider that only a single TCP (Reno) connection uses one 10Mbps link which
does not buffer any data. Suppose that this link is the only congested link between
the sending and receiving hosts. Assume that the TCP sender has a huge file to
send to the receiver, and the receiver’s receive buffer is much larger than the
congestion window. We also make the following assumptions: each TCP segment
size is 1,500 bytes; the two-way propagation delay of this connection is 150 msec;
and this TCP connection is always in congestion avoidance phase, that is, ignore
slow start.
 a. What is the maximum window size (in segments) that this TCP connection can
achieve?
 b. What is the average window size (in segments) and average throughput (in bps)
of this TCP connection?
 c. How long would it take for this TCP connection to reach its maximum window
again after recovering from a packet loss?

3-71