1. These slides are adapted from Kurose and Ross
Transport Layer
Abusayeed Saifullah
CS 5600 Computer Networks
These slides are adapted from Kurose and Ross

2. Transport Layer our goals:
understand principles behind transport layer services:
multiplexing, demultiplexing
reliable data transfer
flow control
congestion control
learn about Internet transport layer protocols:
UDP: connectionless transport
TCP: connection-oriented reliable transport
TCP congestion control

3. Roadmap 1 transport-layer services 2 multiplexing and demultiplexing
3 connectionless transport: UDP
4 connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
5 principles of congestion control
6 TCP congestion control

4. Transport services and protocols
application
transport
network
data link
physical
provide logical communication between app processes running on different hosts
transport protocols run in end systems
send side: breaks app messages into segments, passes to network layer
rcv side: reassembles segments into messages, passes to app layer
more than one transport protocol available to apps
Internet: TCP and UDP
logical end-end transport
application
transport
network
data link
physical

5. Transport vs. network layer
network layer: logical communication between hosts
transport layer: logical communication between processes
relies on, enhances, network layer services
household analogy:
12 kids in Ann’s house sending letters to 12 kids in Bill’s house: Ann and Bill collect and distribute mails for their respective houses
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

6. Internet transport-layer protocols
application
transport
network
data link
physical
reliable, in-order delivery (TCP)
congestion control
flow control
connection setup
unreliable, unordered delivery: UDP
no-frills extension of “best-effort” IP
services not available:
delay guarantees
bandwidth guarantees
network
data link
physical
network
data link
physical
network
data link
physical
logical end-end transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical

7. Roadmap 1 transport-layer services 2 multiplexing and demultiplexing
3 connectionless transport: UDP
4 connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
5 principles of congestion control
6 TCP congestion control

8. Multiplexing/demultiplexing
handle data from multiple
sockets, add transport header (later used for demultiplexing)
multiplexing at sender:
use header info to deliver
received segments to correct
socket
demultiplexing at receiver:
application
application P1 P2
application
socket P3
transport P4
process
transport
network
transport
link
network
network
physical
link
link
physical
physical

9. Multiplexing Multiplexing requires that
Sockets have unique identifiers
Each transport layer segment has special fields that indicate the socket to which the segment is to be delivered
UDP socket is identified by
2-tuple: destination IP, destination port
TCP socket is identified by
4-tuple: dest IP, dest port, source IP, source port

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

11. Connectionless demultiplexing
recall: when creating datagram to send into UDP socket, must specify
destination IP address
destination port #
recall: created socket has host-local port #:
DatagramSocket mySocket = new DatagramSocket(12534);
when host receives UDP segment:
checks destination port # in segment
directs UDP segment to socket with that port #
IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest

12. Connectionless demux: example
DatagramSocket serverSocket = new DatagramSocket
(6428);
DatagramSocket mySocket2 = new DatagramSocket
(9157);
DatagramSocket mySocket1 = new DatagramSocket (5775);
application
application
application P1 P3 P4
transport
transport
transport
network
network
network
link
link
link
physical
physical
physical
source port: 6428
dest port: 9157
source port: ?
dest port: ?
source port: 9157
dest port: 6428
source port: ?
dest port: ?

13. Connection-oriented demux
TCP socket identified by 4-tuple:
source IP address
source port number
dest IP address
dest port number
demux: receiver uses all four values to direct segment to appropriate socket
server host may support many simultaneous TCP sockets:
each socket identified by its own 4-tuple
web servers have different sockets for each connecting client
non-persistent HTTP will have different socket for each request

14. Connection-oriented demux: example
application
application
application P4 P5 P6 P3 P2 P3
transport
transport
transport
network
network
network
link
link
link
physical
physical
physical
server: IP address B
source IP,port: B,80
dest IP,port: A,9157
host: IP address C
host: IP address A
source IP,port: C,5775
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

15. Connection-oriented demux: example
threaded server
application
application
application P4 P3 P2 P3
transport
transport
transport
network
network
network
link
link
link
physical
physical
physical
server: IP address B
source IP,port: B,80
dest IP,port: A,9157
host: IP address C
host: IP address A
source IP,port: C,5775
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

16. Roadmap 1 transport-layer services 2 multiplexing and demultiplexing
3 connectionless transport: UDP
4 connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
5 principles of congestion control
6 TCP congestion control

17. UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol
“best effort” service, UDP segments may be:
lost
delivered out-of-order to app
connectionless:
no handshaking between UDP sender, receiver
each UDP segment handled independently of others
UDP use:
streaming multimedia apps (loss tolerant, rate sensitive)
RIP
SNMP
reliable transfer over UDP:
add reliability at application layer
application-specific error recovery!

18. no congestion control  high loss rate
UDP: segment header
length, in bytes of UDP segment, including header
32 bits
source port #
dest port #
length
checksum
why is there a UDP?
no connection establishment (which can add delay)
simple: no connection state at sender, receiver
small header size
application
data
(payload)
UDP segment format
no congestion control  high loss rate

19. UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
sender:
treat segment contents, including header fields, as sequence of 16-bit integers
checksum: addition (one’s complement sum) of segment contents
sender puts checksum value into UDP checksum field
receiver:
compute checksum of received segment
check if computed checksum equals checksum field value:
NO - error detected
YES - no error detected.

20. Internet checksum: example
example: add two 16-bit integers
wraparound
sum
checksum
Kurose and Ross forgot to say anything about wrapping the carry and adding it to low order bit
Note: when adding numbers, a carryout from the most significant bit needs to be added to the result

21. Roadmap 1 transport-layer services 2 multiplexing and demultiplexing
3 connectionless transport: UDP
4 connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
5 principles of congestion control
6 TCP congestion control

22. TCP: Overview RFCs: 793,1122,1323, 2018, 2581 point-to-point:
one sender, one receiver
reliable, in-order byte steam:
pipelined:
TCP congestion and flow control set window size
full duplex data:
bi-directional data flow in same connection
MSS: maximum segment size
connection-oriented:
handshaking (exchange of control msgs) inits sender, receiver state before data exchange
flow controlled:
sender will not overwhelm receiver

23. TCP segment structure source port # dest port # sequence number
32 bits
URG: urgent data
(generally not used)
counting
by bytes
of data
(not segments!)
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
receive window
# bytes
rcvr willing
to accept
checksum
Urg data pointer
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
options (variable length)
application
data
(variable length)
Internet
checksum
(as in UDP)

24. TCP reliable data transfer
TCP creates rdt service on top of IP’s unreliable service
pipelined segments
cumulative acks
single retransmission timer
We have studied the protocols in data link layer
Similar

25. TCP flow control
receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments
RcvBuffer size set via socket options (typical default is 4096 bytes)
many operating systems autoadjust RcvBuffer
sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value
guarantees receive buffer will not overflow
to application process
buffered data
free buffer space
RcvBuffer
rwnd
TCP segment payloads
receiver-side buffering

26. 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
application
application
connection state: ESTAB
connection variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
connection state: ESTAB
connection Variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
network
network
Socket clientSocket =
newSocket("hostname","port number");
Socket connectionSocket = welcomeSocket.accept();

27. Agreeing to establish a connection
2-way handshake:
Q: will 2-way handshake always work in network?
retransmitted messages (e.g. req_conn(x)) due to message loss
can’t “see” other side
Let’s talk
ESTAB OK
ESTAB
choose x
req_conn(x)
ESTAB
acc_conn(x)
ESTAB

28. TCP 3-way handshake client state server state LISTEN SYNSENT
SYNbit=1, Seq=x
choose init seq num, x
send TCP SYN msg
SYN RCVD
ESTAB
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
choose init seq num, y
send TCP SYNACK
msg, acking SYN
ACKbit=1, ACKnum=y+1
received SYNACK(x)
indicates server is live;
send ACK for SYNACK;
this segment may contain
client-to-server data
received ACK(y)
indicates client is live
ESTAB

29. TCP: closing a connection
Connection release is easy but needs care
Asymmetric release
is the way the telephone system works:
when one party hangs up, the connection is broken.
Symmetric release
treats the connection as two separate unidirectional connections and
requires each one to be released separately.

30. Abrupt disconnection with loss of data 
Asymmetric Release
Abrupt disconnection with loss of data 
needs better protocol

31. Symmetric release
Symmetric release does the job when each process has a fixed amount of data to send and clearly knows when it has sent it.
One can envision a protocol in which host 1 says ‘‘I am done. Are you done too?’’ If host 2 responds: ‘‘I am done too. Goodbye, the connection can be safely released.’’
Unfortunately, this protocol does not always work: two-army problem.

32. Two-army problem

33. Two-army problem A white army is encamped in a valley.
On both surrounding hillsides are blue armies.
The white army is larger than either of the blue armies alone, but together the blue armies are larger than the white army.
If either blue army attacks by itself, it will be defeated, but if the two blue armies attack simultaneously, they will be victorious.

34. Two-army problem The blue armies want to synchronize their attacks.
However, their only communication medium is to send messengers on foot down into the valley, where they might be captured and the message lost (i.e., they have to use an unreliable communication channel).
The question is: does a protocol exist that allows the blue armies to win?

35. Two-army problem Answer: no protocol exists that works.
Relevance to connection release
substitute ‘‘disconnect’’ for ‘‘attack.’’
If neither side is prepared to disconnect until it is convinced that the other side is prepared to disconnect too, the disconnection will never happen.

36. solution to close a TCP connection
In practice, we can avoid this quandary by foregoing the need for agreement and letting each side independently decide when it is done.
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
While this protocol is not infallible, it is usually adequate.

37. solution to close a TCP connection
client state
server state
ESTAB
ESTAB
FIN_WAIT_1
FINbit=1, seq=x
can no longer
send but can
receive data
clientSocket.close()
CLOSE_WAIT
FIN_WAIT_2
ACKbit=1; ACKnum=x+1
wait for server
close
can still
send data
can no longer
send data
LAST_ACK
TIMED_WAIT
FINbit=1, seq=y
CLOSED
timed wait
CLOSED
ACKbit=1; ACKnum=y+1