Download lecture20

Transport Layer
Abusayeed Saifullah
CS 5600 Computer Networks
These slides are adapted from Kurose and Ross
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
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
Transport services and protocols



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
application
transport
network
data link
physical
application
transport
network
data link
physical
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 inhouse siblings
 network-layer protocol =
postal service
Internet transport-layer protocols

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
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
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
Multiplexing/demultiplexing
multiplexing at sender:
handle data from multiple
sockets, add transport header
(later used for demultiplexing)
demultiplexing at receiver:
use header info to deliver
received segments to correct
socket
application
application
P1
P2
application
P3
transport
P4
transport
network
transport
network
link
network
physical
link
link
physical
physical
socket
process
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
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
Connectionless demultiplexing

recall: created socket has
host-local port #:

DatagramSocket mySocket1
= new DatagramSocket(12534);

when host receives UDP
segment:
 checks destination port #
in segment
 directs UDP segment to
socket with that port #
recall: when creating
datagram to send into
UDP socket, must specify
 destination IP address
 destination 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
Connectionless demux: example
DatagramSocket
mySocket2 = new
DatagramSocket
(9157);
DatagramSocket
serverSocket = new
DatagramSocket
(6428);
application
application
DatagramSocket
mySocket1 = new
DatagramSocket
(5775);
application
P1
P3
P4
transport
transport
transport
network
network
link
network
link
physical
link
physical
physical
source port: 6428
dest port: 9157
source port: 9157
dest port: 6428
source port: ?
dest port: ?
source port: ?
dest port: ?
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
Connection-oriented demux: example
application
application
P4
P5
application
P6
P3
P3
P2
transport
network
network
link
network
link
physical
link
physical
host: IP
address A
transport
transport
server: IP
address B
source IP,port: B,80
dest IP,port: A,9157
source IP,port: A,9157
dest IP, port: B,80
three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets
physical
source IP,port: C,5775
dest IP,port: B,80
source IP,port: C,9157
dest IP,port: B,80
host: IP
address C
Connection-oriented demux: example
threaded server
application
application
P3
application
P4
P3
P2
transport
network
network
link
network
link
physical
link
physical
host: IP
address A
transport
transport
server: IP
address B
source IP,port: B,80
dest IP,port: A,9157
source IP,port: A,9157
dest IP, port: B,80
physical
source IP,port: C,5775
dest IP,port: B,80
source IP,port: C,9157
dest IP,port: B,80
host: IP
address C
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
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!
UDP: segment header
32 bits
source port #
dest port #
length
checksum
application
data
(payload)
length, in bytes of
UDP segment,
including header
why is there a UDP?



UDP segment format
no connection
establishment (which can
add delay)
simple: no connection
state at sender, receiver
small header size
no congestion control  high loss rate
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.
Internet checksum: example
example: add two 16-bit integers
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 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 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 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
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
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
TCP segment structure
32 bits
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
source port #
dest port #
sequence number
acknowledgement number
head not
UAP R S F
len used
checksum
counting
by bytes
of data
(not segments!)
receive window
Urg data pointer
options (variable length)
application
data
(variable length)
# bytes
rcvr willing
to accept
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
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
RcvBuffer
rwnd
buffered data
free buffer space
TCP segment payloads
receiver-side buffering
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();
Agreeing to establish a connection
2-way handshake:
Q: will 2-way handshake
always work in
network?
Let’s talk
ESTAB
OK
ESTAB


choose x
ESTAB
req_conn(x)
acc_conn(x)
ESTAB
retransmitted messages
(e.g. req_conn(x)) due to
message loss
can’t “see” other side
TCP 3-way handshake
client state
server state
LISTEN
LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT
received SYNACK(x)
indicates server is live;
ESTAB
send ACK for SYNACK;
this segment may contain
client-to-server data
SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
SYN RCVD
msg, acking SYN
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
ACKbit=1, ACKnum=y+1
received ACK(y)
indicates client is live
ESTAB
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.
Asymmetric Release
Abrupt disconnection with loss of data 
needs better protocol
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.
Two-army problem
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.
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?
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.
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.
solution to close a TCP connection
client state
server state
ESTAB
ESTAB
clientSocket.close()
FIN_WAIT_1
FIN_WAIT_2
can no longer
send but can
receive data
FINbit=1, seq=x
CLOSE_WAIT
ACKbit=1; ACKnum=x+1
wait for server
close
FINbit=1, seq=y
TIMED_WAIT
timed wait
CLOSED
can still
send data
LAST_ACK
can no longer
send data
ACKbit=1; ACKnum=y+1
CLOSED