Page 1
2/9/2017 CSE 3214 - S.Datta 1
CSE 3214: Computer NetworksProtocols and Applications
Suprakash [email protected]
Office: CSEB 3043Phone: 416-736-2100 ext 77875
Course page: http://www.cse.yorku.ca/course/3214
These slides are adapted from Jim Kurose’s slides.
Page 2
2/9/2017 CSE 3214 - S.Datta 2
Next
n The transport layer
Page 3
2/9/2017 CSE 3214 - S.Datta 3
Chapter 3: Transport Layer
Our goals:n understand principles
behind transport layerservices:n multiplexing/demultiplex-
ingn reliable data transfern flow controln congestion control
n learn about transport layerprotocols in the Internet:n UDP: connectionless
transportn TCP: connection-oriented
transportn TCP congestion control
Page 4
2/9/2017 CSE 3214 - S.Datta 4
Chapter 3 outline
n 3.1 Transport-layerservices
n 3.2 Multiplexing anddemultiplexing
n 3.3 Connectionlesstransport: UDP
n 3.4 Principles of reliabledata transfer
- LEAVE OUT
n 3.5 Connection-orientedtransport: TCPn segment structuren reliable data transfern flow controln connection management
n 3.6 Principles ofcongestion control
n 3.7 TCP congestioncontrol
Page 5
2/9/2017 CSE 3214 - S.Datta 5
Transport services and protocols
n provide logical communicationbetween app processesrunning on different hosts
n transport protocols run in endsystemsn send side: breaks app
messages into segments,passes to network layer
n rcv side: reassemblessegments into messages,passes to app layer
n more than one transportprotocol available to appsn Internet: TCP and UDP
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysicallogical end-end
transport
Page 6
2/9/2017 CSE 3214 - S.Datta 6
Transport vs. network layer
n network layer: logicalcommunication between hosts
n transport layer: logicalcommunication betweenprocessesn relies on, enhances, network
layer services
Household analogy:12 kids sending letters to 12
kidsn processes = kidsn app messages = letters in
envelopesn hosts = housesn transport protocol = Ann and
Billn network-layer protocol =
postal service
Page 7
2/9/2017 CSE 3214 - S.Datta 7
Internet transport-layer protocols
n reliable, in-order delivery(TCP)n congestion controln flow controln connection setup
n unreliable, unordered delivery:UDPn no-frills extension of “best-
effort” IPn services not available:
n delay guaranteesn bandwidth guarantees
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysicallogical end-end
transport
Page 8
2/9/2017 CSE 3214 - S.Datta 8
Chapter 3 outline
n 3.1 Transport-layerservices
n 3.2 Multiplexing anddemultiplexing
n 3.3 Connectionlesstransport: UDP
n 3.4 Principles of reliabledata transfer
n 3.5 Connection-orientedtransport: TCPn segment structuren reliable data transfern flow controln connection management
n 3.6 Principles ofcongestion control
n 3.7 TCP congestioncontrol
Page 9
2/9/2017 CSE 3214 - S.Datta 9
Multiplexing/demultiplexing
application
transport
network
link
physical
P1 application
transport
network
link
physical
application
transport
network
link
physical
P2P3 P4P1
host 1 host 2 host 3
= process= socket
delivering received segmentsto correct socket
Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data withheader (later used fordemultiplexing)
Multiplexing at send host:
Page 10
2/9/2017 CSE 3214 - S.Datta 10
How demultiplexing works
n host receives IP datagramsn each datagram has source IP
address, destination IPaddress
n each datagram carries 1transport-layer segment
n each segment has source,destination port number(recall: well-known portnumbers for specificapplications)
n host uses IP addresses & portnumbers to direct segment toappropriate socket
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
Page 11
2/9/2017 CSE 3214 - S.Datta 11
Connectionless demultiplexing
n Create sockets with port numbers:DatagramSocket mySocket1 = new
DatagramSocket(99111);DatagramSocket mySocket2 = new
DatagramSocket(99222);n UDP socket identified by two-tuple:(dest IP address, dest port number)
n When host receives UDPsegment:n checks destination port
number in segmentn directs UDP segment to
socket with that port numbern IP datagrams with
different source IPaddresses and/or sourceport numbers directed tosame socket
Page 12
2/9/2017 CSE 3214 - S.Datta 12
Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
ClientIP:B
P2
client IP: A
P1P1P3
serverIP: C
SP:6428DP:9157
SP:9157DP:6428
SP:6428DP:5775
SP:5775DP:6428
SP provides “return address”
Page 13
2/9/2017 CSE 3214 - S.Datta 13
Connection-oriented demux
n TCP socket identified by4-tuple:n source IP addressn source port numbern dest IP addressn dest port number
n recv host uses all four valuesto direct segment toappropriate socket
n Server host may support manysimultaneous TCP sockets:n each socket identified by its
own 4-tuplen Web servers have different
sockets for each connectingclientn non-persistent HTTP will have
different socket for eachrequest
Page 14
2/9/2017 CSE 3214 - S.Datta 14
Connection-oriented demux (cont)
ClientIP:B
P1
client IP: A
P1P2P4
serverIP: C
SP: 9157DP: 80
SP:9157
DP: 80
P5
P6 P3
D-IP:CS-IP: AD-IP:C
S-IP: B
SP:5775
DP: 80
D-IP:CS-IP: B
Page 15
2/9/2017 CSE 3214 - S.Datta 15
Connection-oriented demux: Threaded Web Server
ClientIP:B
P1
client IP: A
P1P2
serverIP: C
SP: 9157DP: 80
SP:9157
DP: 80
P4 P3
D-IP:CS-IP: AD-IP:C
S-IP: B
SP:5775
DP: 80
D-IP:CS-IP: B
Page 16
2/9/2017 CSE 3214 - S.Datta 16
Chapter 3 outline
n 3.1 Transport-layerservices
n 3.2 Multiplexing anddemultiplexing
n 3.3 Connectionlesstransport: UDP
n 3.4 Principles of reliabledata transfer
n 3.5 Connection-orientedtransport: TCPn segment structuren reliable data transfern flow controln connection management
n 3.6 Principles ofcongestion control
n 3.7 TCP congestioncontrol
Page 17
2/9/2017 CSE 3214 - S.Datta 17
UDP: User Datagram Protocol [RFC 768]
n “no frills,” “bare bones”Internet transport protocol
n “best effort” service, UDPsegments may be:n lostn delivered out of order to
appn connectionless:
n no handshaking betweenUDP sender, receiver
n each UDP segmenthandled independently ofothers
Why is there a UDP?n no connection establishment
(which can add delay)n simple: no connection state
at sender, receivern small segment headern no congestion control: UDP
can blast away as fast asdesired
Page 18
2/9/2017 CSE 3214 - S.Datta 18
UDP: more
n often used for streamingmultimedia appsn loss tolerantn rate sensitive
n other UDP usesn DNSn SNMP
n reliable transfer over UDP:add reliability at applicationlayern application-specific error
recovery!
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDPsegment,including
header
Page 19
2/9/2017 CSE 3214 - S.Datta 19
UDP checksum
Sender:n treat segment contents
as sequence of 16-bitintegers
n checksum: addition (1’scomplement sum) ofsegment contents
n sender puts checksumvalue into UDPchecksum field
Receiver:n compute checksum of received
segmentn check if computed checksum
equals checksum field value:n NO - error detectedn YES - no error detected.
But maybe errorsnonetheless?
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
Page 20
2/9/2017 CSE 3214 - S.Datta 20
Internet Checksum Example
n Noten When adding numbers, a carryout from the most significant
bit needs to be added to the resultn Example: add two 16-bit integers
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 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 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
wraparound
sumchecksum
Page 21
2/9/2017 CSE 3214 - S.Datta 21
Chapter 3 outline
n 3.1 Transport-layerservices
n 3.2 Multiplexing anddemultiplexing
n 3.3 Connectionlesstransport: UDP
n 3.4 Principles of reliabledata transfer
n 3.5 Connection-orientedtransport: TCPn segment structuren reliable data transfern flow controln connection management
n 3.6 Principles ofcongestion control
n 3.7 TCP congestioncontrol
Page 22
2/9/2017 CSE 3214 - S.Datta 22
TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581
n full duplex data:n bi-directional data flow in
same connectionn MSS: maximum segment
sizen connection-oriented:
n handshaking (exchange ofcontrol msgs) init’s sender,receiver state before dataexchange
n flow controlled:n sender will not overwhelm
receiver
n point-to-point:n one sender, one receiver
n reliable, in-order byte steam:n no “message boundaries”
n pipelined:n TCP congestion and flow
control set window sizen send & receive buffers
Page 23
2/9/2017 CSE 3214 - S.Datta 23
TCP segment structure
source port # dest port #
32bits
applicationdata
(variable length)
sequence numberacknowledgement number
Receive windowUrg data pnterchecksum
FSRPAUheadlen
notused
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)
# bytesrcvr willingto accept
countingby bytesof data(not segments!)
Internetchecksum
(as in UDP)
Page 24
2/9/2017 CSE 3214 - S.Datta 24
TCP seq. #’s and ACKs
Seq. #’s:n byte stream “number”
of first byte insegment’s data
ACKs:n seq # of next byte
expected from otherside
n cumulative ACKQ: how receiver handles out-
of-order segmentsn A: TCP spec doesn’t
say, - up toimplementor
Host A Host B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usertypes
‘C’
host ACKsreceipt
of echoed‘C’
host ACKsreceipt of‘C’, echoes
back ‘C’
timesimple telnet scenario
Page 25
2/9/2017 CSE 3214 - S.Datta 25
TCP Round Trip Time and Timeout
Q: how to set TCP timeoutvalue?
n longer than RTTn but RTT varies
n too short: prematuretimeoutn unnecessary
retransmissionsn too long: slow reaction to
segment loss
Q: how to estimate RTT?n SampleRTT: measured time from
segment transmission until ACKreceiptn ignore retransmissions
n SampleRTT will vary, want estimatedRTT “smoother”n average several recent
measurements, not just currentSampleRTT
Page 26
2/9/2017 CSE 3214 - S.Datta 26
TCP Round Trip Time and Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
n Exponential weighted moving averagen influence of past sample decreases exponentially fastn typical value: = 0.125
Page 27
2/9/2017 CSE 3214 - S.Datta 27
Example RTT estimation:
Page 28
2/9/2017 CSE 3214 - S.Datta 28
TCP Round Trip Time and Timeout
Setting the timeoutn EstimtedRTT plus “safety margin”
n large variation in EstimatedRTT -> larger safety marginn first estimate of how much SampleRTT deviates from EstimatedRTT:
TimeoutInterval = EstimatedRTT + 4*DevRTT
DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|(typically, = 0.25)
Then set timeout interval:
Page 29
2/9/2017 CSE 3214 - S.Datta 29
Chapter 3 outline
n 3.1 Transport-layer servicesn 3.2 Multiplexing and
demultiplexingn 3.3 Connectionless transport:
UDPn 3.4 Principles of reliable data
transfer
n 3.5 Connection-orientedtransport: TCPn segment structuren reliable data transfern flow controln connection management
n 3.6 Principles of congestioncontrol
n 3.7 TCP congestion control
Page 30
2/9/2017 CSE 3214 - S.Datta 30
TCP reliable data transfer
n TCP creates rdt service on topof IP’s unreliable service
n Pipelined segmentsn Cumulative acksn TCP uses single retransmission
timer
n Retransmissions are triggeredby:n timeout eventsn duplicate acks
n Initially consider simplified TCPsender:n ignore duplicate acksn ignore flow control, congestion
control
Page 31
2/9/2017 CSE 3214 - S.Datta 31
TCP sender events:
data rcvd from app:n Create segment with seq #n seq # is byte-stream number
of first data byte in segmentn start timer if not already
running (think of timer as foroldest unacked segment)
n expiration interval:TimeOutInterval
timeout:n retransmit segment that
caused timeoutn restart timer Ack rcvd:n If acknowledges previously
unacked segmentsn update what is known to be
ackedn start timer if there are
outstanding segments
Page 32
2/9/2017 CSE 3214 - S.Datta 32
TCPsender
(simplified)
NextSeqNum = InitialSeqNum SendBase = InitialSeqNum
loop (forever) { switch(event)
event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data)
event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer
event: ACK received, with ACK field value of y if (y >= SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer }
} /* end of loop forever */
Comment:• SendBase-1: lastcumulativelyack’ed byteExample:• SendBase-1 = 71;y= 73, so the rcvrwants 73+ ;y > SendBase, sothat new data isacked
Page 33
2/9/2017 CSE 3214 - S.Datta 33
TCP: retransmission scenarios
Host A
Seq=100, 20 bytes data
ACK=100
timepremature timeout
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=
92ti
meo
ut
ACK=120
HostA
Seq=92, 8 bytesdata
ACK=100
loss
tim
e-ou
t
lost ACK scenario
HostB
X
Seq=92, 8 bytesdata
ACK=100
time
Seq=
92 t
imeo
utSendBase
= 100
SendBase= 120
SendBase= 120
Sendbase= 100
Page 34
2/9/2017 CSE 3214 - S.Datta 34
TCP retransmission scenarios (more)
HostA
Seq=92, 8 bytesdata
ACK=100
loss
tim
e-ou
t
Cumulative ACK scenario
HostB
XSeq=100, 20 bytesdata
ACK=120
time
SendBase= 120
Page 35
2/9/2017 CSE 3214 - S.Datta 35
TCP ACK generation [RFC 1122, RFC 2581]
Event at Receiver
Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed
Arrival of in-order segment withexpected seq #. One othersegment has ACK pending
Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected
Arrival of segment thatpartially or completely fills gap
TCP Receiver action
Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK
Immediately send single cumulativeACK, ACKing both in-order segments
Immediately send duplicate ACK,indicating seq. # of next expected byte
Immediate send ACK, provided thatsegment starts at lower end of gap
Page 36
2/9/2017 CSE 3214 - S.Datta 36
Fast Retransmit
n Time-out period often relativelylong:n long delay before resending
lost packetn Detect lost segments via
duplicate ACKs.n Sender often sends many
segments back-to-backn If segment is lost, there will
likely be many duplicate ACKs.
n If sender receives 3 ACKs forthe same data, it supposesthat segment after ACKeddata was lost:n fast retransmit: resend
segment before timer expires
Page 37
2/9/2017 CSE 3214 - S.Datta 37
event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y }
Fast retransmit algorithm:
a duplicate ACK foralready ACKed segment
fast retransmit
Page 38
2/9/2017 CSE 3214 - S.Datta 38
Chapter 3 outline
n 3.1 Transport-layer servicesn 3.2 Multiplexing and
demultiplexingn 3.3 Connectionless transport:
UDPn 3.4 Principles of reliable data
transfer
n 3.5 Connection-orientedtransport: TCPn segment structuren reliable data transfern flow controln connection management
n 3.6 Principles of congestioncontrol
n 3.7 TCP congestion control
Page 39
2/9/2017 CSE 3214 - S.Datta 39
TCP Flow Control
n receive side of TCP connectionhas a receive buffer:
n speed-matching service:matching the send rate tothe receiving app’s drain rate
n app process may be slow atreading from buffer
sender won’t overflowreceiver’s buffer by
transmitting toomuch,
too fast
flow control
Page 40
2/9/2017 CSE 3214 - S.Datta 40
TCP Flow control: how it works
(Suppose TCP receiver discards out-of-order segments)
n spare room in buffer= RcvWindow= RcvBuffer-[LastByteRcvd -
LastByteRead]
n Rcvr advertises spare roomby including value ofRcvWindow in segments
n Sender limits unACKed datato RcvWindown guarantees receive buffer
doesn’t overflow
Page 41
2/9/2017 CSE 3214 - S.Datta 41
Chapter 3 outline
n 3.1 Transport-layer servicesn 3.2 Multiplexing and
demultiplexingn 3.3 Connectionless transport:
UDPn 3.4 Principles of reliable data
transfer
n 3.5 Connection-orientedtransport: TCPn segment structuren reliable data transfern flow controln connection management
n 3.6 Principles of congestioncontrol
n 3.7 TCP congestion control
Page 42
2/9/2017 CSE 3214 - S.Datta 42
TCP Connection Management
Recall: TCP sender, receiverestablish “connection” beforeexchanging data segments
n initialize TCP variables:n seq. #sn buffers, flow control info
(e.g. RcvWindow)n client: connection initiator Socket clientSocket = new
Socket("hostname","portnumber");
n server: contacted by client Socket connectionSocket =
welcomeSocket.accept();
Three way handshake:Step 1: client host sends TCP
SYN segment to servern specifies initial seq #n no data
Step 2: server host receives SYN,replies with SYNACK segmentn server allocates buffersn specifies server initial seq. #
Step 3: client receives SYNACK,replies with ACK segment,which may contain data
Page 43
2/9/2017 CSE 3214 - S.Datta 43
TCP Connection Management (cont.)
Closing a connection:
client closes socket:clientSocket.close();
Step 1: client end system sendsTCP FIN control segment toserver
Step 2: server receives FIN,replies with ACK. Closesconnection, sends FIN.
client
FIN
server
ACK
ACK
FIN
close
close
closed
tim
ed w
ait
Page 44
2/9/2017 CSE 3214 - S.Datta 44
TCP Connection Management (cont.)
Step 3: client receives FIN,replies with ACK.
n Enters “timed wait” - willrespond with ACK toreceived FINs
Step 4: server, receives ACK.Connection closed.
Note: with small modification,can handle simultaneous FINs.
client
FIN
server
ACK
ACK
FIN
closing
closing
closed
tim
ed w
ait
closed
Page 45
2/9/2017 CSE 3214 - S.Datta 45
TCP Connection Management (cont)
TCP clientlifecycle
TCP serverlifecycle