Computer Networks (CS F303)

BITS Pilani Virendra Singh Shekhawat

Department of Computer Science and Information Systems
Pilani Campus
Topics

• Transport Layer
– TCP Protocol
• Connection Establishment
• TCP Segment Structure
• Reliable data transfer
• Flow control
• Congestion control

2
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP [RFCs: 793,1122,1223,2018,2581]

• Point to Point protocol

– One sender and one receiver
• Reliable in-order byte stream
– No message boundaries
• Pipelined
– Window size is set by congestion and flow control
• Full duplex data
– Bi-directional data flow in same connection
• Connection oriented
– Handshaking (exchange of control msgs to initialize sender, receiver state before data
exchange)
• Flow controlled
– Sender do not overwhelm receiver
3
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 TCP Segment Structure
32 bits

source port # dest port # seq#: byte stream number

ACK: seq # of next expected sequence number of the first byte in the
byte; A bit: this is an ACK segment (NOT segment
acknowledgement number
number!)
head not
length (of TCP header) len used C EUAP R SF receive window flow control: # bytes
Internet checksum checksum Urg data pointer receiver willing to accept

options (variable length)

C, E: congestion notification
TCP options
application data sent by
RST, SYN, FIN: connection data application into
management (variable length) TCP socket

4
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP: Wireshark Capture

5
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Sequence Numbers and ACKs
outgoing segment from sender
Sequence Numbers: source port # dest port #
sequence number
• Byte stream “number” of acknowledgement number
rwnd
first byte in segment’s data checksum urg pointer

window size
Acknowledgements: N

• seq # of next byte expected

from other side sender sequence number space

sent sent, not- usable not

ACKed yet ACKed but not usable
(“in-flight”) yet sent

outgoing segment from receiver

source port # dest port #
sequence number
acknowledgement number
A rwnd
checksum urg pointer 6
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Connection Management

• Before exchanging data, sender/receiver do “handshake”

– Agree on connection parameters

application application

connection state: ESTAB connection state: ESTAB

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

network network

Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
7
Computer Networks (CS F303) BITS Pilani, Pilani Campus
2-way Handshake

• Will 2-way handshake

always work in network?
Let’s talk
ESTAB
OK
ESTAB

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

8
Computer Networks (CS F303) BITS Pilani, Pilani Campus
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

9
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Retransmission Scenarios
Host A Host B Host A Host B

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

Seq=100, 20 bytes of data

timeout

timeout
ACK=100
X
ACK=100
ACK=120

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

SendBase=100 bytes of data send cumulative
SendBase=120 ACK for 120
ACK=100
ACK=120

SendBase=120

lost ACK scenario premature timeout

10
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Retransmission Scenarios
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

ACK=100
X
ACK=120

Seq=120, 15 bytes of data

Cumulative ACK covers

for earlier lost ACK
11
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Sender
Event: Data received from application Event: Timeout
 Create segment with seq #  Retransmit segment that caused
timeout
 Seq # is byte-stream number of first  Restart timer
data byte in segment
 Start timer if not already running Event: ACK received
• Think of timer as for oldest unACKed
segment  If ACK acknowledges
• Expiration interval: previously unACKed segments
TimeOutInterval • Update what is known to be
ACKed
• Start timer if there are still
unACKed segments
12
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Receiver: ACK generation [RFC 5681]
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

13
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 Is TCP GBN or SR…?

1. Is out of order segments are individually ACKed?

2. Are ACKs cumulative?
3. How many timers are maintained by sender?
4. Is TCP receiving out of order segments?

14
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 TCP Timeout

• How to set TCP Timeout value?

– Must be longer than RTT
– Too short vs. too long

• How to estimate RTT?

– RTT: measured time from segment transmission until ACK receipt

15
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Quiz

• Calculate the missing sequence numbers (Seq),

acknowledgment numbers (ACK), and segment length
(LEN) (i.e., A to J) in the TCP connection as shown in
the Fig.2. Consider following assumptions:
– No timeouts occur at the receiver.
– The sender starts the timer at T1.
– There are no delayed acknowledgements at the sender or
the receiver.
• Sol: A = 25, B= 140, C=20, D=25, E=140, F=35, G=160, H=45,
I=200, J=35

16
Computer Networks (CS F303) BITS Pilani, Pilani Campus
RTT Estimation
EstimatedRTT = (1-)*EstimatedRTT + *SampleRTT
– Influence of past sample decreases exponentially fast
– Typical value of  = 0.125 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250

RTT (milliseconds)
200

150

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

SampleRTT Estimated RTT

17
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Timeout Interval

• Timeout Interval
– Estimated RTT + “Safety margin”
– Large variation in Estimated RTT  large safety margin
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25)

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”

18
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 Example: Timeout Interval

• Consider three RTT samples (in ms): 150, 200 and 210 in that order. Assume
initial estimated RTT= 200 ms, initial DevRTT = 50 ms, β = 0.25 and α = 0.125

19
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Connection Close

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
20
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Connection States-Client and Server

21
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 TCP Flow Control

• Receiver advertises free buffer space by

including rwnd value in TCP header to application process

– RcvBuffer size set via socket options (typical

default is 4096 bytes) RcvBuffer buffered data
– Many operating systems auto adjust RcvBuffer
rwnd free buffer space

TCP segment payloads

Flow control
Receiver controls sender, so sender won’t
overflow receiver’s buffer by transmitting Sender make sure throughout the connection’s life:
too much, too fast. LastByte Sent – LastByte ACKed <= rwnd

22
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Congestion Control

• What is congestion?
– Too many sources sending too
much data too fast for network
to handle

• Congestion results in
– Packet losses
– Packet delays
– Throughput reduction

23
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Causes/Costs of Congestion: Scenario-1
original data: lin throughput: lout
Simplest scenario:
Host A
 One router, infinite buffers
infinite shared
 Input, output link capacity: R output link buffers

 Two flows
R R
 No retransmissions needed
Host B

R/2
Q: What happens as lout
arrival rate lin

delay
throughput:

approaches R/2?
lin R/2 lin R/2
maximum per-connection large delays as arrival rate
throughput: R/2 lin approaches capacity 24
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Causes/Costs of Congestion: Scenario-2
 One router, finite buffers
 Sender retransmits lost, and timed-out packet
• Application-layer input = application-layer output: lin = lout
• Transport-layer input includes retransmissions : l’in lin

Host A lin : original data

lout
l'in: original data, plus
retransmitted data

R R

Host B finite shared output

link buffers 25
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Causes/Costs of Congestion: Scenario-2
R/2
Realistic scenario: un-needed duplicates “wasted” capacity due
to retransmissions
“wasted” capacity due

throughput: lout
 Packets can be lost, dropped at router due to to un-needed
retransmissions
full buffers – requiring retransmissions
 But sender time-out prematurely, sending two when sending at
R/2, some packets
copies, both of which are delivered are retransmissions,
including needed
and un-needed
Host A lin : original data lin R/2 duplicates, that are
delivered!
l'in: original data, plus lout
retransmitted data
Costs of congestion:
 More work for given receiver
throughput
 Unneeded retransmissions:
R R  Decreasing maximum achievable
throughput
Host B finite shared output
link buffers 26
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Causes/Costs of Congestion: Scenario-3

 Four senders Q: What happens as lin and lin’ increase ?

 Multi-hop paths A: As red lin’ increases, all arriving blue pkts at upper
 Timeout/Retransmit queue are dropped, blue throughput g 0
Host A lin : original data
Host B
l'in: original data, plus
retransmitted data
finite shared
output link buffers

Host D Another “cost” of congestion:

lout  When packet dropped, any
Host C
upstream transmission capacity
and buffering used for that packet
was wasted!
27
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 Summary: Causes/Costs of Congestion
R/2

 Throughput can never exceed capacity

throughput: lout
lin R/2

 Delay increases as capacity approached

delay
R/2
lin R/2

lout
 Loss/retransmission decreases effective

throughput:
throughput
R/2

lin
 Un-needed duplicates further decreases effective

throughput: lout
R/2

throughput
R/2
lin R/2

 Upstream transmission capacity / buffering

lout
wasted for packets lost downstream
lin’ R/2
28
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 Approaches Towards Congestion Control [.1]

End-to-end congestion control:

• No explicit feedback from network
• Congestion inferred from observed loss.

data data
ACKs
ACKs

 Approach taken by TCP

29
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Approaches Towards Congestion Control [..2]

Network-assisted congestion control:

 Routers provide direct feedback to
sending/receiving hosts with flows passing explicit congestion info
through congested router
 May indicate congestion level or explicitly
set sending rate data data
ACKs
ACKs

• TCP ECN, ATM, DECbit protocols

30
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Congestion Control

• Approach
– Sending rate is a function of perceived congestion

• Arises three important questions

– How does sender perceive the congestion on the path?
– What algorithm should be used to change its sending rate?
– How does sender limit the sending rate?

31
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Congestion Control

• Sender limits transmission

– LastByteSent – LastByteAcked <= min(cwnd, rwnd)
sender sequence number space
cwnd
 Roughly: send cwnd bytes, wait
RTT for ACKS, then send more
bytes

last byte last byte

ACKed sent, not- sent cwnd
yet ACKed TCP rate ~ bytes/sec
(“in-
flight”)
RTT

• What is TCP Sending Rate/Throughput?

32
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 TCP Fast Retransmit

• Time-out period often relatively long

TCP fast retransmit
– Long delay before resending lost packet
If sender receives 3
• Detect lost segments via duplicate ACKs for same data
ACKs. (“triple duplicate ACKs”),
resend unacked
– Sender often sends many segments segment with smallest
back-to-back seq #
– If segment is lost, there will likely be  Likely that unacked
many duplicate ACKs. segment lost, so don’t
wait for timeout.

33
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Fast Retransmit: Example

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data
X

ACK=100
timeout

ACK=100
ACK=100
ACK=100
Seq=100, 20 bytes of data

34
Computer Networks (CS F303) BITS Pilani, Pilani Campus
How to start a connection: TCP Slow Start

Host A Host B

RTT

time
35
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Switching from Slow Start to Congestion
Avoidance

36
Computer Networks (CS F303) BITS Pilani, Pilani Campus
FSM Description of TCP Congestion Control
New
New ACK!
ACK! new ACK
duplicate ACK
dupACKcount++ new ACK .
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS transmit new segment(s), as allowed
dupACKcount = 0
L transmit new segment(s), as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0
slow L congestion
start timeout avoidance
ssthresh = cwnd/2
cwnd = 1 MSS duplicate ACK
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 retransmit missing segment
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
timeout
New
ACK!
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 retransmit missing segment dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmit missing segment
retransmit missing segment
fast
recovery
duplicate ACK
cwnd = cwnd + MSS
transmit new segment(s), as allowed
37
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Sawtooth Behavior

Congestion
Window Congestion Timeouts
avoidance may still
occur

Slowstart Fast Time

Initial
to pace Retransmit
Slowstart
packets and Recovery

38
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Congestion Control: AIMD
 Approach: senders can increase sending rate until packet loss (congestion) occurs,
then decrease sending rate on loss event
Additive Increase Multiplicative Decrease
Increase sending rate by 1 Cut sending rate in half at each
maximum segment size every RTT loss event
until loss detected

AIMD sawtooth
TCP sender Sending rate

behavior: probing
for bandwidth

39
time
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Reno Throughput: Macroscopic Model

W
TCP sender Sending rate

W/2

time

40
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 Example: TCP Congestion Control

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) What is the ssthresh value between transmission
round 7-10?
d) What is the congestion window value at
transmission round 11?
e) How many segments have been sent till
transmission round 11? (including 11th
transmission round)
f) Identify the intervals of time when TCP fast
retransmission and fast recovery is used?

41
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 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

42
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Is TCP Fair?

• Two competing TCP sessions

Fairness Line

Overload

User 2’s
Allocation
x2 Optimal point

Underutilization

Efficiency Line

User 1’s Allocation x1

43
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Additive Increase/Decrease
• Both X1 and X2 increase/decrease by the same amount over time
– The additive increase/decrease policy of increasing both users’ allocations by
aI corresponds to moving along a 450 line

Fairness Line

T1

User 2’s
Allocation T0
x2

Efficiency Line

User 1’s Allocation x1

44
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Multiplicative Increase/Decrease

• Both X1 and X2 increase/decrease by the same factor over time

– Extension from origin – constant fairness

Fairness Line
T1

User 2’s
Allocation
x2 T0

Efficiency Line

User 1’s Allocation x1

45
Computer Networks (CS F303) BITS Pilani, Pilani Campus
What is the Right Choice?

• Constraints limit us to AIMD

– AIMD moves towards optimal point

Fairness Line
x1

x0
User 2’s
Allocation
x2 x2

Efficiency Line

User 1’s Allocation x1

46
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Must all network apps be “fair”?

Fairness and UDP Fairness, parallel TCP

 Multimedia apps often do not connections
use TCP  Application can open multiple
• Do not want rate throttled by
congestion control parallel connections between two
hosts
 Instead use UDP:
• Send audio/video at constant rate,  Web browsers do this!!!
tolerate packet loss
 There is no “Internet police”
policing use of congestion
control
47
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Fairness with different RTT

• Flows sharing bottleneck link with different RTT do not get

same bandwidth. Why???
– Throughput is proportional to 1/RTT

48
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Goals for TCP Fairness and Throughput

• Fast window growth

– Slow start and additive increase are too slow when bandwidth is large
– Want to converge more quickly
• Maintain fairness with other TCP variants
– Window growth cannot be too aggressive
• Improve RTT fairness
– TCP Tahoe/Reno flows are not fair when RTT vary widely

49
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 Compound TCP Implementation
• Default TCP implementation in Windows 2008 TCP Stack
– Good for connections with large “bandwidth-delay” products
– Make congestion decisions that modifies the transmission rate based on RTT variation
• Key idea: split cwnd into two separate windows

• swnd = min(cwnd + dwnd, rwnd)

• Rules for adjusting dwnd:

– If RTT is increasing, decrease dwnd (dwnd >= 0)
– If RTT is decreasing, increase dwnd
– Increase/decrease are proportional to the rate of change
• Further Reading
50
– A Compound TCP Approach for High-speed and Long Distance Networks, K Tan, J Song, MS Research Asia
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Compound TCP Example
Faster
High Low
cwnd
RTT RTT
Slower growth
Sender window

Timeout cwnd Timeout

growth

Slow Start

Time
• Pros: fast ramp up, more fair to flows with different RTTs
• Cons: must estimate precise value of RTT, which is challenging
51

Computer Networks (CS F303) BITS Pilani, Pilani Campus

TCP CUBIC
 Is there a better way than AIMD to “probe” for usable bandwidth?
 Insight/intuition:
• Wmax: sending rate at which congestion loss was detected
• Congestion state of bottleneck link probably (?) hasn’t changed much
• After cutting rate/window in half on loss, initially ramp to to Wmax faster, but then
approach Wmax more slowly

Wmax classic TCP

TCP CUBIC - higher

Wmax/2 throughput in this
example

52
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Cubic
• W(t) = C( t – K)3 + Wmax
- Increase W as a function of the cube
of the distance between current time
t and K (future point in time when W
reach again Wmax)
- K is a time period that the function
takes to increase W to Wmax (when
there is no further loss)
K = 3 Wb / C
- β multiplicative decrease factor
- C is a CUBIC parameter
- t is the time elapsed since last
window reduction

53
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP Reno vs TCP CUBIC Performance

Wmax classic TCP

TCP CUBIC - higher

Wmax/2 throughput in this
example

54
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP and the congested “bottleneck link”

 TCP (classic, CUBIC) increase TCP’s sending rate until packet loss occurs
at some router’s output: the bottleneck link

source destination
application application
TCP TCP
network network
link link
physical physical
packet queue almost
never empty, sometimes
overflows packet (loss)

bottleneck link (almost always busy)

55
Computer Networks (CS F303) BITS Pilani, Pilani Campus
TCP and the congested “bottleneck link”
 TCP (classic, CUBIC) increase TCP’s sending rate until packet loss occurs
at some router’s output: the bottleneck link
 Understanding congestion: useful to focus on congested bottleneck link

insight: increasing TCP sending rate will

source not increase end-end throughout destination
with congested bottleneck
application application
TCP TCP
network network
link link
physical physical

insight: increasing TCP

sending rate will
increase measured RTT
Goal: “keep the end-end pipe just full, but not fuller”
RTT 56
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 Delay-based TCP congestion control (TCP
Vegas)
Keeping sender-to-receiver pipe “just full enough, but no fuller”: keep bottleneck link
busy transmitting, but avoid high delays/buffering
# bytes sent in
measured last RTT interval
RTTmeasured throughput =
RTTmeasured
Delay-based approach:
 RTTmin - minimum observed RTT (uncongested path)
 Uncongested throughput with congestion window cwnd is cwnd/RTTmin
if measured throughput “very close” to uncongested throughput
increase cwnd linearly /* since path not congested */
else if measured throughput “far below” uncongested throughout
decrease cwnd linearly /* since path is congested */
57
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 BBR (Bottleneck Bandwidth and
Roundtrip) Congestion Control
• BBR builds on ideas in TCP Vegas
• BBR provides a “queueless” congestion control
• A flow should ideally have data in-flight equal to Bandwidth Delay
Product (BDP)
– BDP = RTprop x BtlBw
– At this point, a connection completely saturates the bottleneck link with
no buffer(queue)
• Definition of congestion…?
– In-flight data more than BDP (for a long duration) considered as
congestion
Congestion Based Congestion Control- BBR [N Cardwell 2016]
58
Advanced Computer Networks CS G525 BITS Pilani, Pilani Campus
BBR (Bottleneck Bandwidth and Roundtrip
propagation)
• RTprop and BtlBw cannot be measured
simultaneously. Why?
– Measuring RTprop requires operating to the left of
BDP while measuring BtlBw requires operation
to the right.

59
Advanced Computer Networks CS G525 BITS Pilani, Pilani Campus
Evolving Transport-Layer Functionality
• TCP, UDP: principal transport protocols for 40 years
• Different “flavors” of TCP developed, for specific scenarios:
Scenario Challenges
Long, fat pipes (large data Many packets “in flight”; loss shuts down
transfers) pipeline
Wireless networks Loss due to noisy wireless links, mobility;
TCP treat this as congestion loss
Long-delay links Extremely long RTTs
Data center networks Latency sensitive
Background traffic flows Low priority, “background” TCP flows

 Moving transport–layer functions to application layer, on top of UDP

• HTTP/3: QUIC
60
Computer Networks (CS F303) BITS Pilani, Pilani Campus
QUIC: Quick UDP Internet Connections

• Application-layer protocol, on top of UDP

– Increase performance of HTTP
– Deployed on many Google servers, apps (Chrome, mobile YouTube app)

HTTP/2 HTTP/2 (slimmed)

Application HTTP/3
TLS QUIC

Transport TCP UDP

Network IP IP

HTTP/2 over TCP HTTP/2 over QUIC over UDP

61
Computer Networks (CS F303) BITS Pilani, Pilani Campus
QUIC: Quick UDP Internet Connections

• Error and congestion control:

• Similar approaches which have been used in TCP
• Connection establishment:
• Reliability, congestion control, authentication, encryption, state
established in one RTT

• Multiple application-level “streams” multiplexed over single QUIC

connection
– Separate reliable data transfer, security
– Common congestion control
62
Computer Networks (CS F303) BITS Pilani, Pilani Campus
QUIC: Connection Establishment

TCP handshake
(transport layer) QUIC handshake

data
TLS handshake
(security)
data

TCP (reliability, congestion control QUIC: reliability, congestion control,

state) + TLS (authentication, crypto authentication, crypto state
state)
 1 handshake
 2 serial handshakes
63
Computer Networks (CS F303) BITS Pilani, Pilani Campus
 QUIC: Streams: Parallelism, No HOL
Blocking
HTTP HTTP
GET GET HTTP
GET
HTTP HTTP
application

GET GET
HTTP
GET QUIC QUIC QUIC QUIC QUIC QUIC
encrypt encrypt encrypt encrypt encrypt encrypt
QUIC QUIC QUIC QUIC QUIC QUIC
TLS encryption TLS encryption RDT RDT RDT RDT
error!
RDT RDT

QUIC Cong. Cont. QUIC Cong. Cont.

TCP RDT TCP
error! RDT
transport

TCP Cong. Contr. TCP Cong. Contr. UDP UDP

(a) HTTP 1.1 (b) HTTP/2 with QUIC: no HOL blocking

64
Computer Networks (CS F303) BITS Pilani, Pilani Campus
What’s Next…

• Network Layer (Internet Protocol)

– Network layer service models (Internet and ATM)
– Forwarding versus Routing
– How a router works?
– IPv4 Datagram Structure and IP Protocol
– IPv4 Addressing
• Hierarchical Addressing
• NAT, Sub Netting, IPv4 to IPv6 translation, ICMP protocol
– Routing Algorithms and Protocols
• Inter-domain Routing (OSPF, RIP) and Intra-domain routing (BGP)
– Multicast Routing
65
Computer Networks (CS F303) BITS Pilani, Pilani Campus
Thank You

66
Computer Networks (CS F303) BITS Pilani, Pilani Campus