Internet Transport Protocols UDP and TCP

Outline
Internet Transport Protocols
UDP and TCP
Transport Layer Review
UDP Protocol
UDP Characteristics
UDP Functionalities
TCP Protocol
TCP Characteristics
Connection Management
TCP Flow and Congestion Control
Design Issues
TRANSPORT LAYER
Transport Layer Services and
Protocols
Transport layer provides a logical connection
between application processes running on
different hosts
Transport Layer Services
Connection Management
If connection-oriented
Multiplexing and De-Multiplexing
Data Segmentation and Reassembly
Error, Flow and Congestion Control
1

Transport Layer Concepts
Host
Application
Transport
IP
Network
Access
Physical
Internet
Logical Connection
Router
NA
PHY
IP
NA
PHY
Host
Application
Transport
IP
Network
Access
Physical
Internet
Internet Transport Layer Protocols
The IP suite offers two transport protocols
User Datagram Protocol (UDP
Connectionless protocol
“Best Effort” Service
Unreliable
Unordered datagram delivery
No error or flow control
Transmission Control Protocol
Connection-oriented protocol
Reliable, ordered delivery of byte stream
Error, flow and congestion control
No delay guarantees and no bandwidth guarantees
User Datagram Protocol
UDP
UDP Characteristics
UDP is a connectionless datagram service.
No need to establish a connection prior to data transfer
Datagrams may be generated and transmitted at any time.
UDP datagrams are self-contained.
UDP is unreliable:
No acknowledgements for reliable delivery of data.
Checksums cover the header, and only optionally cover
the data.
Contains no mechanism to detect missing or out of
sequence datagrams.
No mechanism for automatic retransmission.
No mechanism for flow control
Sender can over-run the receiver.
2

UDP Service
UDP provides unreliable connectionless
delivery service using IP to transport
datagrams
UDP does not enhance the “best effort” service
provided by IP
UDP provides a mechanism to distinguish
among multiple destinations within a host
The mechanism, referred to as multiplexing, is
based on the notion of “ports”
IP Communication Ports
To communicate, a sender needs to know
IP address of the remote host and
Port number within that host
Multiplexing in UDP
UDP Operation
Port 1 Port 2 Port 3 Port 1 Port 2 Port 3 Port 4
A1
A2
B1
B2
UDP Module
TCP Module
App
App
App
App
RARP Module
IP Module
ARP Module
OS
UDP
Network Interface
Frame
IP address, Protocol,
Port number
IP
UDP uses port number
to de-multiplex packets
3

User Datagram Protocol
UDP Checksum
Physical
Header
UDP Source Port
UDP Message Length
Data
IP Datagram
Physical Data Frame
UDP Destination Port
UDP Checksum
IP Header UDP Header Data
Physical
Trailer
UDP source port is optional (set to 0 if not
used)
UDP checksum is optional (set to 0 if not used)
Using UDP checksum option is useful, however,
since IP checksum does not cover the data portion
of the datagram
It provides the only way to ensure that data has
arrived intact and should be used
Also, the only way to verify the UDP header
UDP Checksum
Appropriate Uses of UDP
The UDP checksum covers more information than is
present in the UDP datagram
A pseudo-header is prepended to the UDP datagram, and a
checksum over the entire object is computed
The pseudo-header contains source and destination IP
addresses, IP protocol type (code 17 for UDP), and UDP
datagram length (the pseudo-header not included)
It guarantees that the datagram has reached the proper
destination
The checksum is computed as a one’s complement sum (sum
modulo 2 16 -1) of all 16-bit words of the header and the pseudo-header
(checksum field is set to 0) and taking one’s complement of the
result
Inward data collection
Outward data dissemination
Request-response
Real-time applications
Streaming of real-time audio and video.
On-time delivery is important
Minimum overhead
4

Transmission Control Protocol
TCP
Transmission Control Protocol
TCP provides a reliable virtual circuit service
TCP guarantees ordered delivery of a stream of data
without loss or duplicatio, despite unreliable network
packet delivery service
TCP assumes little about the underlying
communication system
TCP can be used with a variety of packet delivery
services
Dial-up telephone lines
Local and wide area networks
Low and high-speed long haul networks
TCP Interface Characteristics
Virtual Circuit connection
TCP is full-duplex
TCP is stream-oriented protocol
Data is viewed as a stream of bytes
TCP provides an unstructured stream
TCP does not mark boundaries between streams
Application’s responsibility to understand stream contents
Buffered transfer
TCP collects enough data to fill a reasonably large datagram
before transmission
TCP provides a push mechanism to force transfer, if needed
TCP supports a “stream of
bytes” service
Sender
Receiver
5

Stream Service is emulated using
TCP “Segments”
Sender
Receiver
TCP Data
TCP Data
Segment sent when:
Segment is full
MSS bytes,
Segment not full, but times out, or
“Pushed” by application.
MSS = Maximum Segment Size
TCP MSS
TCP segments are the messages that carry data
between TCP sender and receiver
TCP must decide how many bytes to put into each
message that it sends.
The current size of a TCP segment, CSS, is
determined by two factors
The size of the receiver’s window (bytes) – W
A ceiling on TCP size segment size, never to be
exceeded – Maximum Segment Size (MSS)
CSS = minimum(MSS, W)
TCP Interface Characteristics
TCP specifications describe generally how
applications use TCP, but do not dictate details
of an interface
There have been numerous implementations of TCP
TCP Reno, TCP Tahoe, TCP Las Vegas, SACK TCP, ….
TCP Connection Establishment
Initially, a service user at site 1 issues a passive
open function
Willingness to accept connections from other users
TCP returns a passive open confirm with local
connection name to use when a connection is set up
Service user at site 1 can start “listening” for
requests
6

TCP Connection Establishment
Three-way Handshake
To establish a connection with service at site 1,
a user at side 2 issues an active open
Active open contains data needed to set up the
connection
This begins a three-way handshake
Send data unit
with SYN bit set
and seq# = x
Receive data unit
SYN x
ACK x+1/SYN y
Receive data unit
Send data unit
with SYN bit set
and seq# = y,
acknowledge x+1
Send data unit
acknowledge y+1
ACK y+1
Receive data unit
Connection Termination
Connection Termination
TCP connections are terminated with “graceful
close”
Graceful close ensures that the connection is
terminated after all data had been received
One side issues Close request, and is not permitted
to transmit data after sending it
The other side acknowledges it, but can send data
until it sends Close request too
After the second Close request is acknowledged, the
connection is closed
No data transmission
from this side
FIN x
ACK x+1/ Data y
ACK y+k+1
FIN y+k
ACK y+k+1
Last segment sent by receiver
• Sequence number : y
• Length: k
7

TCP Segment Format
TCP Segment Fields
0 15 31
Data
Offset
Source Port
Reserved
Sequence Number
Acknowledgement Number
U
R
G
Checksum
A
C
K
P
S
H
R
S
T
Options
S
Y
N
F
I
N
Data
Destination Port
Window
Urgent pointer
Padding
Source and Destination Port Number
16-bit – end-point identifiers
Sequence Number
32-bit – number of the first data octet in this segment except for
when the SYN flag is set
When the SYN flag is set, sequence number identifies “the Initial
Sequence Number” and the first data octet is ISN+1
Acknowledgement Number
32-bit – number of the next octet expected to receive
Data Offset
4-bit – number of 32-bit words in the header (including options)
Header Length
TCP Flags
URG: segment contains urgent data:
urgent pointer points to the last octet of urgent data
ACK: acknowledgement field is significant
PSH: segment is sent with the push function
RST: reset the connection
Closes a half-open connection
SYN: synchronize sequence numbers
Used during open request
FIN: no more data from sender
Used during close request
TCP Segment Fields
Window – 16-bit number of unacknowledged octets that
the sender is allowed to transmit
Maximum value limits the value of the window size to 216 , unless
“window scale” option is used
Checksum – 16-bit one’s complement of a one’s
complement sum of all 16-bit words of the segment and a
pseudo-header (the checksum field is set to zero)
The pseudo-header contains the sender’s and receiver’s IP
addresses, the protocol type (code 6 for TCP), and the segment
length field)
A zero padding is added to the segment to make the segment
multiple of 16 bits
The pseudo-header and the padding are not transmitted
8

Pseudo-header
Out-of-Band Data
Source address (32-bits)
Destination address (32-bits)
00000000 Protocol
00000110
TCP segment length
Out-of-band data is needed to handle abort or
program interrupt signals
These “signals” should not wait for the octets
already in the TCP stream to be transmitted
Telnet uses this feature to send “interrupt” commands
TCP uses URGENT feature to accomodate
out-of-band data
Out-of-Band Data
Out-of-Band Data
User
Process
Out-of-Band
Data
Send
Buffer
Network
Out-of-Band
Data
Receive
Buffer
Application is required to check on the “Out-of-Band”
data stream before processing regular data stream
User
Process
TCP notifies associated application of the
beginning and end of urgent mode
How TCP informs the application depends on the
operation system
Urgent data is detected by the URG flag set
and retrieved by the urgent pointer
Unfortunately, TCP does not denote the beginning
of the urgent data in the segment
It’s up to the application to decide, where the urgent data
starts
9

TCP Options
Originally, one option, maximum segment size
was defined
The 16-bit option may be used only in the initial
connection request segment
If this option is not used, any segment size is allowed
Later, two other options have gained
widespread acceptance
Window scale factor
Timestamps
TCP Options
End of options
Kind = 0
(8 bits)
No operation : padding
Kind = 1
(8 bits)
TCP Options
Maximum Segment Size
Window Scale Option – Purpose
Kind = 2
(8 bits)
Length = 4
(8 bits)
Maximum Segment Size
(16 bits)
Window Scale Factor
Kind = 3
(8 bits)
Length = 3
(8 bits)
Shift Count
(8 bits)
10

Window Scale Option
The option increases the TCP receive window above its
maximum value of 65,535 bytes
A much better alternative than changing the TCP header to
accomodate the need for larger windows
When window scale option is used, the value of the field is
multiplied by 2 F , where F is between 1 and 14, is a scale
option specified in the initial connection request segment
A value F = 14 results in a maximum window size of over 10 9 bytes
(65535 2 14 )
Internally, TCP maintains a “real” window size of 32 bits
The option can only appear in a SYN segment
Thus, scale factor is agreed upon and fixed in each direction at the
connection setup
TCP Options
Timestamp – Used for 2 distinct mechanisms
RTT Measurement (RTTM) – To track the RTT for data
in order to identify changes in latency that may require ack
timer adjustment
Protect Against Wrapped Sequences (PWAS)
Kind = 8
(8 bits)
Length = 10
(8 bits)
Timestamp Value (LSB)
(16 bits)
Timestamp Echo Reply
(LSB) (16 bits)
Timestamp Value (MSB)
(16 bits)
Timestamp Echo Reply
(MSB) (16 bits)
This option can be used throughout the TCP connection
TCP FLOW CONTROL
TCP Data Flow Control
TCP uses a variable size window protocol to
regulate the flow control
Its unique feature is that it decouples
acknowledgements of received data units from
the granting of a permission to send additional
data
Each acknowledgement contains a window
advertisement
Increased window advertisement allows sender to proceed with
sending octets not acknowledged yet
Decreased window advertisement causes the sender to stop at
the boundary of the window
11

TCP Sliding Window
Data
AcK’d
Window Size
Outstanding
Un-Ack’d data
Data OK
to send
Data not OK
to send yet
Window is meaningful to the sender
Current window size is “advertised” by receiver
Usually 4k – 8k Bytes when connection set-up
Acknowledgements and
Retransmission
TCP uses a cumulative acknowledgement scheme
ACK reports on the number of octets so far accumulated and
specifies the next octet expected
Advantages
ACKs are easy to generate unambiguously
Lost ACKs do not necessarily force a retransmission
Disadvantages
Receiver does not report on the segments successfully received, if
one intermediate segment is lost
Timeout mechanism becomes very crucial
TCP Window Mechanisms
TCP uses a credit allocation scheme
The sender includes the sequence number of the
first octet in the segment data field
The receiver acknowledges the incoming segment
with a message of the form (ACK = i, WIN = j )
All octets up to i-1 are acknowledged
Permission is granted to send an additional window of j
octets starting at i through i+j-1
TCP Credit Allocation Scheme
The credit allocation scheme is flexible
Assume last message issued by receiver carries
ACK = i and WIN = j
To increase the credit by an amount k > j, when no additional
data have arrived, the receiver issues ACK = i and WIN = k
To acknowledge an incoming segment containing m octets of
data (m < j) without granting additional credits, the receiver
issues ACK = i+m and WIN = j-m
The receiver can issue cumulative acks, and is not
required to issue an ack immediately after receiving a
segment
12

TCP Window Control
Effect of Window Size
Sender
Receiver
1001 2400 1001 2400
SN 1001
1601 2400 LEN 600
1601 2400
ACK 1601
1601 2400 WIN 800 1601 4000
ACK 1601
1601 4000
WIN 2400
1601 4000
TCP Actual Throughput
TCP performance can be affected by several complicating
factors:
In most cases, a number of TCP connections are multiplexed over
the same network interface, so each connection is only allocated a
fraction of bandwidth
This reduces R, therefore S as well
TCP connections usually involve a hop across multiple networks
Router delay becomes the biggest contributor to D
Actual data rate may be reduced below R if a bottleneck router exists
along the path
If any segment is lost and must be retransmitted, throughput is
reduced
TCP Sliding Window
Fundamental Questions
How much data can a TCP sender have
outstanding in the network?
How much data should TCP retransmit
when an error occurs?
Just selectively repeat the missing data?
How does the TCP sender avoid overrunning
the receiver’s buffers?
13

TCP Flow Control
TCP Flow Control
Receiver throttles sender by advertising a
window size no larger than the amount of data it
can buffer.
To avoid buffer overflow at the receiver side, the
following invariant is always true:
LastByteRcvd - LastByteRead

TCP Congestion Control
TCP CONGESTION CONTROL
TCP sliding window provides an adequate
mechanism to control the data flow between the
sender and the receiver
TCP sender still needs to perform congestion control to
ensure that the network can handle the window agreed upon
by the sender and the receiver
TCP relies on ACKs to control flow and congestion
If the ACK is not received on time, TCP retransmits the
segment
An absence of an ACK signals congestion in the network
TCP Window Control
TCP Timeout Timers
TCP does not rely on an explicit negative
acknowledgement to detect errors
TCP relies exclusively on positive ACKs and
retransmissions when an ACK does not arrive within
a given period of time
Retransmission TimeOut (RTO) should be on
the order of RTT (Round-Trip Time)
RTT and its statistics, however, vary considerably as
the Internet load changes
Thus timers play a major role in TCP congestion
Sender
Receiver
Data
Round-trip time (RTT)
ACK
Data
Retransmission TimeOut (RTO)
ACK
Guard
Band
Estimated RTT
15

Timer Values
The timeout timer should be set to a value
somewhat longer than the RTT
Two strategies can be used to set the timer
value:
Static timer value
Adaptive timer value
Static Value Timers
A fixed value timer based on the Internet
typical behavior is used for RTO value
The strategy suffers from the inability to respond to
Internet changing conditions
A high value leads to sluggish service and unnecessary
long time of response to a lost packet
A low value leads to a positive feedback condition that
causes more retransmissions (some unnecessary) in a case
of congestion
Adaptive Timers
TCP keeps track of the time taken to acknowledge data
segments and sets its retransmission timers based on the
average of the observed delays
Can this be trusted?
Cumulative ACK by the peer may delay an acknowledgement
If a segment has been retransmitted, the sender cannot determine
which segment (the original or the retransmitted), the ACK does
correspond to
Internet laod may change suddenly
Still, tracks better RTT variation than the fixed strategy
Adaptive Timers
Smoothed Average
An estimated value of RTT, SRTT(), is computed as a
smoothed average
SRTT
k
1
SRTT k
1
RTT
k
1
The smaller the value of , the greater weight of more
recent observations
With small values of , the average quickly reflects a rapid change in
the observed quantity
A disadvantage, a brief surge in the observed value followed by a
return to the average causes strong fluctuations
= 0.9 is recommended
16

Adaptive Timers
Adaptive Timers
Given an SRTT value, what should be the RTO value?
Use a constant value:
RTO k
1 SRTTk
1
is not proportional to SRTT
If SRTT(k+1) is large, may become insignificant,
relatively
As a consequence, fluctuations in the RTT cause unnecessary
retransmissions
If SRTT(k+1) value is small, may become relatively
large
As a consequence, the mechanism depends solely on value, not
reacting to changing conditions
TCP Congestion Control
TCP Congestion Control
The rate at which a TCP entity can send data is
determined by the rate of incoming ACKs to
previous segments (with granted credit)
This rate is determined by the “bottleneck” in the
round trip path between the source and the
destination
Congestion control in the Internet is complex
IP is a connectionless, stateless protocol
No provision for determining congestion, let alone control it
TCP provides only end-to-end flow control and relies on
implicit feedback to deduce the presence of congestion
ICMP quench messages are too crude to provide any effective
control
No cooperative, distributed algorithm exists between
different TCP entities
On the contrary, TCP entities may be selfish and do not cooperate to
maintain some level of control
17

TCP Congestion Control
The only tool is the sliding-window flow
control and error control mechanisms
Not enough, in a dynamic environment
A number of clever techniques have been
developed and added to control congestion in
the Internet
Mechanisms for congestion detection
Mechanisms for congestion avoidance
Mechanisms for congestion recovery
TCP Flow and Congestion Control
TCP is self-clocking: returning of ACKs
functions as pacing signal
After an initial burst, the sender’s segment rate
matches the arrival rate of ACKs
Sender rate equals the rate of the slowest link on the path
This way TCP senses the bottleneck and regulates its rate
accordingly
TCP Flow and Congestion Control
Network Bottleneck
Pb is the minimum segment spacing on the slowest link
Pr is the segment spacing at the receiver
As is the ACK spacing at the sender
Ab is the ACK spacing at the bottleneck
Pr
Pb
Data
Pb = Pr = Ab = As
TCP Flow and Congestion Control
Problem caused by the fact that the sender does not know
where is the bottleneck: the network or the receiver
If ACKs arrive relatively slow due to network congestion, then the
sender must transmit segments at a rate slower than the ACKs
On the other hand, if slow pace is due to the receiver, this pace
should dictate the transmission policy
Thus, TCP sliding window must be enhanced to factor in
the network congestion
ACK
As
Ab
18

Probability
Average Queueing Delay
Improving TCP Congestion
Effectiveness
Three techniques have been suggested for
retransmission timer management
RTT Variance Estimation
Exponential Backoff
Karn’s Algorithm
Four techniques have been suggested for
window management
Slow Start
Dynamic Window Sizing on Congestion
Fast Retransmission
Fast Recovery
RTT Variance Estimation
Factors of Influence
RTT exhibits relatively high variance due to three
sources
A low data rate on the TCP connection relative to the
progation time makes the transmission delay relatively
important in the RTT estimation
Thus, high variation in datagram sizes induces high variation in
RTT
SRTT estimator can be heavily influenced by characteristics of
the data, that have nothing to do with the network
Abrupt changes in the Internet load and condition
TCP receiver may use cumulative ACKs
RTO Scheme Revisited
TCP Timeout Estimates
TCP original scheme suggests to compute
RTO as follows
RTO k
1 SRTTk
1 ; 2
There will be some (unknown) distribution
of RTTs.
We are trying to estimate an RTO to
minimize the probability of a false timeout.
Router queues grow when there is more
traffic, until they become unstable.
As load grows, variance of delay grows
rapidly.
If RTT has low variance, it results in
unnecessary high values of RTO
In unstable environments, it may be
inadequate to protect against retransmissions
variance
mean
RTT
Variance
grows rapidly
with load
Load
(Amount of traffic
arriving to router)
19

RTT Variance Estimates
A more effective approach is to estimate
RTT standard deviation
However, too costly as it involves square and
square root calculation
A less expensive alternative: the mean
deviation
MDEV X E X E X
Dynamic Estimate of RTT
Variability
The algorithm to dynamically estimate the
variability in estimating RTT uses an
exponential smoothing technique
SRTT k
1 SRTT k
1
RTT
k
1
SERR k
1 RTT k
1 SRTT k
1
SDEV k
1 '
SDEV k
1
'
SERR
k
1
RTOk
1 SRTT k
1 SDEV k
1
7
;
8
'
3
;
4
4
TCP Congestion Control
RTT variance estimation is efficient in detecting
data loss
It may not be sufficient in a case of retransmission
Two other factors must be taken into consideration
when managing retransmission timers in a case of
congestion:
What RTO value should be used on a retransmitted
segment (i.e., when timeout occurs)?
Exponential RTO Backoff
What RTT samples should be used as input to compute
SRTTT( ) in a case of retransmission?
Karn’s Algorithm
Exponential RTO Backoff
Timeouts are usually due to congestion
Maintaining the same RTO value for retransmission is ill
advised
May cause sustained congestion due to the development of a
similar pattern of behavior of all active TCP connections
All sources wait for local RTO time and retransmit again
A more efficient scheme must try to increase RTO values
to give the Internet more time to clear the congestion
Exponential RTO Backoff scheme
RTO = q RTO
Typically q = 2
20

RTT Samples Ambiguity
Ambiguity may occur when a timeout occurs
and the same segment is retransmitted
Upon receiving an ACK, the sender has no way of
determining which segment, the first or the second,
has been acknowledged
Feeding the resulting RTT into the RTO
algorithm may lead to false measurements and
oscilations
Retransmission and Timeouts
TCP Source cannot distinguish between these
two cases
Wrong RTT
Sample
Host A
Retransmission
Host B
Wrong RTT
Sample
Host A
Retransmission
How can we estimate RTT when packets are
retransmitted?
Host B
RTT Samples – Karn’s Algorithm
Karn’s algorithm uses the following rules
Do NOT use the measured RTT for a retransmitted
segment to update SRTT and SDEV
Calculate the backoff RTO when a retransmission occurs
RTO = q RTO ; (typically q = 2)
Use the backoff RTO value for succeeding segment until
an acknowledgement arrives for a segment that has not
been retransmitted
When the acknowledgement is received to an unretransmitted
segment, use the normal algorithm to update SRTT and SDEV
and compute future RTO values
TCP Congestion Control
Armed with an efficient RTO estimation mechanism,
use lack of acknowledgements as congestion
indication and maintain a congestion window to
estimate congestion in the network
CongestionWindow :: a variable maintained by the TCP
source for each connection.
TCP is modified such that the maximum number of
bytes of unacknowledged data allowed is the
minimum of CongestionWindow and
AdvertisedWindow
AllowedWindow :: Min (CongestionWindow , AdvertisedWindow)
21

Window Management Techniques
A number of strategies have been suggested to
effectively manage the sending window
Slow Start
Dynamic Window Sizing on Congestion
Fast Retransmission
Fast Recovery
These techniques are incorporated in all
modern implementations of TCP
Slow Start
TCP is self-clocking and paces itself
approximately to the rate of the bottleneck
At the initialization phase, no such pacing is
available for guidance
Sending at full window speed is ill-advised as it
may cause large packet drops
Some means of gradually expanding the initial
window until pacing takes over is needed
“Slow Start” is the procedure recommended for
initial window expansion until packing takes over
Phases of Congestion Control
TCP Slow Start
The goal of TCP Slow Start is to discover
roughly the proper sending rate quickly
Whenever starting traffic on a new connection,
or whenever increasing traffic after congestion
was experienced:
Intialize cwnd =1
Each time a segment is acknowledged, increment
cwnd by one (cwnd++).
Continue until
The threshold, ss_thresh, is reached or Packet Loss
The variable ssthresh can be thought of as an estimate of the level below which
congestion is not expected.
22

TCP Slow Start
Dynamic Window Sizing on Congestion
Each ACK adds 2
“credits”
This gives the sender the
permission to send two
segments
Slow start increases
rate exponentially fast
Rate is doubled every
RTT!
cwnd = 1
cwnd = 2
cwnd = 4
cwnd = 8
Slow Start enables the sender to quickly
determine a reasonable window size for the
connection
What happens if packet loss (timeout) occurs?
This could be a sign of congestion, but it is not clear how
serious the congestion is
Would resetting cwnd = 1 and restarting slow-start be
enough?
This may not be conservative enough
Need a more aggressive response
Congestion Avoidance: Additive
Increase
After exiting slow start, slowly increase cwnd to probe for
additional available bandwidth
Competing flows may end transmission
May have been “unlucky” with an early drop
If cwnd > ss_thresh then
each time a segment is acknowledged
increment cwnd by 1/cwnd (cwnd += 1/cwnd).
cwnd is increased by one only if all segments have been
acknowledged
Increases by 1 per RTT, vs. doubling per RTT
Congestion Avoidance: Additive
Increase
When a timeout occurs, use these rules:
Set a slow-start threshold, ssthresh, equal to half of
cwnd
ssthresh = cwnd / 2
Set cwnd = 1 and perform slow start until cwnd =
ssthresh
At that time, cwnd is increased only by 1, for every ACK
received
For cwnd ssthresh, increase cwnd by 1 for each
RTT
91
23

Cwnd (in segments)
Example of Slow Start + Congestion
Avoidance
cwnd = 1
Assume that ss_thresh = 8
14
12
10
8
ssthresh
6
4
2
0
t=0
t=2
t=4
Roundtrip times
t=6
cwnd = 2
cwnd = 4
cwnd = 8
cwnd = 9
cwnd = 10
TCP Improvement
FAST RETRANSMIT
FAST RECOVERY
Acknowledgments in TCP
Fast Retransmission Policy – TCP Tahoe
• Receiver sends ACK to sender
ACK is used for flow control, error
control, and congestion control
• ACK number sent is the next sequence
number expected
• Delayed ACK: TCP receiver normally
delays transmission of an ACK (for
about 200ms)
Why?
• ACKs are not delayed when packets are
received out of sequence
Why?
1K SeqNo=0
AckNo=1024
1K SeqNo=1024
AckNo=2048
1K SeqNo=2048
1K SeqNo=3072
AckNo=2048
Lost segment
When a segment is lost, original TCP waits for an
ACK that’s not coming and eventually times-out.
It is often the case that of the segments sent after the lost
segment arrive at the receiver.
For each segment received, the receiver sends a
duplicate ACK, notifying the sender that the receiver
is waiting for the missing segment.
TCP Tahoe interprets duplicate ACK’s as an
indication that a segment was lost.
95
24

Fast Retransmit
Fast Recovery
cwnd=12
sshtresh=5
1K SeqNo=0
1K SeqNo=0
• If three or more duplicate ACKs
are received in a row, the TCP
sender considers the segment
as lost.
• Then TCP performs a
retransmission of the missing
segment, without waiting for a
timeout to happen.
duplicate
duplicate
AckNo=1024
AckNo=1024
AckNo=1024
1K SeqNo=1024
1K SeqNo=2048
1K SeqNo=3072
1K SeqNo=1024
• Fast recovery avoids slow start after a
fast retransmit
• Intuition: Duplicate ACKs indicate that
data is getting through
• After three duplicate ACKs set:
Retransmit “lost packet”
ssthresh = cwnd/2
cwnd = cwnd+3
Enter congestion avoidance
Increment cwnd by one for each
additional duplicate ACK
cwnd=12
sshtresh=5
cwnd=12
sshtresh=5
cwnd=12
sshtresh=5
AckNo=1024
AckNo=1024
AckNo=1024
1K SeqNo=1024
1K SeqNo=2048
1K SeqNo=3072
1K SeqNo=1024
1K SeqNo=4096
• Enter slow start:
ssthresh = cwnd/2
cwnd = 1
1K SeqNo=4096
• When ACK arrives that acknowledges
“new data” (here: AckNo=2028), set:
cwnd=ssthresh
enter congestion avoidance
cwnd=9
sshtresh=9
AckNo=2048
97
98
Fast Recovery
Summary of TCP Behavior
cwnd
(initial) ssthresh
fast-retransmit
fast-retransmit
new ACK
new ACK
Slow Start Congestion Avoidance
timeout
Time
TCP
Variation
Tahoe
Reno
NewReno
Response to 3
dupACK’s
Do fast retransmit,
enter slow start
Do fast retransmit,
enter fast recovery
Do fast retransmit,
enter modified fast
recovery
• When entering slow start, if connection is
new,
ssthresh = arbitrarily large value
cwnd = 1.
else,
ssthresh = max(flight size/2, 2*MSS)
cwnd = 1.
• In slow start ++cwnd on new ACK
Response to Partial ACK
of Fast Retransmission
++cwnd
Exit fast recovery, deflate
window, enter congestion
avoidance
Fast retransmit and deflate
window – remain in
modified fast recovery
Response to “full” ACK of
Fast Retransmission
++cwnd
Exit fast recovery, deflate
window, enter congestion
avoidance
Exit modified fast recovery,
deflate window, enter
congestion avoidance
• When entering either fast recovery or
modified fast recovery,
ssthresh = max(flight size/2, 2*MSS)
cwnd = ssthresh.
• In congestion avoidance
cwnd += 1*MSS per RTT
25

Summary
Transmission Control Protocol Discussion
Segment format and functionality
TCP Flow Control
TCP Congestion Control
AIMD strategy
26