E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
1
EE 586 Communication andSwitching Networks
Lecture 9
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
Chapter 3: Transport Layer
Three Questions:
How do, say a webserver at port 80, differentiateand response to two different clients? (3.2, 3.3)
How can an end-to-end protocol eliminate ALLnetwork error along the way? (3.4, 3.5)
How can an end-to-end protocol prevent thecollapse of the Internet (3.6, 3.7)
First, a bit of an overview …
2
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
access_point_stylized_small
antenna_radiation_stylized
cell_tower_radiation_gray
access_point_stylized_gray_small
access_point_stylized_gray_small
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
car_icon_small
iphone_stylized_small
antenna_radiation_stylized
antenna_stylized
laptop_keyboard
screen
antenna_stylized
laptop_keyboard
screen
antenna_stylized
laptop_keyboard
screen
desktop_computer_stylized_medium
antenna_stylized
laptop_keyboard
screen
underline_base
Transport services and protocols
provide logical communicationbetween app processesrunning on different hosts
transport protocols run in endsystems
send side: breaks appmessages into segments,passes to  network layer
receiver side: reassemblessegments into messages,passes to app layer
more than one transportprotocol available to apps
Internet: TCP and UDP
application
transport
network
data link
physical
logical end-end transport
application
transport
network
data link
physical
3
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
UDP: User Datagram Protocol [RFC 768]
no frills, bare bonesInternet transportprotocol
best effort service,UDP segments may be:
lost
delivered out-of-orderto app
connectionless:
no handshakingbetween UDP sender,receiver
each UDP segmenthandled independentlyof others
UDP use:
streaming multimediaapps (loss tolerant, ratesensitive)
DNS
SNMP
reliable transfer overUDP:
add reliability atapplication layer
application-specific errorrecovery!
4
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
UDP: segment header
source port #
dest port #
32 bits
application
data
(payload)
UDP segment format
length
checksum
length, in bytes ofUDP segment,including header
no connectionestablishment (which canadd delay)
simple: no connectionstate at sender, receiver
small header size
no congestion control:UDP can blast away asfast as desired
why is there a UDP?
5
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
TCP: Overview  RFCs: 793,1122,1323, 2018, 2581
full duplex data:
bi-directional data flowin same connection
MSS: maximumsegment size
connection-oriented:
handshaking (exchangeof control msgs) initssender, receiver statebefore data exchange
flow controlled:
sender will notoverwhelm receiver
point-to-point:
one sender, onereceiver
reliable, in-order bytesteam:
no messageboundaries
pipelined:
TCP congestion andflow control set windowsize
underline_base
(modified by Cheung for EE586; based on K&R original)
6
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
TCP segment structure
source port #
dest port #
32 bits
application
data
(variable length)
sequence number
acknowledgement number
receive window
Urg data pointer
checksum
F
S
R
P
A
U
head
len
not
used
options (variable length)
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
# bytes
rcvr willing
to accept
counting
by bytes
of data
(not segments!)
Internet
checksum
(as in UDP)
(modified by Cheung for EE586; based on K&R original)
7
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-8
underline_base
TCP connection management
before exchanging data, sender/receiver handshake:
agree to establish connection (each knowing the other willingto establish connection)
agree on connection parameters
connection state: ESTAB
connection variables:
seq # client-to-server
         server-to-client
rcvBuffer size
   at server,client
 
application
network
connection state: ESTAB
connection Variables:
seq # client-to-server
          server-to-client
rcvBuffer size
   at server,client
 
application
network
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-9
Q: will 2-way handshakealways work innetwork?
variable delays
retransmitted messages(e.g. req_conn(x)) due tomessage loss
message reordering
Alice
Bob
2-way handshake:
Lets talk
OK
ESTAB
ESTAB
choose x
req_conn(x)
ESTAB
ESTAB
acc_conn(x)
underline_base
Agreeing to establish a connection
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-10
underline_base
Agreeing to establish a connection
2-way handshake failure:
retransmit
req_conn(x)
ESTAB
req_conn(x)
half open connection!
(no client!)
clientterminates
server
forgets x
connection
x completes
choose x
req_conn(x)
ESTAB
ESTAB
acc_conn(x)
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-11
underline_base
TCP 3-way handshake
SYNbit=1, Seq=x
choose init seq num, x
send TCP SYN msg
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
SYNSENT
ESTAB
SYN RCVD
client state
LISTEN
server state
LISTEN
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-12
underline_base
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 ownFIN
simultaneous FIN exchanges can be handled
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-13
underline_base
FIN_WAIT_2
CLOSE_WAIT
FINbit=1, seq=y
ACKbit=1; ACKnum=y+1
ACKbit=1; ACKnum=x+1
 wait for server
close
can still
send data
can no longer
send data
LAST_ACK
CLOSED
TIMED_WAIT
 timed wait
for 2*max
segment lifetime
CLOSED
TCP: closing a connection
FIN_WAIT_1
FINbit=1, seq=x
can no longer
send but can
 receive data
clientSocket.close()
client state
server state
ESTAB
ESTAB
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
Let’s start with the first question
Three Questions:
How do, say a webserver at port 80, differentiateand response to two different clients? (3.2, 3.3)
How can an end-to-end protocol eliminate ALLnetwork error along the way? (3.4, 3.5)
How can an end-to-end protocol prevent thecollapse of the Internet (3.6, 3.7)
14
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
Multiplexing/demultiplexing
process
socket
use header info to deliver
received segments to correct
socket
demultiplexing at receiver:
handle data from multiple
sockets, add transport header(later used for demultiplexing)
multiplexing at sender:
transport
application
physical
link
network
P2
P1
transport
application
physical
link
network
P4
transport
application
physical
link
network
P3
desktop_computer_stylized_medium
desktop_computer_stylized_medium
15
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
How demultiplexing works
host receives IP datagrams
each datagram has source IPaddress, destination IPaddress
each datagram carries onetransport-layer segment
each segment has source,destination port number
host uses IP addresses &port numbers to directsegment to appropriatesocket
source port #
dest port #
32 bits
application
data
(payload)
other header fields
TCP/UDP segment format
16
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Transport Layer
3-17
underline_base
Connectionless demultiplexing
server: created socket hashost-local port #:
  bind(sockid,port,size)
when host receives UDPsegment:
checks destination port #in segment
directs UDP segment tosocket with that port #
client: when creatingdatagram to send intoUDP socket, must specify
destination IP address
destination port #
IP datagrams with samedest. port #, but differentsource IP addressesand/or source portnumbers will be directedto same socket at dest
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Connection-oriented demux
TCP socket identifiedby 4-tuple:
source IP address
source port number
dest IP address
dest port number
demux: receiver usesall four values to directsegment to appropriatesocket
server host may supportmany simultaneous TCPsockets:
each socket identified byits own 4-tuple
web servers havedifferent sockets foreach connecting client
non-persistent HTTP willhave different socket foreach request
underline_base
18
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Connection-oriented demux: example
transport
application
physical
link
network
P3
transport
application
physical
link
transport
application
physical
link
network
P2
dest IP, port: B,80
source IP,port: B,80
dest IP,port: A,9157
host: IPaddress A
host: IPaddress C
server: IP address B
network
P3
dest IP,port: B,80
dest IP,port: B,80
P4
web server
underline_base
desktop_computer_stylized_medium
desktop_computer_stylized_medium
19
(modified by Cheung for EE586; based on K&R original)
three segments, all destined to IP address: B, dest port: 80 are demultiplexedto different sockets based on source IP address and source port
source IP,port: A,9157
source IP,port: C,9157
source IP,port: C,5775
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
Move on to the 2nd question
Three Questions:
How do, say a webserver at port 80, differentiateand response to two different clients? (3.2, 3.3)
How can an end-to-end protocol eliminate ALLnetwork error along the way? (3.4, 3.5)
How can an end-to-end protocol prevent thecollapse of the Internet (3.6, 3.7)
20
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
well:
incrementally develop sender, receiver sides ofreliable data transfer protocol (rdt)
consider only unidirectional data transfer
but control info will flow on both directions!
use finite state machines (FSM)  to specify sender,receiver
state
1
state
2
event causing state transition
actions taken on state transition
state: when in thisstate next stateuniquely determinedby next event
event
actions
underline_base
Reliable data transfer: getting started
21
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
Reliable data transfer: getting started
rdt_part2
send
side
receive
side
rdt_send(): called from above,(e.g., by app.). Passed data to
deliver to receiver upper layer
udt_send(): called by rdt,
to transfer packet over
unreliable channel to receiver
rdt_rcv(): called when packetarrives on rcv-side of channel
deliver_data(): called byrdt to deliver data to upper
22
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
rdt1.0: reliable transfer over a reliable channel
underlying channel perfectly reliable
no bit errors
no loss of packets
separate FSMs for sender, receiver:
sender sends data into underlying channel
receiver reads data from underlying channel
Wait forcall fromabove
packet = make_pkt(data)
udt_send(packet)
rdt_send(data)
extract (packet,data)
deliver_data(data)
Wait forcall frombelow
rdt_rcv(packet)
sender
receiver
underline_base
23
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Somewhat noisy channel
may cause some bits to flip from 1 to 0 or vice versa
no packet loss
Two questions:
1.How do you detect bit error?
2.How do you correct the detected bit error?
Answers:
1.Checksum
2.Ask the sender to resend – “retransmission”
rdt2.0: channel with bit errors
underline_base
24
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
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
1  1  0  1  1  1  0  1  1  1  0  1  1  1  0  1  1
1  1  0  1  1  1  0  1  1  1  0  1  1  1  1  0  0
1  0  1  0  0  0  1  0  0  0  1  0  0  0  0  1  1
wraparound
sum
checksum
Note: when adding numbers, a carryout from the mostsignificant bit needs to be added to the result – this is 1’scomplement arithmetic (not 2’s complement!)
25
(modified by Cheung for EE586; based on K&R original)
data
data
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Checksum (no bit error)
Receiver receives
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
1  0  1  0  0  0  1  0  0  0  1  0  0  0  0  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  0
wraparound
checksum
data
data
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
underline_base
26
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Checksum (bit errors)
Receiver receives with 3 bit error
The receiver does not know which bitsare wrong – error detecting but notcorrecting
1  1  1  1  0  0  1  1  0  0  1  1  0  0  1  0  0
1  1  1  0  1  1  1  0  1  0  1  0  1  0  1  0  1
1  0  1  0  0  0  1  0  0  0  0  0  0  0  0  1  1
1  1  1  1  1  0  1  1  1  1  0  1  1  1  1  0  0
wraparound
checksum
data
data
1  1  1  1  0  1  1  1  1  0  1  1  1  1  0  1
27
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Checksum (bit errors)
Receiver receives with 2 bit error
The receiver cannot detect someerror
1  1  1  1  0  0  1  1  0  0  1  1  0  0  1  0  0
1  1  1  0  1  0  1  0  1  0  1  0  1  0  1  1  1
1  0  1  0  0  0  1  0  0  0  1  0  0  0  0  1  1
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  0
wraparound
checksum
data
data
1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
28
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Why use 1’s complement?
Checksum is based on 1’s complement arithmeticwhich have two representations of zero:
1111111111111111
0000000000000000
The all zero’s is used to indicate that nochecksum is computed.
If the computed checksum is all zero, just turnthem into all ones and it would still work.
Try to compute 4-bit checksum: 0011 and 1100
0011 + 1100 = 1111  checksum = 0000
Receiver: 0011 + 1100 + 1111 = 1111 checked
(modified by Cheung for EE586; based on K&R original)
29
1111