1. Transport Layer
Part 2
TCP Flow Control, Congestion Control, Connection Management, etc.

2. Encapsulation in TCP/IP
IP datagram
Due to router congestion, the packets sent by the sending End system is lost. When that happens, the sending end system is alerted of congestion if it does not receive an acknowledgement for the packets it sent. TCP provides a congestion control service that forces the End systems to decrease the rate at which packets are sent during periods of congestion.
You can view the applet from Kurose’s site demonstrating network congestion.

3. TCP: Overview full duplex data: point-to-point:
Error detection, retransmission, cumulative ACKs, timers, header fields for sequence and ACK numbers
full duplex data:
bi-directional app. data flow in same connection
MSS: maximum segment size
connection-oriented:
handshaking (exchange of control msgs) init's sender, receiver state before data exchange
flow controlled:
sender will not ''flood'' receiver with data
point-to-point:
one sender, one receiver
reliable, in-order byte stream:
no message boundaries
pipelined:
TCP congestion and flow control set window size
send & receive buffers
TCP only allows a POINT-TO-POINT connection, which means only one sender and one receiver can be catered to at a time. It does not allow for multicasting where one sender can deliver the same message to multiple receivers. Contrary to our previous protocols, TCP uses reliable in-order byte stream delivery (byte numbers) instead of packet numbers. It facilitates a pipelined approach to segment passing between two hosts using send and receive buffers. When an application creates data to be sent, TCP relays that data into the TCP send buffer, then grabs chunks of data from the buffer and put them in a SEGMENT. The maximum data that can be placed in a SEGMENT depends on the maximum segment size (MSS) defined in the O.S.
Moreover, TCP provides full-duplex service, allowing one HOST to send data and receive data at the same time. Also, as we have discussed before, it is classified as a connection-oriented protocol requiring a 3-way handshake, and provides flow-control to prevent the sender from “flooding” the receiver with too much data.
application
application
socket
writes data
reads data
socket
door
door
TCP
TCP
send buffer
receive buffer
segment

4. Recall Reliable Data Transfer Mechanisms: Checksum Timer
application
application
writes data
socket
reads data
socket
door
door
TCP
TCP
send buffer
receive buffer
Packet ->
Reliable Data Transfer Mechanisms:
Checksum
Timer
Sequence number
ACK
NAK
Window, pipelining
- Verification of integrity of packet
- Signals necessary re-transmission is required
- Keeps track of which packet has been sent and received
- Indicates receipt of packet in good or bad form
- Allows for the sending of multiple yet-to-be-acknowledged packets

5. Internet Checksum Example
Note
When adding numbers, a carryout from the most significant bit needs to be added to the result
Example: add two 16-bit integers
data
Kurose and Ross forgot to say anything about wrapping the carry and adding it to low order bit
wraparound 1
sum
checksum
To check:

6. Connection Oriented Transport: TCP
TCP Segment Structure
SEQ and ACK numbers
Calculating the Timeout Interval
The Simplified TCP Sender
ACK Generation Recommendation (RFC 1122, RFC 2581)
Interesting Transmission Scenarios
Flow Control
TCP Connection Management

7. TCP segment structure Header source port # dest. port #
32 bits
URG: urgent data
(generally not used)
counting
by bytes
of data
(not segments!)
Header
source port #
dest. port #
sequence number
ACK: ACK #
valid
acknowledgement number
head
len
not
used
PSH: push data now
(generally not used) U A P R S F
rcvr window size
# bytes the
rcvr is willing
to accept
checksum
URGent data ptr
RST, SYN, FIN:
connection established
(setup, tear down
commands)
Options (variable length)
The TCP segment structure can be split into two primary components: the Header fields and the Data field.
All the underlying principles we have covered so far are implemented through the utilization of specific header fields in the TCP SEGMENT.
We could easily identify the components we have used in our discussion of reliable data transfer protocols. As can be seen in the structure, we have:
SOURCE PORT – for multiplexing data from the upper-layer applications
DESTINATION PORT – for demultiplexing data to the upper-layer applications
SEQ NUMBER
ACK NUMBER
A Flag – indicates if ACK number is valid
WINDOW SIZE
OPTIONS (varies according to options set)
- used for setting the MSS, or negotiating for the Windows Scaling factor, and TIME STAMPING
In addition, there are other fields less frequently used like URG and PTR URGENT DATA fields that specifies the existence of URGENT data, and its location (last byte location), PSH which tells the receiver to push data to the upper-layer immediately
application
data
(variable length)
Internet
checksum
(as in UDP)
We can view these
teeny-weeny
details using Ethereal.
In practice, PSH, URG, and the Urgent Data Pointer are not used.

8. Example
Suppose that a process in Host A wants to send a stream of data to a process in Host B over a TCP connection.
Assume:
Data stream: file consisting of 500,000 bytes
MSS: 1,000 bytes
First byte of data stream: numbered as 0
TCP constructs 500 segments out of the data stream.
500,000 bytes/1,000 bytes = 500 segments

9. TCP sequence #'s and ACKs
...
Segment 1
Segment 2
Sequence. Numbers (#'s):
byte stream 'number' of first byte in segment's data
Do not necessarily start from 0, use random initial number R
Segment 1: 0 + R
Segment 2: R etc...
ACKs (acknowledgment):
Seq # of next byte expected from other side (last byte +1)
Cumulative ACK
If received segment 1, waits for segment 2
E.g. Ack= R (received up to 999th byte)
Instead of thinking in packet numbers, sequence numbers used by TCP is in terms of bytes, in particular the first byte-stream number in the segment’s data to be sent to the other HOST.
ACKs on the other hand denotes the sequence number of the next byte expected to be received from the other HOST.
In the example, the HOST is saying that the data segment I’m sending goes with data that starts with SEQ NUM., that is, the byte-stream number of the first byte in the segment’s data.
Moreover, the HOST is saying that I’m expecting data starting from ACK NUMBER and beyond.

10. TCP sequence #'s and ACKs
simple telnet scenario (with echo on)
client
Q: how receiver handles out-of-order segments
A: TCP specs. does not say, - decide when implementing
server
Host A
Host B
User
types
'C'
Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
'C', echoes
back 'C'
I’m sending data starting at seq. num=42
Seq=79, ACK=43, data = ‘C’
Assuming that the starting sequence numbers for Host A and Host B are: 42 and 79 respectively
Send me the bytes from 43 onward
ACK is being piggy-backed on
server-to-client data
host ACKs
receipt
of echoed
'C'
Seq=43, ACK=80
time

11. Yet another server echo example
Host A
Host B
Host A:
seq=42
ack=79
seq=47
ack=84
User
types
'Hello'
Seq=42, ACK=79, data = ‘Hello’
Host B:
seq=79
ack=47
seq=84
ack=50
host ACKs
receipt of
'Hello',
echoes back
'Hello'
Seq=79, ACK=47, data = ‘Hello’
host ACKs
receipt
of echoed
'Hello'
send something
else
Seq=47, ACK=84, data = ‘200’
Seq=84, ACK=50, data = ‘200’
time
ACK tells about up to what byte has been received and what is the next starting byte the host is expecting to receive

12. TCP Round Trip Time and Timeout
Main Issue: How long is the sender willing to wait before re-transmitting the packet?
Q: how to set TCP timeout value?
longer than RTT *
note: RTT will vary
too short: premature timeout
unnecessary retransmissions
too long: slow reaction to segment loss
* RTT = round trip time
Q: how to estimate RTT?
SampleRTT: measured time from segment transmission until ACK receipt
ignore retransmissions, cumulatively ACKed segments
SampleRTT will vary, we would want estimated RTT to be ''smoother''
use several recent measurements, not just current SampleRTT

13. TCP Round Trip Time and Timeout
EstimatedRTT = (1-x) * EstimatedRTT + x * SampleRTT
Exponential weighted moving average
influence of given sample decreases exponentially fast
typical value of x: (RFC 2988)
Setting the timeout
EstimatedRTT plus ''safety margin''
large variation in EstimatedRTT -> larger safety margin
recommended value of x: 0.25
Deviation = (1-x) * Deviation +
x * |SampleRTT-EstimatedRTT|
Timeout = EstimatedRTT + (4 * Deviation)

14. Sample Calculations
EstimatedRTT = * EstimatedRTT * SampleRTT
EstimatedRTT after the receipt of the ACK of segment 1:
EstimatedRTT = RTT for Segment 1 = second
EstimatedRTT after the receipt of the ACK of segment 2:
EstimatedRTT = * * =
EstimatedRTT after the receipt of the ACK of segment 3:
EstimatedRTT = * * =
EstimatedRTT after the receipt of the ACK of segment 4:
EstimatedRTT = * * =
EstimatedRTT after the receipt of the ACK of segment 5:
EstimatedRTT = * * =
EstimatedRTT after the receipt of the ACK of segment 6:
EstimatedRTT = * * =

15. RTT Samples and RTT estimates
300
250
200
150
100
Estimated RTT
Sample RTT
RTT (msec.)
The variations in the SampleRTT are smoothed out in the computation of the EstimatedRTT.
time

16. An Actual RTT estimation:

17. FSM of TCP for Reliable Data Transfer
Simplified TCP sender, assuming:
event: data received
from application above
- one way data transfer
- no flow, congestion control
create, send segment
wait
for
event
wait
for
event
event: timer timeout for
segment with seq. number y
retransmit segment
event: ACK received,
with ACK number y
process ACK

18. Associated with the oldest unACKed segment
SIMPLIFIED TCP
SENDER
Assumptions:
sender is not constrained by TCP flow or congestion control
that data from above is less than MSS in size
that data transfer is in one direction only
00 sendbase = initial_sequence number
01 nextseqnum = initial_sequence number 02
loop (forever) {
switch(event)
event: data received from application above
create TCP segment with sequence number nextseqnum
If (timer is currently not running) start timer for segment nextseqnum
pass segment to IP
nextseqnum = nextseqnum + length(data)
event: timer timeout
retransmit not-yet-ACKed segment with smallest Seq. #
Start timer
event: ACK received, with ACK field value of y
if (y > sendbase) { /* cumulative ACK of all data up to y */
sendbase = y
If (there are currently any not-yet-ACKed segments)
start timer }
} /* end of loop forever */
Associated with the oldest unACKed segment

19. TCP sender (simplified)
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event)
event: data received from application above
create TCP segment with sequence number NextSeqNum
if (timer currently not running)
start timer
pass segment to IP
NextSeqNum = NextSeqNum + length(data)
event: timer timeout
retransmit not-yet-acknowledged segment with
smallest sequence number
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments) }
} /* end of loop forever */
TCP sender (simplified)
Comment:
SendBase-1: last
cumulatively acked byte
Example:
SendBase-1 = 71; y= 73, so the rcvr wants 73+ ; y > SendBase, so that new data is acked
Transport Layer

20. TCP with MODIFICATIONS SENDER
00 sendbase = initial_sequence number
01 nextseqnum = initial_sequence number 02
loop (forever) {
switch(event)
event: data received from application above
create TCP segment with sequence number nextseqnum
start timer for segment nextseqnum
pass segment to IP
nextseqnum = nextseqnum + length(data)
event: timer timeout for segment with sequence number y
retransmit segment with sequence number y
compute new timeout interval for segment y
restart timer for sequence number y
event: ACK received, with ACK field value of y
if (y > sendbase) { /* cumulative ACK of all data up to y */
cancel all timers for segments with sequence numbers < y
sendbase = y }
else { /* a duplicate ACK for already ACKed segment */
increment number of duplicate ACKs received for y
if (number of duplicate ACKS received for y is 3) {
/* perform TCP fast retransmission */
resend segment with sequence number y
restart timer for segment y }
} /* end of loop forever */
Why wait for the timeout to expire, when consecutive ACKs can be used to indicate a lost segment
With Fast Retransmit

21. TCP ACK generation [RFC 1122, RFC 2581]
Receiver does not discard out-of-order segments
Event
in-order segment arrival,
no gaps,
everything else already ACKed
no gaps, one delayed ACK
pending (due to action 1)
out-of-order segment arrival
with higher than expect seq. #
- a gap is detected
arrival of segment that
partially or completely fills gap
TCP Receiver action
Delay sending the ACK. Wait up to 500ms
for next segment. If next segment does
not arrive in this interval, send ACK
immediately send a single
cumulative ACK
send duplicate ACK, indicating seq. #
of next expected byte
Immediately send an ACK if segment starts
at lower end of gap 1 2 3 4

22. TCP: Interesting Scenarios
Simplified TCP version
Host A
Seq=92, 8 bytes data
ACK=100
loss
timeout
time
lost ACK scenario
Host B X
Host A
Host B
Seq=92, 8 bytes data
Seq=92 timeout
Seq=100, 20 bytes data
ACK=100
ACK=120
Timer is restarted here for Seq=92
Seq=92, 8 bytes data
SCENARIO #1:
HOST A sends SEGMENT, starts timer, waits for an ACK EVENT, and a SEGMENT from HOST B.
HOST B receives SEGMENT from HOST A and ACKs the SEGMENT. However, this ACK is lost along its way.
Timeout EVENT occurs, invoking HOST A to retransmit the same SEGMENT (unACKed, with smallest SEQ NUMBER).
HOST B observes from the SEQ NUMBER that the SEGMENT it receives is a retransmission. Therefore, it discards the bytes in the SEGMENT.
SCENARIO #2:
As long as the ACK for the new segment arrives before the new timeout, the second segment will not be retransmitted.
ACK=120
time
premature timeout,
cumulative ACKs
Segment with Seq=100 not retransmitted
Retransmission due to lost ACK

23. TCP: Retransmission Scenario
Host A
Host B
Seq=92, 8 bytes data
Seq=100, 20 bytes data
Seq=92 timeout
ACK=100 X
loss
ACK=120
HOST A receives an ACK = 120, indicating that HOST B has received everything up through byte 119.
time
Cumulative ACK avoids retransmission of the first segment.

24. TCP Modifications: Doubling the Timeout Interval
Provides a limited form of congestion control
Congestion may get worse if sources continue to retransmit packets persistently.
Timer expiration is more likely caused by congestion in the network
TimeoutInterval = 2 * TimeoutIntervalPrevious
After ACK is received,
TimeoutInterval is derived
from most recent EstimatedRTT
and DevRTT
TCP acts more politely by increasing the TimeoutInterval, causing the sender to retransmit after longer and longer intervals.
Others: check RFC 2018 – selective ACK

25. TCP Flow Control flow control
receiver: explicitly informs sender of (dynamically changing) amount of free buffer space
RcvWindow field in TCP segment
sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow
flow control
sender won't overrun
receiver's buffer by
transmitting too much,
too fast
RcvBuffer = size of TCP Receive Buffer
RcvWindow = amount of spare room in Buffer
receiver buffering

26. FLOW CONTROL: Receiver
EXAMPLE: HOST A sends a large file to HOST B
RECEIVER: HOST B – uses RcvWindow, LastByteRcvd, LastByteRead
LastByteRead
Data from IP
Application Process 40 60 50
100
FLOW CONTROL SERVICE – to eliminate the possibility of the sender overflowing the receiver’s buffer
Example:
HOST A sends a large file to HOST B
Application process reads data from buffer
LastByteRcvd
HOST B tells HOST A how much spare room it has in the connection buffer by placing its current value of RcvWindow in the receive window field of every segment it sends to HOST A.
Initially, RcvWindow = RcvBuffer
Application reads from the buffer
RcvBuffer
RcvWindow=RcvBuffer-[LastByteRcvd-LastByteRead]

27. FLOW CONTROL: Sender ACKs from Host B Data
EXAMPLE: HOST A sends a large file to HOST B
SENDER: HOST A – uses RcvWindow of HostB, LastByteSent, LastByteACKed
LastByteACKed
SENDER: HOST A
ACKs from
Host B 40 60 50
100
The SENDER
LastByteSent
Data
To ensure that HOST B does not overflow, HOST A maintains throughout the connection’s life that [LastByteSent-LastByteACKed] <= RcvWindow

28. FLOW CONTROL Some issue to consider:
RcvWindow – used by the connection to provide the flow control service
What happens when the receive buffer of HOST B is full ? (that is, when RcvWindow=0)
TCP requires that HOST A continue to send segments with one data byte when HOST B’s receive window is 0. Such segments will be ACKed by HOST B.
Eventually, the buffer will have some space and the ACKs will contain RcvWindow > 0
TCP sends a segment only when there is data or ACK to send. Therefore, the sender must maintain the connection ‘alive’.

29. TCP Connection Management
Recall: TCP sender, receiver establish “connection” before exchanging data segments
Initialize TCP variables:
sequence numbers
buffers, flow control info (e.g. RcvWindow)
Client is the connection initiator
In Java, Socket clientSocket = new Socket("hostname","port number"); connect;
Server is contacted by client
In Java,Socket accept();
if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) != 0) {
printf("connect failed\n");
WSACleanup(); exit(1); }
ns = accept(s,(struct sockaddr *)(&remoteaddr),&addrlen);

30. TCP Connection Management
Establishing a connection
Three way handshake:
Step 1: client end system sends TCP SYN control segment to server (executed by TCP itself)
specifies initial seq number (isn)
Step 2: server end system receives SYN, replies with SYNACK control segment
ACKs received SYN
allocates buffers
specifies server’s initial seq. number
Step 3: client ACKs the connection with
ACK=server_isn +1
sends SYN=0
Connection established!
Client
Server
This is what happens when we create a socket for connection to a server
Connect (SYN=1, seq=client_isn)
seq=server_isn,ack=client_isn+1)
Accept (SYN=1,
seq=client_isn+1,ack=server_isn+1)
ACK (SYN=0,
The server allocates and initialises connection variables and buffers in response to a received SYN.
time
After establishing the connection, the client can receive segments with app-generated data! (SYN=0)

31. TCP Connection Management (cont.)
How TCP connection is established and torn down
Closing a connection:
client closes socket:
closesocket(s);
Java: clientSocket.close();
Step 1: client end system sends TCP FIN control segment to server
Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN.
client
FIN
server
ACK
close
closed
timed wait

32. TCP Connection Management (cont.)
Step 3: client receives FIN, replies with ACK.
Enters ''timed wait'' - will respond with ACK to received FINs
Step 4: server, receives ACK. Connection closed.
Note: with small modification, can handle simultaneous FINs.
client
server
closing
FIN
ACK
closing
FIN
timed wait
ACK
closed
closed

33. TCP Connection Management (cont)12
Used in case ACK gets lost. It is implementation-dependent (e.g. 30 seconds, 1 minute, 2 minutes 10 2 8 4
TCP server lifecycle 6 11
TCP client lifecycle 9 1
SYN (1 bit) – Synchronize sequence numbers.
Connection formally closes – all resources (e.g. port numbers) are released 7 3 5

34. End of Flow Control and Error Control
When we think of the internet, so many things come to our mind. Nowadays, the internet connects almost anything imaginable. To take a peek of the few items connected to the internet, we have…

35. Flow Control vs. Congestion Control
Similar actions are taken, but for very different reasons
Flow Control
point-to-point traffic between sender and receiver
speed matching service, matching the rate at which the sender is sending against the rate at which the receiving application is reading
prevents Receiver Buffer from overflowing
Congestion – happens when there are too many sources attempting to send data at too high a rate for the routers along the path
Reliable data transfer service – accounts for packet loss. Packet loss – typically results from the overflowing of router buffers as the network becomes congested
FLOW CONTROL & CONGESTION CONTROL – similar actions are taken – throttling of the sender, but taken for very different reasons
FLOW CONTROL
speed matching service – matching the rate at which the SENDER is sending against the rate at which the RECEIVING APPLICATION is reading
- prevents overflowing the RECEIVE BUFFER
Flow control, in contrast, relates to the point-to-point traffic between a given sender and a given receiver. Its job is to make sure that a fast sender cannot continually transmit data faster than the receiver is able to absorb it. Flow control frequently involves some direct feedback from the receiver to the sender to tell the sender how things are doing at the other end.
CAUSE OF NETWORK CONGESTION – too many sources attempting to send data at too high a rate
CONGESTION
a state in which the data traffic approaches or exceeds the channel’s capacity, resulting in a severe performance degradation and, possibly, loss of packets.
caused by temporary resource overloads. If more traffic suddenly arrives at a router than the router can handle, congestion will build up and performance will suffer
When too much traffic is offered, congestion sets in and performance degrades sharply
happens when there are too many sources attempting to send data at too high a rate for the routers along the path
CONGESTION CONTROL
service that makes sure that the routers between End Systems are able to carry the offered traffic
has to do with making sure the subnet is able to carry the offered traffic. It is a global issue, involving the behavior of all the hosts, all the routers, the store-and-forwarding processing within the routers, and all the other factors that tend to diminish the carrying capacity of the subnet.
Congestion Control
service that makes sure that the routers between End Systems are able to carry the offered traffic
prevents routers from overflowing
Same course of action: Throttling of the sender

36. Principles of Congestion Control
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 (queuing in router buffers)
a top-10 problem!
Reliable data transfer service – accounts for packet loss. Packet loss – typically results from the overflowing of router buffers as the network becomes congested
FLOW CONTROL & CONGESTION CONTROL – similar actions are taken – throttling of the sender, but taken for very different reasons
FLOW CONTROL – speed matching service – matching the rate at which the SENDER is sending against the rate at which the RECEIVING APPLICATION is reading
- prevents overflowing the RECEIVE BUFFER
CAUSE OF NETWORK CONGESTION – too many sources attempting to send data at too high a rate

37. Approaches towards congestion control
Two broad approaches towards congestion control: 1
End-to-end congestion control:
no explicit feedback from network
congestion inferred by end-systems from observed packet loss & delay
approach taken by TCP 2
Network-assisted congestion control:
routers provide feedback to End Systems in the form of:
single bit indicating link congestion (SNA, DECbit, TCP/IP ECN, ATM ABR)
explicit transmission rate the sender should send at
TCP necessarily take this approach for congestion control, since the IP layer provides no feedback to the END systems regarding network congestion.
INDICATION OF NETWORK CONGESTION:
timeout, triple duplicate ACKs – TCP decreases Window size accordingly
Increasing Round-trip delay values
Congestion information is typically fed back from the network to the sender in one of two ways:
Direct feedback from Network ROUTER to SENDER– in the form of a choke packet (essentially saying, I’m congested!)
Router marks/updates fields in a packet flowing from SENDER to RECEIVER to indicate congestion
Upon receipt of a marked packet, the RECEIVER then notifies the sender of a congestion problem (takes at least a full RTT)

38. TCP Congestion Control
How TCP sender limits the rate at which it sends traffic into its connection?
New variable! – Congestion Window
SENDER:
(Amount of unACKed data)SENDER < min(CongWin, RcvWindow)
LastByteSent - LastByteACKed
Indirectly limits the sender’s send rate
By adjusting CongWin, sender can therefore adjust the rate at which it sends data into its connection
Assumptions:
Why is Network-assisted congestion control suitable for ATM?
ATM maintains per-VC state at network switches allowing the switches to track the behavior of individual senders (e.g. average transmission rate) and to take sender-specific congestion control actions.
TCP receive buffer is very large – no RcvWindow constraint
 Amt. of unACKed data at sender is solely limited by CongWin
Packet loss delay & packet transmission delay are negligible
Sending rate: (approx.)
CongWin
RTT

39. TCP Congestion Control
TCP uses ACKs to trigger (“clock”) its increase in congestion window size – “self-clocking”
Arrival of ACKs – indication to the sender that all is well
Slow Rate
Congestion window will be increased at a relatively slow rate
High rate
Why is Network-assisted congestion control suitable for ATM?
ATM maintains per-VC state at network switches allowing the switches to track the behavior of individual senders (e.g. average transmission rate) and to take sender-specific congestion control actions.
Congestion window will be increased more quickly

40. TCP Congestion Control
How TCP perceives that there is congestion on the path?
“Loss Event” – when there is excessive congestion, router buffers along the path overflows, causing datagrams to be dropped, which in turn, results in a “loss event” at the sender
Timeout
no ACK is received after segment loss
Receipt of three duplicate ACKs
Why is Network-assisted congestion control suitable for ATM?
ATM maintains per-VC state at network switches allowing the switches to track the behavior of individual senders (e.g. average transmission rate) and to take sender-specific congestion control actions.
segment loss is followed by three ACKs received at the sender

41. TCP Congestion Control: details
sender limits transmission:
LastByteSent-LastByteAcked
 cwnd
roughly,
cwnd is dynamic, function of perceived network congestion
How does sender perceive congestion?
loss event = timeout or 3 duplicate acks
TCP sender reduces rate (cwnd) after loss event
Three mechanisms:
AIMD
slow start
conservative after timeout events
rate =
cwnd
RTT
Bytes/sec

42. TCP congestion avoidance : additive increase, multiplicative decrease
approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs
additive increase: increase cwnd by 1 MSS every RTT until loss is detected
multiplicative decrease: cut cwnd in half after loss
saw tooth
behavior: probing
for bandwidth
cwnd: congestion window size
time

43. TCP Slow Start
when connection begins, increase rate exponentially until first loss event:
initially cwnd = 1 MSS
double cwnd every RTT
done by incrementing cwnd by 1 MSS for every ACK received
summary: initial rate is slow but ramps up exponentially fast (doubling of the sending rate every RTT)
Host A
Host B
one segment
RTT
two segments
four segments
time

44. Refinement: inferring loss
after 3 dup ACKs:
cwnd is cut in half
window then grows linearly
but after timeout event:
cwnd is set to 1 MSS
window then grows exponentially
Up to a threshold, then grows linearly
Philosophy:
3 dup ACKs indicates network capable of delivering some segments
timeout indicates a “more alarming” congestion scenario

45. Refinement Implementation:
Q: when should the exponential increase switch to linear?
A: when cwnd gets to 1/2 of its value before timeout.
Implementation:
variable ssthresh (slow-start threshold)
on loss event, ssthresh is set to 1/2 of cwnd just before loss event

46. TCP Sender Congestion Control
STATE
EVENT
TCP SENDER Congestion-Control Action
Commentary
SLOW START (SS)
ACK receipt for previously unACKed data
CongWin = CongWin + MSS,
If(CongWin > Threshold)
set state to “Congestion Avoidance”
Resulting in a doubling of CongWin every RTT
Congestion Avoidance (CA)
CongWin = CongWin + MSS * (MSS/CongWin)
Additive increase, resulting in increasing of CongWin by 1 MSS every RTT
SS or CA
Loss event detected by triple duplicate ACK
Threshold = CongWin / 2,
CongWin = Threshold,
Set state to “Congestion Avoidance”
Fast recovery, implementing multiplicative decrease, CongWin will not drop below 1 MSS.
Timeout
CongWin = 1 MSS,
Set state to “Slow Start”
Enter Slow Start.
Duplicate ACK
Increment duplicate ACK count for segment being ACKed
CongWin and Threshold not changed

47. Summary: TCP Congestion Control
New
ACK!
congestion
avoidance
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
transmit new segment(s), as allowed
new ACK .
dupACKcount++
duplicate ACK
slow
start
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
cwnd = cwnd+MSS
transmit new segment(s), as allowed
new ACK
dupACKcount++
duplicate ACK L
ssthresh = 64 KB L
cwnd > ssthresh
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment
dupACKcount == 3
timeout
ssthresh = cwnd/2
cwnd = 1
dupACKcount = 0
cwnd = ssthresh
dupACKcount = 0
New ACK
ssthresh= cwnd/2
cwnd = ssthresh + 3 MSS
retransmit missing segment
dupACKcount == 3
fast
recovery
cwnd = cwnd + MSS
transmit new segment(s), as allowed
duplicate ACK

48. TCP’s Congestion Control Service
Problem: Gridlock sets-in when there is packet loss due to router congestion
The sending system’s packet is lost due to congestion, and is alerted when it stops receiving ACKs of packets sent
CLIENT
SERVER
Due to router congestion, the packets sent by the sending End system is lost. When that happens, the sending end system is alerted of congestion if it does not receive an acknowledgement for the packets it sent. TCP provides a congestion control service that forces the End systems to decrease the rate at which packets are sent during periods of congestion.
You can view the applet from Kurose’s site demonstrating network congestion.
Congestion control
forces the End Systems to decrease the rate at which packets are sent during
periods of congestion

49. Macroscopic Description of TCP throughput
(Based on Idealised model for the steady-state dynamics of TCP)
what’s the average throughout of TCP as a function of window size and RTT?
ignore slow start (typically very short phases)
let W be the window size when loss occurs.
when window is W, throughput is W/RTT
just after loss, window drops to W/2, throughput to W/2RTT.
Throughput increases linearly (by MSS/RTT every RTT)
Average Throughput: .75 W/RTT
Transport Layer

50. TCP Futures: TCP over “long, fat pipes”
Example: GRID computing application
1500-byte segments, 100ms RTT, desired throughput of 10 Gbps
requires window size W = 83,333 in-flight segments
Throughput in terms of loss rate:
➜ L = 2· – a very small loss rate! (1 loss event every 5 billion segments)
new versions of TCP is needed for high-speed environments
Transport Layer

51. Go to Summary of TCP Congestion Control
TCP Fairness
Fairness goal: if N TCP sessions share same bottleneck link, each should get an average transmission rate of R/N , an equal share of the link’s bandwidth
TCP connection 1
bottleneck
router
capacity R
TCP
connection 2
Go to Summary of TCP Congestion Control

52. Analysis of 2 connections sharing a link
Assumptions:
Link with transmission rate of R
Each connection have the same MSS, RTT
No other TCP connections or UDP datagrams traverse the shared link
Ignore slow start phase of TCP
Operating in congestion-avoidance mode (linear increase phase)
Goal: adjust sending rate of the two connections to allow for equal bandwidth sharing

53. Why is TCP fair? Two competing sessions: View Simulation
Additive increase gives slope of 1, as throughout increases
multiplicative decrease: decreases throughput proportionally R
equal bandwidth share
We can view
a simulation on this
A point on the graph depicts the amount of link bandwidth jointly consumed by the connections
loss: decrease window by factor of 2
Connection 2 throughput
congestion avoidance: additive increase
Connection 1 throughput R
Full bandwidth utilisation line
View Simulation

54. The End
The next succeeding slides are just for additional reading.

55. TCP Latency Modeling Loop holes in TCP:
Multiple End Systems sharing a link
1 TCP connection
1 TCP connection
3 TCP connections
Multithreading implementation
1 TCP connection
R bps – link’s transmission rate
Loop holes in TCP:
In practice, client/server applications with smaller RTT gets the available bandwidth more quickly as it becomes free. Therefore, they have higher throughputs
Multiple parallel TCP connection allows one application to get a bigger share of the bandwidth

56. Q: How long does it take to receive an object from a Web server?
TCP latency modeling
the time from when the client initiates a TCP connection until when the client receives the requested object in its entirety
Q: How long does it take to receive an object from a Web server?
TCP connection establishment time
data transfer delay
Actual data transmission time
Two cases to consider:
WS/R > RTT + S/R:
An ACK for the first segment in window returns to the Sender before a window’s worth of data is sent
WS/R < RTT + S/R:
Sender has to wait for an ACK after a window’s worth of data sent
No data transfer delay
CASE 1: There’s no gap between each transmission of a window’s worth of data (ACK is received in time).
CASE 2: There’s gap between each transmission of a window’s worth of data (ACK is not received in time) – there’s delay .
There’s data transfer delay

57. TCP Latency Modeling O - Size of object in bits Assumptions:
CLIENT
SERVER
R bps – link’s transmission rate
FILE
O - Size of object in bits
Assumptions:
S – number of bits of MSS (max. segment size)
Network is uncongested, with one link between end systems of rate R
CongWin (fixed) determines the amount of data that can be sent
No packet loss, no packet corruption, no retransmissions required
Header overheads are negligible
File to send = integer number of segments of size MSS
Connection establishment, request messages, ACKs, TCP connection-establishment segments have negligible transmission times
Initial Threshold of TCP congestion mechanism is very big

58. Case 1: latency = 2RTT + O/R
TCP latency Modeling
Case Analysis: STATIC CONGESTION WINDOW
Case 1: WS/R > RTT + S/R:
An ACK for the first segment in window returns to the Sender before a window’s worth of data is sent
K = Number of Windows of data that cover the object
K = O/WS
Server is in stalled state (K-1) periods of time
Number of segments;
Rounded up to the nearest integer
e.g. O=256bits, S=32bits, W=4
Assume: W=4 segments
Case 1: latency = 2RTT + O/R

59. Case 2: latency = 2RTT + O/R + (K-1)[S/R + RTT - WS/R]
TCP latency Modeling
Case Analysis: STATIC CONGESTION WINDOW
Case 2: WS/R < RTT + S/R:
Sender has to wait for an ACK after a window’s worth of data sent
Number of Windows of data that cover the object
K:= O/WS
If there are k windows, sender will
be stalled (k-1) times
STALLED PERIOD
Server is in stalled state (K-1) periods of time
Case 2: latency = 2RTT + O/R + (K-1)[S/R + RTT - WS/R]

60. Case Analysis: DYNAMIC CONGESTION WINDOW
STALLED PERIOD
O/S=15
4 windows

61. Case Analysis: DYNAMIC CONGESTION WINDOW
Let K be the number of windows that cover the object.
We can express K in terms of the number of segments in the object as follows:
K is exponentially growing in size: 1, 2, 4 ,8, 16
We can see here that K could be expressed in terms of the (number of MSS segments comprising an object) + 1
Note:

62. Case Analysis: DYNAMIC CONGESTION WINDOW
From the time the server begins to transmit the kth window until the time the server receives an ACK for the first segment in the window
Transmission of kth window =
Stall Time =
Latency =

63. Case Analysis: DYNAMIC CONGESTION WINDOW
Let Q be the number of times the server would stall if the object contained an infinite number of segments.
The actual number of times that the server stalls is
P = min{ Q, K-1 }.

64. Case Analysis: DYNAMIC CONGESTION WINDOW
Let Q be the number of times the server would stall if the object contained an infinite number of segments.
The actual number of times that the server stalls is
P = min{ Q, K-1 }.
Closed-form expression for the latency:

65. Case Analysis: DYNAMIC CONGESTION WINDOW
Let Q be the number of times the server would stall if the object contained an infinite number of segments.
*Slow start will not significantly increase latency if RTT << O/R

66. http://www1. cse. wustl. edu/~jain/cis788- 97/ftp/tcp_over_atm/index
97/ftp/tcp_over_atm/index.htm#atm-features