Computer Network:

Transport Layer Protocols

Modified version:- Rajesh Palit, Ph.D., North South University, Dhaka

Transport Layer: 3-1

Transport layer: overview
Our goal:
▪ understand principles ▪ learn about Internet transport
behind transport layer layer protocols:
services: • UDP: connectionless transport
• multiplexing, • TCP: connection-oriented reliable
demultiplexing transport
• reliable data transfer • TCP congestion control
• flow control
• congestion control

Transport Layer: 3-2

Transport services and protocols
application
transport

▪ provide logical communication mobile network

network
data link
physical
between application processes national or global ISP

running on different hosts

▪ transport protocols actions in end
systems: local or
• sender: breaks application messages regional ISP

into segments, passes to network layer home network content

• receiver: reassembles segments into provider
network datacenter
messages, passes to application layer application
transport
network
network

▪ two transport protocols available to data link

physical

Internet applications enterprise

network
• TCP, UDP
Transport Layer: 3-3
Transport vs. network layer services and protocols
household analogy:
12 kids in Ann’s house sending
letters to 12 kids in Bill’s
house:
▪ hosts = houses
▪ processes = kids
▪ app messages = letters in
envelopes
▪ transport protocol = Ann and Bill
who demux to in-house siblings
▪ network-layer protocol = postal
service

Transport Layer: 3-4

Transport vs. network layer services and protocols
household analogy:
▪transport layer:
12 kids in Ann’s house sending
communication between letters to 12 kids in Bill’s
processes house:
• relies on, enhances, network ▪ hosts = houses
layer services ▪ processes = kids
▪ app messages = letters in
envelopes
▪network layer: ▪ transport protocol = Ann and Bill
communication between who demux to in-house siblings
hosts ▪ network-layer protocol = postal
service

Transport Layer: 3-5

Transport Layer Actions

Sender: Receiver:
▪ is passed an application- ▪ receives segment from IP
layer message ▪ checks header values
▪ determines segment ▪ extracts application-layer
header fields values message
▪ creates segment
▪ demultiplexes message up
▪ passes segment to IP to application via socket

Transport Layer: 3-6

Two principal Internet transport protocols
application
transport

▪ TCP: Transmission Control Protocol mobile network

network
data link
physical
• reliable, in-order delivery national or global ISP

• congestion control
• flow control
• connection setup
local or
▪ UDP: User Datagram Protocol regional ISP

• unreliable, unordered delivery home network content

• no-frills extension of “best-effort” IP provider
network datacenter
application
network
▪ services not available: transport
network
data link

• delay guarantees physical

• bandwidth guarantees enterprise

network

Transport Layer: 3-7

Multiplexing/demultiplexing
multiplexing as sender: demultiplexing as receiver:
handle data from multiple use header info to deliver
sockets, add transport header received segments to correct
(later used for demultiplexing) socket

application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical

Transport Layer: 3-8

 application application

transport ? transport

multiplexing de-multiplexing
User Datagram Protocol (UDP)

Transport Layer: 3-10

UDP: User Datagram Protocol
Why is there a UDP?
▪ “no frills,” “bare bones”
Internet transport protocol ▪ no connection
establishment (which can
▪ “best effort” service, UDP add RTT delay)
segments may be: ▪ simple: no connection state
• lost at sender, receiver
• delivered out-of-order to app ▪ small header size
▪ connectionless: ▪ no congestion control
• no handshaking between UDP ▪ UDP can blast away as fast as
desired!
sender, receiver
▪ can function in the face of
• each UDP segment handled congestion
independently of others
Transport Layer: 3-11
UDP: User Datagram Protocol
▪ UDP use:
▪ streaming multimedia apps (loss
tolerant, rate sensitive)
▪ DNS
▪ SNMP
▪ HTTP/3
▪ if reliable transfer needed over UDP (e.g.,
HTTP/3):
▪ add needed reliability at application
layer
▪ add congestion control at application
layer

Transport Layer: 3-12

UDP: Transport Layer Actions

SNMP client SNMP server

UDP sender actions:
application ▪ is passed an application- application
SNMP msg
layer message
transport transport
▪ determines UDP segment UDP
UDPhh SNMP msg
(UDP) header fields values (UDP)

network (IP) ▪ creates UDP segment network (IP)

link ▪ passes segment to IP link

physical physical

Transport Layer: 3-13

UDP: Transport Layer Actions

SNMP client SNMP server

UDP receiver actions:
application ▪ receives segment from IP application
▪ checks UDP checksum
transport transport
SNMP msg header value
(UDP) (UDP)
▪ extracts application-layer
network
UDP h SNMP(IP)
msg message network (IP)
▪ demultiplexes message up
link link
to application via socket
physical physical

Transport Layer: 3-14

UDP segment header
32 bits
source port # dest port #
length checksum

application length, in bytes of

data UDP segment,
(payload) including header

data to/from
UDP segment format application layer

Transport Layer: 3-15

UDP checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
1st number 2nd number sum

Transmitted: 5 6 11

Received: 4 6 11

receiver-computed sender-computed
checksum
= checksum (as received)

Transport Layer: 3-16

Internet checksum: an example
example: add two 16-bit integers
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Note: when adding numbers, a carryout from the most significant bit needs to be
added to the result

* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-17
Internet checksum: weak protection!
example: add two 16-bit integers
0 1
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 Even though
numbers have
sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 changed (bit
flips), no change
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 in checksum!

Transport Layer: 3-18

Summary: UDP
▪ “no frills” protocol:
• segments may be lost, delivered out of order
• best effort service: “send and hope for the best”
▪ UDP has its plusses:
• no setup/handshaking needed (no RTT incurred)
• can function when network service is compromised
• helps with reliability (checksum)
▪ build additional functionality on top of UDP in application layer
(e.g., HTTP/3)
Transmission Control Protocol (TCP)

Transport Layer: 3-20

TCP: overview RFCs: 793,1122, 2018, 5681, 7323
▪ point-to-point: ▪ cumulative ACKs
• one sender, one receiver ▪ pipelining:
▪ reliable, in-order byte • TCP congestion and flow control
steam: set window size
• no “message boundaries" ▪ connection-oriented:
▪ full duplex data: • handshaking (exchange of control
• bi-directional data flow in messages) initializes sender,
same connection receiver state before data exchange
• MSS: maximum segment size ▪ flow controlled:
• sender will not overwhelm receiver

Transport Layer: 3-21

 ❑ Acknowledgement
Principles of reliable data transfer ❑
❑
Retransmission
Error Detection
❑ Flow Control

sending receiving sending receiving

process process process process
application data data application data data
transport transport
reliable channel
sender-side of receiver-side
reliable service abstraction reliable data of reliable data
transfer protocol transfer protocol

Complexity of reliable data transfer transport

network
protocol will depend (strongly) on unreliable channel
characteristics of unreliable channel
(lose, corrupt, reorder data?) reliable service implementation

Transport Layer: 3-22

 Byte Stream

Example: A file is viewed as a stream of bytes.

In fact, data produced by any source is considered as a stream of bytes.
Bytes have individual IDs. ➔ Bytes are individually numbered.

ISN+1 ISN+10 ISN+16 ISN+26 ISN+30

ISN: Initial Sequence Number

3-23
 TCP: Retransmission Scenarios
Host A Host B Host A Host B
Host A Host B

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

timeout
timeout

ACK=100 Seq=100, 20 bytes of data

X ACK=100
ACK=100 X
ACK=120
ACK=120
Seq=92, 8 bytes of data Seq=92, 8
SendBase=100 bytes of data send cumulative
SendBase=120 ACK for 120 Seq=120, 15 bytes of data
ACK=100
ACK=120

SendBase=120
cumulative ACK covers
lost ACK scenario early timeout for earlier lost ACK

Transport Layer: 3-24

 Piggybacking
Data
ACK
Client
Data Server

ACK

Small segments produce extra overhead:

transmission and processing at routers.

Data

Client
Data Server

25
 S=1 ➔ Seq. num. field carries ISN to be used
TCP Segment Structure S=0 ➔ Seq. num. = Seq. # of the first data byte in seg.

32 bits

source port # dest port # segment seq #: counting

ACK: seq # of next expected sequence number bytes of data into bytestream
byte; A bit: this is an ACK (not segments!)
acknowledgement 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
U: URG (Urgent)
management (variable length)
A: ACK
TCP socket
P: PSH (Push)
R: RST (Reset)
S: SYN (Sync.)
MSS: Maximum Segment Size
F: FIN (Finish)
Transport Layer: 3-26
TCP: Header
▪ Source/destination Ports
• Port: A 16-bit local unique number on the host
• Port + Host IP => Unique end point of an application
• (Src Port + IP, Dst Port + IP): Unique connection ID
• Source and destination IP: NOT part of a TCP segment
▪ 32-bit seq. number
• SYN = 0 (DATA segment)
• Position of the first data byte of this segment in the sender’s
data stream
• SYN = 1
• ISN to be used in the sender’s byte stream. (in fact, ISN+1)
• Different each time a host requests a connection

3-27
TCP Sequence Numbers, 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 checksum urg pointer
data window size
N
acknowledgements:
• seq # of next byte
expected from other side sender sequence number space

• cumulative ACK sent sent, not- usable not

ACKed yet ACKed but not usable
Q: how receiver handles out- (“in- yet sent
flight”)
of-order segments incoming segment to sender
• A: TCP spec doesn’t say, - source port # dest port #
sequence number
up to implementor acknowledgement number
A rwnd
checksum urg pointer

Transport Layer 3-28

TCP: Header
▪ 32-bit ACK number
• Valid if ACK = 1
• Identifies the sequence number of the NEXT data byte that the
sender of the ACK expects to receive.
▪ Header length in 4-byte units
• Let's the receiver know the beginning of the data area due to the
variable length of the Option field.
▪ Reserved (6 bits)
• For future use. All 0’s.

3-29
TCP: Header
▪ URG: ‘1’ => Urgent Pointer is valid
▪ ACK: ‘1’ => ACK Seq# is valid
▪ PSH:
• ‘1’: The receiving TCP module passes the data to the
application immediately
• ‘0’: The receiving TCP module may delay the data
▪ RST: ‘1’ => Tells the receiver to abort the conn.
▪ SYN: This bit requests a connection
▪ FIN
• ‘1’: Sender has no more data to send, but is ready to receive.

3-30
TCP: Header
▪ Window Size
• The number of bytes the sender is willing to receive.
• Used in flow control and congestion control
▪ Checksum: For error detection; scope: complete seg.
▪ Urgent Pointer: Valid if URG = ‘1’
• Urgent data
• Start byte is not specified, but it is considered to be the
start of the seg.
• Final byte in receiver’s buffer: Seq# + Urgent Pointer
• The sender can send “control” information to the receiver to
be processed on a priority basis.

3-31
TCP: Header Options
▪ MSS
• The Max Segment Size accepted by the sender
• Specified during connection set up
▪ Window Scale
• Allows the use of a larger advertised Window Size
▪ Time Stamp
• Used in Round-Trip Time (RTT) calculation
• Intended to be used on high-speed connection
• Sequence number may wrap around during a connection.
• New segments are distinguished from old segments by means
of time stamps

3-32
TCP Connection

Transport Layer: 3-33

TCP Connection: 3-way handshake
▪Use these fields to understand the opening of a connection
• Connection Request (SYN)
• Sequence Number (ISN)
• Acknowledgement (ACK)
• Receive Window Size (RWND)

Transport Layer: 3-34

 TCP 3-way handshake
Server state
serverSocket = socket(AF_INET,SOCK_STREAM)
Client state serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept()
LISTEN
clientSocket.connect((serverName,serverPort)) 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

Transport Layer: 3-35

TCP Connection: 3-way handshake
▪ SYN segment from client to server
• SYN = 1
• A random initial Seq# (ISN)
• RWND is undefined (defined later)
• Options
▪ SYN+ACK segment from server to client
• SYN = 1
• A random initial Seq# (ISN)
• ACK = 1 (server acks the received SYN segment)
• Ack Seq.#: The sequence # of first data byte to
be received
• RWND: Receive window size
▪ ACK from client to server
• ACKs the second SYN segment
• RWND
Transport Layer: 3-36
TCP: Closing a connection

❖client, server each close their side of connection

▪ send TCP segment with FIN bit = 1
❖respond to received FIN with ACK
▪ on receiving FIN, ACK can be combined with own FIN
❖simultaneous FIN exchanges can be handled

Transport Layer: 3-37

Closing a TCP connection
client state server state
ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 can no longer FINbit=1, seq=x
send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close

LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime

CLOSED

Transport Layer: 3-38

 Client TCP Operation Server

LISTEN Closed
Closed
Active open Passive open
SYN

SENT
SYN
SYN+ACK

RCVD
SYN
ACK
Read/Write

Established
Read/Write

Established
Active close
FIN

WAIT-1
FIN
ACK

CLOSE
WAIT
Passive close
WAIT-2
FIN

LAST
FIN

ACK
2MSL timer
WAIT
TIME

ACK

Closed
Server states
Closed

Client states
Transport Layer: 3-39
ACK Generation Rules
▪ When an in-order data segment is received, delay the
ACK until
• Another data segment is received, OR
• 500 milliseconds have elapsed
▪ When an out of sequence segment with a higher
sequence # arrives
• Send an ACK with the expected seq#
▪ When a missing segment arrives
• Send an ACK to announce the next seq# expected.
▪ If a duplicate segment arrives, immediately send an
ACK
Transport Layer: 3-40
TCP Flow Control

Transport Layer: 3-41

TCP Flow Control
▪ Regulates the amount of data a source can send
before receiving an ACK.
▪ Sliding Window Protocol with selective repeat is
used.
• The bytes within the window are the bytes that
can be in transit.
▪ The receiver can open/shrink/close its window,
dynamically.
▪ FC is performed by the receiver.

Transport Layer: 3-42

TCP flow control
application
Q: What happens if network Application removing
process
layer delivers data faster than data from TCP socket
buffers
application layer removes TCP socket
data from socket buffers? receiver buffers

TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers
code

flow control
receiver controls sender, so sender from sender
won’t overflow receiver’s buffer
receiver protocol stack
by transmitting too much, too fast
Transport Layer: 3-43
TCP Silly Window Syndrome

▪ Silly Window Syndrome (SWS)

▪ (#of data bytes in a segment/segment length) is too small
▪ Example: 5 bytes of data; seg. length = 5 +20; ratio = 5/25 = 0.2
▪ 1000 bytes of data; seg. length = 1000 + 20; ratio = 1000/1020 =
0.98
▪ SWS occurs if
▪ the sender and/or the receiver is very slow.

3-44
TCP: Silly Window Syndrome (Sender produces small data blocks)

Server
Client
Read Write
Port Port

TCP TCP
IP/Link/PHY
Internet IP/LinkPHY

Nagle’s solution
Sender sends the first segment even if it is a small one.
Next, wait until an ACK is received OR a maximum-size segment is accumulated
before sending the next segment
…… and repeat “Next” ...

3-45
TCP: Silly Window Syndrome (Slow Receiver)
Client is emptying the buffer slowly ➔ RWND is small

Client Server
Read Write
Port Port

TCP TCP
IP/Link/PHY
Internet IP/Link/PHY
Receive buffer

Clarke’s solution
Send an ACK and close the window until another segment
can be received or buffer is ½ empty.
3-46
TCP Congestion Control

Transport Layer: 3-47

TCP: Congestion Control

Host
H H

Total Output rate

Network capacity Ideal behavior
Internet
(Net of routers) Desired behavior
No Undesired
congestion congestion behavior

Total Input rate

H H

Network input
Network output
3-48
Causes of congestion

▪ Packets arriving on many input links want to go on

the same output link
• Queue builds up for the outgoing link.
• Router starts dropping packets.
▪ Slow routers
• Queues build up if computing tasks take too much time.
• Buffer management, updating RT, running routing protocols
• looking up RT
▪ Hosts produce/download too much …

3-49
General Principles of Congestion Control
Monitor: A variety of metrics can be monitored.
Fraction of all packets discarded due to lack of buffer
Average queue length
Number of retransmitted packets
Average packet delay

Communicate: Notify the entities that need to take actions.

Fields in packet headers can be reserved to carry this info.
Hosts and routers can send probe packets to
enquire.
Adjust system operation: Take actions.
Deny service to some users.
Degrade service to some users.
Have users schedule their demand in a more predictable
manner. 3-50
All protocol layers contribute to congestion “prevention”
- Link layer

Don’t discard out-of-sequence packets.

(Selective-Repeat is better than Go-back-N.)
Reduce the # of smaller packets (e.g. piggyback ACKs).

- Network layer

Apply load balancing: Spread traffic over many paths.

Use good discard policies.
File transfer: Drop new packets.
Real-time: Drop old packets.
- TCP layer

Next …

3-51
 TCP: Congestion Control (CC)
▪ CC is achieved by controlling the transmission rate at the
sender after “detecting” congestion.
• Tx rate is controlled by controlling the window
size.
• Main idea in controlling CW (congestion window)
❖ Slow start (CW = 1 MSS)
but quickly speed up to congestion threshold (CT): 1,2,4, 8, …CT

❖ Congestion avoidance
beyond threshold, increase linearly: CW++, CW++, …, RWND

v Congestion detection
Go back to slow start ….

3-52
 TCP: Congestion Control
▪ Slow start ▪ Congestion Avoidance: Additive Inc.
✓ Initially, CW = 1: Tx 1 Seg. (MSS) ✓ Each time the whole window of
segs. is ACKed
✓ If ACK received before TO CW = CW + 1
CW = 2 (= CW x 2): Tx 2 Segs. (CWmax = RWND)
✓ If ACKs received before TO
CW = 4 (= CW x 2): Tx 4 Segs.
✓ If ACKs received before TO  Congestion Detection
CW = 8 (= CW x 2): Tx 8 Segs.
RTO timer goes off
:
✓ Continue until you hit a threshold:
CT = CW/2 and CW = 1
Congestion Threshold (CT)

3 duplicate ACKs received

(AAAA)
Normally, CT = 64 KBytes
CT = CW/2 and CW = 1
CT = CW/2 and CW = CT
Congestion Control

▪ Variable CT
▪ Congestion Threshold is also known as ssthresh
Transport Layer 3-54
TCP: Timers
Four kinds of timers

Retransmission Timeout (RTO) timer

Persistence Timer

Keep-Alive Timer

TIME-WAIT Timer (2*MSL timer)

3-55
Example RTT estimation:
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

Transport Layer 3-56

 TCP: Timers (RTO)
• Operation
• For each segment transmitted (except ACK and RST), start an RTO
• If RTO goes off, retransmit the segment and restart RTO
• RTO
Initially: Default value (60s)
After measurements (RTTM): RTO = RTTS + 4. RTTD

RTTS (RTT Smoothed): α = 0.125 (typical value)

After first measurement RTTS = RTTM
After another measurement RTTS = (1 – α )RTTS + α.RTTM

RTTD (RTT Deviation): β = 0.25 (typical value)

After first measurement RTTD = RTTM/2
After another measurement RTTD = (1 – β )RTTD + β. |RTTS – RTTM|

3-57
 TCP: Persistence Timer
• A receiver can close the window and reopen it with an ACK
▪ Problem: If the ACK is lost, there is deadlock.
▪ Solution:
✓ When a sending TCP receives a segment with RWND = 0, start a
persistence timer.

✓ Persistence timer goes off: Send a probe segment (1 byte

data) to alert the receiver.
✓ Persistence timer value
Initially: Equal to RTO
Subsequently: Doubled with each Tx of the probe.
Saturates at 60 sec.

3-58
 TCP: Timers (Keepalive and TIME-WAIT)
• Keepalive Timer
✓ To sustain mostly idle connections (as between BGP routers)
✓ Each time the server hears from a client
Reset the timer: 2 hours.
If the server does not hear from the client for 2 hours
Send a probe segment.
If there is no response after 10 probes (75 sec apart)
Assume that the client is down.

▪ TIME-WAIT Timer (2.MSL) Maximum Segment Lifetime

✓ Used during connection termination.

✓ Standard: MSL = 120 sec (implementations choose a smaller

value)
3-59
TCP Fairness

Transport Layer: 3-60

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
TCP connection 2 router
capacity R

Transport Layer: 3-61

Q: is TCP Fair?
Example: two competing TCP sessions:
▪ additive increase gives slope of 1, as throughout increases
▪ multiplicative decrease decreases throughput proportionally

R equal bandwidth share

Is TCP fair?
A: Yes, under idealized
loss: decrease window by factor of 2 assumptions:
congestion avoidance: additive increase ▪ same RTT
loss: decrease window by factor of 2
congestion avoidance: additive increase ▪ fixed number of sessions
only in congestion
avoidance

Connection 1 throughput R
Transport Layer: 3-62
Fairness: 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 , e.g., link of
tolerate packet loss rate R with 9 existing connections:
▪ there is no “Internet police” • new app asks for 1 TCP, gets rate R/10
policing use of congestion • new app asks for 11 TCPs, gets R/2
control

Transport Layer: 3-63

TCP Throughput
▪ avg. TCP thruput as function of window size, RTT?
• ignore slow start, assume there is always data to send
▪ W: window size (measured in bytes) where loss occurs
• avg. window size (# in-flight bytes) is ¾ W
• avg. thruput is 3/4W per RTT
3 W
avg TCP thruput = bytes/sec
4 RTT
W

W/2
Extra Slide: TCP Variants
▪ The most common TCP variant used today is CUBIC, which is the default congestion control
algorithm in many Linux kernels. Other notable TCP variants include Reno, New Reno, Vegas, and
SACK.
▪ CUBIC: CUBIC TCP is an updated version of TCP designed to handle high-bandwidth networks
effectively. It uses a cubic function for congestion window increase, improving scalability.
▪ Reno: Reno is a standard TCP implementation and was one of the earlier TCP variants. It's known
for its simple implementation but can be less efficient in certain network conditions.
▪ New Reno: New Reno improves upon Reno by addressing the problem of multiple packet loss
events and making the fast recovery algorithm more robust.
▪ Vegas: Vegas is another TCP variant that attempts to avoid congestion by dynamically adjusting
its window size based on observed round trip times (RTTs).
▪ SACK (Selective Acknowledgment): SACK allows the receiver to acknowledge individual packets
that were received in order, rather than cumulative acknowledgments. This helps with packet
loss recovery and is useful in certain network environments.

Transport Layer: 3-65

Chapter Summary
▪ principles behind transport Up next:
layer services: ▪ leaving the network
• multiplexing, demultiplexing “edge” (application,
• reliable data transfer transport layers)
• flow control ▪ into the network “core”
• congestion control
▪ two network-layer
▪ instantiation, implementation chapters:
in the Internet • data plane
• UDP • control plane
• TCP

Transport Layer: 3-66