Week4 Modified

Chapter 3
Transport Layer
Computer Networking: A
Top-Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
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: roadmap
▪ Transport-layer services
▪ Multiplexing and demultiplexing
▪ Connectionless transport: UDP
▪ Connection-oriented transport: TCP
▪ Principles of congestion control
▪ TCP congestion control
▪ Evolution of transport-layer
functionality

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

Transport Layer Actions
Sender:
application ▪ is passed an application- application
app. msg
layer message
transport ▪ determines segment TThhtransport
app. msg
header fields values
network (IP) ▪ creates segment network (IP)
link ▪ passes segment to IP link
physical physical

Transport Layer Actions
Receiver:
application ▪ receives segment from IP application
▪ checks header values
transport
app. msg ▪ extracts application-layer transport
message
network (IP) network (IP)
▪ demultiplexes message up
link to application via socket link
physical physical
Th app. msg

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

Chapter 3: roadmap
▪ Transport-layer services
▪ Multiplexing and demultiplexing
▪ Connectionless transport: UDP
▪ Connection-oriented transport: TCP
▪ Principles of congestion control
▪ TCP congestion control
▪ Evolution of transport-layer
functionality

HTTP server
client
application application
HTTP msg
transport
transport network transport

network link network
link physical link
physical physical

HTTP server
client
HTTP msg
transport
Ht HTTP msg

link physical link
physical physical

HTTP server
client
HTTP msg
transport
Ht HTTP msg
Hnnetwork
Ht HTTP msg transport
transport
link physical link
physical physical

HTTP server
client
transport

link physical link
physical physical
Hn Ht HTTP msg

HTTP server
client1 client2
application P-client1 P-client2 application
transport

link physical link
physical physical

Multiplexing/demultiplexing
multiplexing at sender: demultiplexing at 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
link physical link
physical physical

How demultiplexing works
▪ host receives IP datagrams 32 bits
• each datagram has source IP source port # dest port #
address, destination IP address
• each datagram carries one other header fields
transport-layer segment
• each segment has source, application
destination port number data
▪ host uses IP addresses & port (payload)
numbers to direct segment to
appropriate socket TCP/UDP segment format

Connection-oriented demultiplexing
▪ TCP socket identified by ▪ server may support many
4-tuple: simultaneous TCP sockets:
• source IP address • each socket identified by its
• source port number own 4-tuple
• dest IP address • each socket associated with
• dest port number a different connecting client
▪ demux: receiver uses all
four values (4-tuple) to
direct segment to
appropriate socket
Connection-oriented demultiplexing: example
application
application P4 P5 P6 application
P1 P2 P3
transport
transport transport
network
link physical link
physical server: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
Three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets
Summary
▪ Multiplexing, demultiplexing: based on segment, datagram
header field values
▪ UDP: demultiplexing using destination port number (only)
▪ TCP: demultiplexing using 4-tuple: source and destination IP
addresses, and port numbers
▪ Multiplexing/demultiplexing happen at all layers

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
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

UDP: User Datagram Protocol [RFC 768]

UDP: Transport Layer Actions
SNMP client SNMP server
transport transport
(UDP) (UDP)
network (IP) network (IP)
link link
physical physical


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


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

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

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)

UDP checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
sender: receiver:
▪ treat contents of UDP ▪ compute checksum of received
segment (including UDP header segment
fields and IP addresses) as
sequence of 16-bit integers ▪ check if computed checksum equals
▪ checksum: addition (one’s checksum field value:
complement sum) of segment • Not equal - error detected
content • Equal - no error detected. But maybe
▪ checksum value put into errors nonetheless? More later ….
UDP checksum field
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/
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

Reliable Protocol
▪ In computer networking, a reliable protocol is a communication
protocol that notifies the sender whether or not the delivery of data
to intended recipients was successful.
▪ Reliability is a synonym for assurance.
▪ Reliable protocols typically incur more overhead than unreliable
protocols, and as a result, function more slowly and with less
scalability.
(Source Wikipedia)

Principles of reliable data transfer
sending receiving
process process
application data data
transport
sender-side of receiver-side
Complexity of reliable data reliable data
transfer protocol
of reliable data
transfer protocol
transfer protocol will depend
(strongly) on characteristics of transport
network
unreliable channel (lose, unreliable channel
corrupt, reorder data?)
reliable service implementation

Principles of reliable data transfer
sending receiving
process process
application data data
transport
sender-side of receiver-side
reliable data of reliable data
Sender, receiver do not know transfer protocol transfer protocol
the “state” of each other, e.g.,
was a message received? transport
network
▪ unless communicated via a unreliable channel
message
reliable service implementation

channel with bit errors
▪ underlying channel may flip bits in packet
• checksum to detect bit errors
▪ the question: how to recover from errors?
• acknowledgements (ACKs): receiver explicitly tells sender that pkt
received OK
• negative acknowledgements (NAKs): receiver explicitly tells sender
that pkt had errors
• sender retransmits pkt on receipt of NAK

channels with errors and loss
New channel assumption: underlying channel can also lose
packets (data, ACKs)
• checksum, sequence #s, ACKs, retransmissions will be of help …
but not quite enough
Q: How do humans handle lost sender-to-

receiver words in conversation?

rdt3.0: channels with errors and loss
Approach: sender waits “reasonable” amount of time for ACK
▪ retransmits if no ACK received in this time
▪ if pkt (or ACK) just delayed (not lost):
• retransmission will be duplicate, but seq #s already handles this!
• receiver must specify seq # of packet being ACKed
▪ use countdown timer to interrupt after “reasonable” amount
of time
timeout

TCP segment structure
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
management (variable length) TCP socket

rdt3.0: stop-and-wait operation
sender receiver
first packet bit transmitted, t = 0
first packet bit arrives

RTT last packet bit arrives, send ACK
ACK arrives, send next

packet, t = RTT + L / R

Pipelining: increased utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R
first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
3-packet pipelining increases
utilization by a factor of 3!
U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008

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

TCP fast retransmit
Host A Host B
TCP fast retransmit
if sender receives 3 additional
ACKs for same data (“triple
duplicate ACKs”), resend unACKed
segment with smallest seq # X
▪ likely that unACKed segment lost,
so don’t wait for timeout
timeout
Receipt of three duplicate ACKs
indicates 3 segments received Seq=100, 20 bytes of data
after a missing segment – lost

segment is likely. So retransmit!

Go-Back-N: sender
▪ sender: “window” of up to N, consecutive transmitted but unACKed pkts
• k-bit seq # in pkt header
▪ cumulative ACK: ACK(n): ACKs all packets up to, including seq # n

• on receiving ACK(n): move window forward to begin at n+1
▪ timer for oldest in-flight packet
▪ timeout(n): retransmit packet n and all higher seq # packets in window
Go-Back-N: receiver
▪ ACK-only: always send ACK for correctly-received packet so far, with
highest in-order seq #
• may generate duplicate ACKs
• need only remember rcv_base
▪ on receipt of out-of-order packet:
• can discard (don’t buffer) or buffer: an implementation decision
• re-ACK pkt with highest in-order seq #
Receiver view of sequence number space:

received and ACKed
… … Out-of-order: received but not ACKed
rcv_base
Not received
Go-Back-N in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
pkt 2 timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5

Selective repeat
▪receiver individually acknowledges all correctly received packets
• buffers packets, as needed, for eventual in-order delivery to upper
layer
▪sender times-out/retransmits individually for unACKed packets
• sender maintains timer for each unACKed pkt
▪sender window
• N consecutive seq #s
• limits seq #s of sent, unACKed packets

Selective repeat: sender, receiver windows

Selective repeat: sender and receiver
sender receiver
data from above: packet n in [rcvbase, rcvbase+N-1]
▪ if next available seq # in ▪ send ACK(n)
window, send packet ▪ out-of-order: buffer
timeout(n): ▪ in-order: deliver (also deliver
buffered, in-order packets),
▪ resend packet n, restart timer advance window to next not-yet-
ACK(n) in [sendbase,sendbase+N]: received packet
▪ mark packet n as received packet n in [rcvbase-N,rcvbase-1]
▪ if n smallest unACKed packet, ▪ ACK(n)
advance window base to next otherwise:
unACKed seq # ▪ ignore

Selective Repeat in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5
record ack3 arrived send ack4
pkt 2 timeout send ack5
012345678 send pkt2
012345678 (but not 3,4,5)
012345678 rcv pkt2; deliver pkt2,
012345678 pkt3, pkt4, pkt5; send ack2
Q: what happens when ack2 arrives?

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 data checksum urg pointer
window size
Acknowledgements: N
• 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
(“in-flight”) yet sent
Q: how receiver handles out-of-
order segments outgoing segment from receiver
• A: TCP spec doesn’t say, - up

source port # dest port #
sequence number
to implementor acknowledgement number

A rwnd
checksum urg pointer
TCP sequence numbers, ACKs
Host A Host B
User types‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs receipt
of‘C’, echoes back ‘C’
Seq=79, ACK=43, data = ‘C’
host ACKs receipt
of echoed ‘C’
Seq=43, ACK=80
simple telnet scenario

TCP Sender (simplified)
event: data received from event: timeout
application ▪ retransmit segment that
caused timeout
▪ create segment with seq #
▪ restart timer
▪ seq # is byte-stream number
of first data byte in segment
event: ACK received
▪ start timer if not already
running ▪ if ACK acknowledges
previously unACKed segments
• think of timer as for oldest
unACKed segment • update what is known to be
ACKed
• expiration interval:
TimeOutInterval • start timer if there are still
unACKed segments
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
flow control
receiver controls sender, so
sender won’t overflow IP
code
receiver’s buffer by
transmitting too much, too fast
from sender
receiver protocol stack

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., starting seq #s)
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 number"); welcomeSocket.accept();
Agreeing to establish a connection
2-way handshake:
Q: will 2-way handshake always

Let’s talk work in network?
ESTAB
ESTAB
OK ▪ variable delays
▪ retransmitted messages (e.g.
req_conn(x)) due to message loss
▪ message reordering
choose x
req_conn(x) ▪ can’t “see” other side
ESTAB
acc_conn(x)
ESTAB

Principles of congestion control
Congestion:
▪ informally: “too many sources sending too much data too fast for
network to handle”
▪ manifestations:
• long delays (queueing in router buffers)
• packet loss (buffer overflow at routers)
▪ different from flow control! congestion control:
▪ a top-10 problem! too many senders,
sending too fast
flow control: one sender

too fast for one receiver
Closing a TCP 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

Week4 Modified

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Week4 Modified

Uploaded by

Copyright:

Available Formats

Chapter 3

Transport Layer: 3-2

Transport Layer: 3-3

▪ provide logical communication mobile network

running on different hosts

into segments, passes to network layer home network content

▪ two transport protocols available to data link

Internet applications enterprise

Transport Layer: 3-5

link ▪ passes segment to IP link

Transport Layer: 3-6

Transport Layer: 3-7

▪ TCP: Transmission Control Protocol mobile network

• unreliable, unordered delivery home network content

• delay guarantees physical

• bandwidth guarantees enterprise

Transport Layer: 3-8

Transport Layer: 3-9

transport network transport

Transport Layer: 3-10

transport network transport

Transport Layer: 3-11

Transport Layer: 3-12

transport network transport

Transport Layer: 3-13

transport network transport

Transport Layer: 3-14

application P1 P2 application socket

Transport Layer: 3-15

Transport Layer: 3-16

host: IP source IP,port: B,80 host: IP

Transport Layer: 3-21

Transport Layer: 3-23

Transport Layer: 3-24

SNMP client SNMP server

network (IP) network (IP)

Transport Layer: 3-25

SNMP client SNMP server

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

link ▪ passes segment to IP link

Transport Layer: 3-26

SNMP client SNMP server

Transport Layer: 3-27

application length, in bytes of

Transport Layer: 3-28

Transport Layer: 3-29

Transport Layer: 3-32

Transport Layer: 3-33

Transport Layer: 3-34

Transport Layer: 3-35

Transport Layer: 3-36

Q: How do humans handle lost sender-to-

Transport Layer: 3-37

Transport Layer: 3-38

source port # dest port # segment seq #: counting

options (variable length)

Transport Layer: 3-39

first packet bit arrives

ACK arrives, send next

Transport Layer: 3-40

first packet bit arrives

Transport Layer: 3-41

Seq=100, 20 bytes of data