TELCOM 2310: Applications of Networks

Lecture 6 (Part 1)
TCP services: Flow Control, Congestion Control
Kaushik P. Seshadreesan, Fall 2024
Partially adapted from Kurose & Ross slides: http://gaia.cs.umass.edu/kurose_ross/ppt.htm
Partially adapted from prior year slides by Kostas Pelechrinis and Amy Babay
Partially adapted from JHU Computer Networks course: https://github.com/xinjin/course-net

Department of Informatics and Networked Systems

School of Computing and Information
 Recall: TCP Service Abstraction
• TCP is a connection-oriented protocol that delivers a reliable, in-
order, byte stream
• Connection-oriented: two processes coordinate (“handshake”)
before beginning to send data to each other
• Reliable: TCP resends lost packets
– Until it gives up and shuts down connection
• In-order: TCP only hands consecutive chunks of data to application
• Byte stream: TCP assumes there is an incoming stream of data, and
attempts to deliver it to application

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 2

 Recall: Reliability in TCP
• TCP’s reliability builds on mechanisms we’ve seen:
– Checksums
– sequence numbers (adapted to byte stream abstraction),
– cumulative acknowledgments, time outs and retransmissions,
– sliding window
– New mechanisms: dynamic timeout estimation, fast retransmit

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 3

 Flow Control
• Flow Control key idea: sender should not transmit faster than
the receiver can process!

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 4

 Flow Control
• Recall our discussion from last week on reliable data transfer
– Receiver maintains a buffer that stores received but not-yet-
delivered data
recvbase N
Received and ACK’d

Not received (but expected)

sequence number → Not received

– Buffers have finite storage space, so what would happen if sender

sends more data than the receiver can fit in its buffer?

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 5

 Flow Control
• We saw a limited form of flow control in the Go-Back-N and
Selective Repeat protocols we looked at:
– Receiver maintains a buffer that can hold N packets
– Sender is allowed to have up to N unacknowledged packets out at
any time N
Sent and ACK’d

Sent but not ACK’d

sequence number → Not yet sent

N
Received and ACK’d

Not received (but expected)

sequence number → Not received

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 6
 TCP Flow Control
• More flexible, but same basic idea: 32 bits
sender only sends as much data as it Source port Destination port
knows receiver can accept Sequence number
Acknowledgment
• Receiver uses an “Advertised Window” HdrLen 0 Flags Advertised window
(RWND) to tell the sender how many Checksum Urgent pointer
bytes it can accept
Options (variable)
– Receiver indicates value of RWND in ACKs
– Sender ensures that the total number of
Data
bytes in flight <= RWND

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 7

 TCP Flow Control
• Advertised window limits rate: Sender can send no faster than
RWND/RTT bytes/sec
• Receiver only advertises more space when application has
consumed old arriving data
• What happens when RWND=0?
– Sender keeps probing by sending segments with one byte of data
– Receiver can ACK, but won’t increase RWND until application reads
some data and buffer space opens up

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 8

 Recall: TCP Service Abstraction
• TCP is a connection-oriented protocol that delivers a reliable, in-
order, byte stream
• Connection-oriented: two processes coordinate (“handshake”)
before beginning to send data to each other
• Reliable: TCP resends lost packets
– Until it gives up and shuts down connection
• In-order: TCP only hands consecutive chunks of data to application
• Byte stream: TCP assumes there is an incoming stream of data, and
attempts to deliver it to application

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 9

 TCP Connection Management
• Before exchanging data, sender/receiver “handshake”:
– agree to establish connection (each knowing the other willing to establish
connection)
– agree on connection parameters (e.g., initial buffer sizes, starting seq #s)
application application

connection state: ESTAB connection state: ESTAB

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

network network

clientSocket.connect("hostname, connectionSocket =
"port number"); welcomeSocket.accept();
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 10
Connection Parameters: Initial Sequence Number
• Sequence number for the very first byte
• Why not just use ISN = 0?
– Practical issue
• IP addresses and port #s uniquely identify a connection
• Eventually, though, these port #s do get used again; small chance an old
packet is still in flight
• Also, others might try to spoof your connection
– Why does using ISN help?
• Hosts exchange ISNs when establishing connection

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 11

 Establishing a TCP Connection

• Three-way handshake to A B
establish connection
– Host A sends a SYN (open;
“synchronize sequence numbers”)
to host B
– Host B returns a SYN
acknowledgment (SYN ACK)
– Host A sends an ACK to
acknowledge the SYN ACK

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 12

 Establishing a TCP Connection
32 bits
Source port Destination port

Sequence number
Flags:
SYN Acknowledgment
ACK HdrLen 0 Advertised window
Flags
FIN
RST Checksum Urgent pointer
PSH
URG Options (variable)
CWR
ECE
Data

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 13

 Establishing a TCP Connection
32 bits
Source port Destination port

Sequence number
Flags:
SYN – connection setup Acknowledgment
ACK – contains valid ack HdrLen 0 Advertised window
Flags
FIN – connection teardown
RST – connection teardown Checksum Urgent pointer
PSH – pass data up immediately
URG – data marked urgent Options (variable)
CWR – congestion control
ECE – congestion control
Data

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 14

 Wrapping up TCP Segment Structure
32 bits
Source port Destination port

Sequence number
Acknowledgment
Length of header in 32-bit words HdrLen 0 Flags Advertised window
Unused Checksum Urgent pointer
Options (variable)

Data

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 15

 Step 1: Host A’s SYN

A’s port B’s port

A’s Initial Sequence Number

A tells B to open
a connection N/A
5 0 SYN Advertised window

Checksum Urgent pointer

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 16

 Step 2: Host B’s SYN-ACK

B’s port A’s port

B’s Initial Sequence Number

B tells A it
accepts and is ACK=A’s ISN+1
ready to accept
next packet 5 0 SYN|ACK Advertised window

Checksum Urgent pointer

B’s Initial Sequence Number can be different from A’s Initial Sequence Number: they
each choose randomly
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 17
 Step 3: Host A’s ACK of B’s SYN-ACK

A’s port B’s port

A’s Initial Sequence Number

A tells B to open
a connection ACK=B’s ISN+1
5 0 ACK Advertised window

Checksum Urgent pointer

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 18

 TCP 3-way Handshake
Active Passive
Open Open

Client (initiator) Server

connect() listen()

Why did we say

TCP connection
takes 1 RTT if
there are really 3
delays?
Last ACK can be
“piggybacked” on
first data packet
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 19
Closing a TCP Connection: Normal Termination Example

A
time
• Finish (FIN) to close and receive remaining bytes
– FIN occupies one byte in the sequence space Connection
now closed
• Other host acks the byte to confirm Connection
now half-closed
• Closes A’s side of the connection, but not B’s
– Until B likewise sends a FIN
– Which A then acks TIME_WAIT:
B will retransmit FIN
if ACK is lost
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 20
 Closing a TCP Connection: Abrupt Termination

A
time
• A sends a RESET (RST) to B
– E.g., because application process on A crashed
• That’s it
– B does not ack the RST
– Thus, RST is not delivered reliably, and any data in flight is lost
– But: if B sends anything more, will elicit another RST

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 21

 Summary
• TCP: connection-oriented protocol delivering reliable, in-order
byte stream
– Reliability builds on mechanisms we’ve seen: checksums, sequence
numbers (adapted to byte stream abstraction), cumulative
acknowledgments, sliding window
• New mechanisms: dynamic timeout estimation, fast retransmit (based on 3
duplicate ACKs)
– Flow control prevents buffer overruns
– Handshaking procedures used to set up and cleanly teardown
connections
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 22
Congestion Control

Department of Informatics and Networked Systems

School of Computing and Information
 Recall: Flow Control
Sender Receiver
Problem:
- New data arriving at a
receiver with a full buffer will
be dropped
- To provide reliable transfer, it
will need to be
retransmitted… Solution:
- Sender needs to do a lot of - Flow control!
extra work, and we waste - Receiver tells sender how much new data it
bandwidth transmitting the can accept, and sender agrees not to send
same data multiple times more than that
- Results in “speed matching” of sending and
processing/delivering data
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 24
 Congestion Control
• But, buffers at the receiver aren’t the only ones we need to
worry about…
Sender Receiver

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 25

 Congestion Control
• …and many senders may “compete” for the same network
resources
Sender Receiver

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 26

 Congestion Control vs Flow Control
• Both try to limit sending rate to avoid overwhelming finite
resources

• Flow control aims to avoid overwhelming the receiver

• Congestion control aims to avoid overwhelming the network

• Flow control benefits an individual source->destination flow

• Congestion control is (mainly) for the general benefit of the
network
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 27
 Congestion Control
• Goal: allow senders to transmit as fast as possible without
overloading the network

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 28

 Congestion Control Challenges
Consider an extremely simple scenario:

A B
100 Mbps

Sending Host Buffer in Router Receiving Host

• Can we experience congestion in this case?

– Yes, if A sends at a rate > 100 Mbps
• How can we avoid congestion in this case?
– A needs to send at < 100 Mbps…but how does it know what the
available bandwidth is??
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 29
 Congestion Control Challenges
Consider a slightly more complex (but still simple) scenario:
A1 B1
100 Mbps
A2 B2

A3 B3
• How can we avoid congestion?
– A1, A2, A3 need to collectively send at a rate of at most 100 Mbps
– But none of them knows that the bottleneck link is 100 Mbps, how many
other senders there are, or how fast the others want to send…
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 30
 Congestion Control Challenges
And reality looks more like this:

1Gbps
1Gbps

600Mbps

Congestion control is a resource allocation problem involving many flows,

many links, and complicated global dynamics
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 31
 What can we do?

(0) Give up – let everyone send as fast as they want

– Many packet drops, delays, retransmissions, potential
for congestive collapse

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 32

 What can we do?

(0) Give up – let everyone send as fast as they want

(1) Require reservations (virtual circuits)
– Pre-arrange bandwidth allocations
– Requires negotiation before sending packets
– Low utilization

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 33

 What can we do?

(0) Give up – let everyone send as fast as they want

(1) Require reservations (virtual circuits)
(2) Charge more money
– Don’t drop packets for the high-bidders
– Requires payment model

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 34

 What can we do?

(0) Give up – let everyone send as fast as they want

(1) Require reservations (virtual circuits)
(2) Charge more money
(3) Dynamically adjust sending rates
– Hosts infer level of congestion; adjust rates
– Simple to implement but suboptimal, messy dynamics

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 35

 What can we do?

(0) Give up – let everyone send as fast as they want

(1) Require reservations (virtual circuits)
(2) Charge more money
(3) Dynamically adjust sending rates
– Hosts infer level of congestion; adjust rates
– Simple to implement but suboptimal, messy dynamics
– But, provides a very general solution: doesn’t assume business model,
traffic characteristics, application requirements; maintains layered model
– But, requires good citizenship!

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 36

 What can we do?
(0) Give up – let everyone send as fast as they want Aside: congestion arises
(1) Require reservations (virtual circuits) from competition for limited
(2) Charge more money resources
(3) Dynamically adjust sending rates
An alternative is
– Hosts infer level of congestion; adjust rates
overprovisioning such that
– Simple to implement but suboptimal, messy dynamics
congestion becomes
– But, provides a very general solution: doesn’t assume extremely unlikely.
business model, traffic characteristics, application
requirements
What is the
– But, requires good citizenship!
drawback/tradeoff?

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 37

 TCP Congestion Control: Dynamic Adaptation
• Two key questions:
– How do senders infer that there is congestion?
– How do senders adjust their sending rates in response?

• High-level answers:
– Assume loss implies congestion
– Maintain a window that shrinks whenever congestion is detected
(and increases when no congestion is detected)

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 38

 Congestion Window: Controlling the Send Rate
• Congestion Window: CWND
– Bytes that can be sent without overflowing routers
– Computed by sender using congestion control algorithm
• (Recall) Flow control window: RWND
– Bytes that can be sent without overflowing receiver
– Determined by the receiver and reported to the sender
• Sender-side window = min {CWND, RWND}
– Assume for this lecture that RWND >> CWND
– Recall from flow control discussion: sending rate ~ Window/RTT

10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 39

 Adjusting the Window
• Basic idea:
– Probing for available bandwidth
– ACK: segment received → network is ACKs being received,
not congested → increase sending so increase rate
X
X loss, so decrease rate

rate (increase window size) X

X

sending rate
– Lost segment: (timeout or 3 duplicate X

ACKs) → network is congested →

decrease sending rate (decrease time

window size) TCP’s

“sawtooth”
behavior
10/07/2024 TELCOM 2310 Fall 2024: Lecture 6 40