Post on 04-Jun-2018
8/13/2019 NetWork Service - Chapter_3_V6.0
1/110
Transport Layer 3-1
Chapter 3Transport Layer
ComputerNetworking: A
Top Down Approach
6 th editionJim Kurose, Keith Ross
Addison-WesleyMarch 2012
A note on the use of these ppt slides:We
re making these slides freely available to all (faculty, students, readers).They
re in PowerPoint form so you see the animations; and can add, modify,and delete slides (including this one) and slide content to suit your needs.They obviously represent a lot of work on our part. In return for use, we onlyask the following:
If you use these slides (e.g., in a class) that you mention their source
(after all, we
d like people to use our book!)If you post any slides on a www site, that you note that they are adaptedfrom (or perhaps identical to) our slides, and note our copyright of thismaterial.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2012J.F Kurose and K.W. Ross, All Rights Reserved
8/13/2019 NetWork Service - Chapter_3_V6.0
2/110
Transport Layer 3-2
Chapter 3: Transport Layer
our goals:understandprinciples behindtransport layerservices:
multiplexing,demultiplexingreliable data
transferflow controlcongestion control
learn about Internettransport layerprotocols:
UDP: connectionlesstransportTCP: connection-oriented reliabletransportTCP congestion control
8/13/2019 NetWork Service - Chapter_3_V6.0
3/110
Transport Layer 3-3
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable datatransfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transferflow controlconnectionmanagement
3.6 principles ofcongestion control
3.7 TCP congestioncontrol
8/13/2019 NetWork Service - Chapter_3_V6.0
4/110
Transport Layer 3-4
Transport services and protocolsprovide logicalcommunication betweenapp processes running ondifferent hoststransport protocols run inend systems
send side: breaks appmessages intosegments , passes tonetwork layerrcv side: reassemblessegments intomessages, passes toapp layer
more than one transportprotocol available to apps
applicationtransport networkdata linkphysical
application
transport networkdata linkphysical
8/13/2019 NetWork Service - Chapter_3_V6.0
5/110
Transport Layer 3-5
Transport vs. network layer
network layer: logicalcommunicationbetween hoststransport layer: logicalcommunicationbetweenprocesses
relies on,enhances,network layerservices
12 kids in Ann s housesending letters to 12 kidsin Bills house: hosts = housesprocesses = kidsapp messages = lettersin envelopestransport protocol = Ann
and Bill who demux to in-house siblingsnetwork-layer protocol =postal service
household analogy:
8/13/2019 NetWork Service - Chapter_3_V6.0
6/110
Transport Layer 3-6
Internet transport-layer protocols
reliable, in-orderdelivery (TCP)
congestion controlflow control
connection setupunreliable, unordereddelivery: UDP
no-frills extension of
best-effort
IPservices notavailable:
delay guaranteesbandwidth guarantees
application
transport networkdata linkphysical
applicationtransport
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
8/13/2019 NetWork Service - Chapter_3_V6.0
7/110Transport Layer 3-7
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable datatransfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transferflow controlconnectionmanagement
3.6 principles ofcongestion control
3.7 TCP congestioncontrol
8/13/2019 NetWork Service - Chapter_3_V6.0
8/110Transport Layer 3-8
Multiplexing/demultiplexing
process
socket
use header info to deliverreceived segments to correctsocket
demultiplexing at receiver:handle data from multiplesockets, add transportheader (later used fordemultiplexing)
multiplexing at sender:
transport
application
physicallink
network
P2P1
transport
application
physical
linknetwork
P4
transport
application
physical
linknetwork
P3
8/13/2019 NetWork Service - Chapter_3_V6.0
9/110Transport Layer 3-9
How demultiplexing works
host receives IPdatagrams
each datagram hassource IP address,destination IP addresseach datagram carriesone transport-layersegmenteach segment hassource, destination portnumber
host uses IP addresses& port numbers to direct
segment to appropriatesocket
source port # dest port #
32 bits
applicationdata
(payload)
other header fields
TCP/UDP segment format
8/13/2019 NetWork Service - Chapter_3_V6.0
10/110Transport Layer 3-10
Connectionless demultiplexing
recall: created socket hashost-local port #:DatagramSocket mySocket1= new DatagramSocket( 12534 );
when host receivesUDP segment:
checks destination port# in segmentdirects UDP segment tosocket with that port #
recall: when creatingdatagram to send intoUDP socket, mustspecify
destination IP addressdestination port #
IP datagrams withsame dest. port #, but
different source IPaddresses and/orsource port numberswill be directed to samesocket at dest
8/13/2019 NetWork Service - Chapter_3_V6.0
11/110
Transport Layer 3-11
Connectionless demux:example
DatagramSocketserverSocket = newDatagramSocket( 6428 );
transport
application
physical
link
network
P3transport
application
physical
link
network
P1
transport
application
physical
link
network
P4
DatagramSocket mySocket1 = new
DatagramSocket( 5775 );
DatagramSocket mySocket2 = new
DatagramSocket( 9157 );
source port: 9157dest port: 6428
source port: 6428dest port: 9157
source port: ?dest port: ?
source port: ?dest port: ?
8/13/2019 NetWork Service - Chapter_3_V6.0
12/110
Transport Layer 3-12
Connection-oriented demux
TCP socket identifiedby 4-tuple:
source IP addresssource port numberdest IP addressdest port number
demux: receiver usesall four values todirect segment toappropriate socket
server host maysupport manysimultaneous TCPsockets:
each socket identifiedby its own 4-tuple
web servers havedifferent sockets for
each connecting clientnon-persistent HTTPwill have differentsocket for each request
8/13/2019 NetWork Service - Chapter_3_V6.0
13/110
Transport Layer 3-13
Connection-oriented demux:example
transport
application
physical
linknetwork
P3transport
application
physicallink
P4
transport
application
physicallink
network
P2
source IP,port: A,9157dest IP, port: B,80
source IP,port: B,80dest IP,port: A,9157host: IPaddress A
host: IPaddressC
network
P6P5P3
source IP,port: C,5775dest IP,port: B,80
source IP,port: C,9157dest IP,port: B,80
three segments, all destined to IP address: B,dest port: 80 are demultiplexed to different sockets
server:IP
addressB
8/13/2019 NetWork Service - Chapter_3_V6.0
14/110
Transport Layer 3-14
Connection-oriented demux:example
transport
application
physical
linknetwork
P3transport
application
physicallink
transport
application
physicallink
network
P2
source IP,port: A,9157dest IP, port: B,80
source IP,port: B,80dest IP,port: A,9157host: IPaddress A
host: IPaddressC
server:IP
addressB
network
P3
source IP,port: C,5775dest IP,port: B,80
source IP,port: C,9157dest IP,port: B,80
P4
threaded server
8/13/2019 NetWork Service - Chapter_3_V6.0
15/110
Transport Layer 3-15
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable datatransfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transferflow controlconnectionmanagement
3.6 principles ofcongestion control
3.7 TCP congestioncontrol
8/13/2019 NetWork Service - Chapter_3_V6.0
16/110
Transport Layer 3-16
UDP: User Datagram Protocol [RFC768]
no frills,
bare bones
Internet transportprotocol
best effort
service,UDP segments may be:
lostdelivered out-of-orderto app
connectionless: no handshakingbetween UDPsender, receivereach UDP segmenthandled
independently ofothers
UDP use:streaming multimediaapps (loss tolerant,rate sensitive)DNSSNMP
reliable transfer overUDP:
add reliability at
application layerapplication-specificerror recovery!
8/13/2019 NetWork Service - Chapter_3_V6.0
17/110
Transport Layer 3-17
UDP: segment header
source port # dest port #
32 bits
applicationdata
(payload)
UDP segment format
length checksum
length, in bytes ofUDP segment,including header
no connectionestablishment (whichcan add delay)simple: no connectionstate at sender, receiversmall header sizeno congestion control:UDP can blast away asfast as desired
why is there a UDP?
8/13/2019 NetWork Service - Chapter_3_V6.0
18/110
Transport Layer 3-18
UDP checksum
sender:treat segmentcontents, includingheader fields, assequence of 16-bitintegerschecksum: addition(one s complementsum) of segmentcontentssender puts checksumvalue into UDPchecksum field
receiver:
compute checksum ofreceived segmentcheck if computedchecksum equalschecksum field value:
NO - error detectedYES - no errordetected. But maybeerrors nonetheless? More later .
Goal: detect errors (e.g., flipped bits) intransmitted segment
8/13/2019 NetWork Service - Chapter_3_V6.0
19/110
Transport Layer 3-19
Internet checksum: example
example: add two 16-bit integers1 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
Note: when adding numbers, a carryout from the mostsignificant bit needs to be added to the result
8/13/2019 NetWork Service - Chapter_3_V6.0
20/110
Transport Layer 3-20
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable datatransfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transferflow controlconnectionmanagement
3.6 principles ofcongestion control
3.7 TCP congestioncontrol
8/13/2019 NetWork Service - Chapter_3_V6.0
21/110
Transport Layer 3-21
Principles of reliable datatransfer
important in application, transport, link layerstop-10 list of important networking topics!
characteristics of unreliable channel will determinecomplexity of reliable data transfer protocol (rdt)
8/13/2019 NetWork Service - Chapter_3_V6.0
22/110
Transport Layer 3-22
characteristics of unreliable channel will determinecomplexity of reliable data transfer protocol (rdt)
Principles of reliable datatransfer
important in application, transport, link layerstop-10 list of important networking topics!
8/13/2019 NetWork Service - Chapter_3_V6.0
23/110
Transport Layer 3-23
characteristics of unreliable channel will determinecomplexity of reliable data transfer protocol (rdt)
important in application, transport, link layerstop-10 list of important networking topics!
Principles of reliable datatransfer
8/13/2019 NetWork Service - Chapter_3_V6.0
24/110
Transport Layer 3-24
Reliable data transfer: getting started
sendside
receiveside
rdt_send(): called from above,(e.g., by app.). Passed data todeliver 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
8/13/2019 NetWork Service - Chapter_3_V6.0
25/110
Transport Layer 3-25
we
ll:incrementally develop sender, receiver sidesof r eliable data transfer protocol (rdt)consider only unidirectional data transfer
but control info will flow on both directions!use finite state machines (FSM) to specifysender, receiver
state1
state2
event causing state transitionactions taken on state transition
state: when in this state
next stateuniquely determined
by next eventeventactions
Reliable data transfer: getting started
8/13/2019 NetWork Service - Chapter_3_V6.0
26/110
Transport Layer 3-26
rdt1.0: reliable transfer over a reliablechannel
underlying channel perfectly reliableno bit errorsno loss of packets
separate FSMs for sender, receiver:
sender sends data into underlying channelreceiver reads data from underlying channel
Wait forcall from
above packet = make_pkt(data)udt_send(packet)
rdt_send(data)
extract (packet,data)deliver_data(data)
Wait forcall from
below
rdt_rcv(packet)
sender receiver
8/13/2019 NetWork Service - Chapter_3_V6.0
27/110
Transport Layer 3-27
underlying channel may flip bits in packetchecksum to detect bit errorsthe question: how to recover from errors:
acknowledgements (ACKs): receiver explicitly tellssender that pkt received OKnegative acknowledgements (NAKs): receiverexplicitly tells sender that pkt had errorssender retransmits pkt on receipt of NAK
new mechanisms in rdt2.0 (beyond rdt1.0 ):error detectionreceiver feedback: control msgs (ACK,NAK) rcvr->sender
rdt2.0: channel with bit errors
How do humans recover from
errors
during conversation?
8/13/2019 NetWork Service - Chapter_3_V6.0
28/110
Transport Layer 3-28
underlying channel may flip bits in packetchecksum to detect bit errorsthe question: how to recover from errors:
acknowledgements (ACKs): receiver explicitly tells
sender that pkt received OKnegative acknowledgements (NAKs): receiverexplicitly tells sender that pkt had errorssender retransmits pkt on receipt of NAK
new mechanisms in rdt2.0 (beyond rdt1.0 ):error detectionfeedback: control msgs (ACK, NAK) from receiverto sender
rdt2.0: channel with bit errors
8/13/2019 NetWork Service - Chapter_3_V6.0
29/110
Transport Layer 3-29
rdt2.0: FSM specification
Wait forcall from
above
sndpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) &¬corrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) &&corrupt(rcvpkt)
Wait for ACK or
NAK
Wait forcall from
below sender
receiverrdt_send(data)
L
8/13/2019 NetWork Service - Chapter_3_V6.0
30/110
Transport Layer 3-30
rdt2.0: operation with no errors
Wait forcall from
above
sndpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) &¬corrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) &&corrupt(rcvpkt)
Wait for ACK or
NAK
Wait forcall from
below
rdt_send(data)
L
8/13/2019 NetWork Service - Chapter_3_V6.0
31/110
Transport Layer 3-31
rdt2.0: error scenario
Wait forcall from
above
sndpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) &¬corrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) &&corrupt(rcvpkt)
Wait for ACK or
NAK
Wait forcall from
below
rdt_send(data)
L
8/13/2019 NetWork Service - Chapter_3_V6.0
32/110
Transport Layer 3-32
rdt2.0 has a fatal flaw!
what happens if ACK/NAKcorrupted?sender doesn t know
what happened atreceiver!can't just retransmit:possible duplicate
handling duplicates :sender retransmitscurrent pkt if ACK/NAKcorrupted
sender adds sequencenumber to each pktreceiver discards(doesn t deliver up)duplicate pkt
stop and waitsender sends onepacket,then waits for receiverresponse
8/13/2019 NetWork Service - Chapter_3_V6.0
33/110
Transport Layer 3-33
rdt2.1: sender, handles garbled ACK/NAKs
Wait forcall 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
Wait for ACK orNAK 0 udt_send(sndpkt)
rdt_rcv(rcvpkt) &&(corrupt(rcvpkt) ||isNAK(rcvpkt) )
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&( corrupt(rcvpkt) ||isNAK(rcvpkt) )
rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt)
Wait forcall 1 from
above
Wait for ACK or
NAK 1
LL
8/13/2019 NetWork Service - Chapter_3_V6.0
34/110
Transport Layer 3-34
Wait for0 frombelow
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) &¬ corrupt(rcvpkt) &&has_seq0(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)&& has_seq1(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
Wait for1 frombelow
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &¬ corrupt(rcvpkt) &&has_seq1(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
rdt2.1: receiver, handles garbled ACK/NAKs
8/13/2019 NetWork Service - Chapter_3_V6.0
35/110
Transport Layer 3-35
rdt2.1: discussion
sender:seq # added to pkttwo seq. #
s (0,1)will suffice. Why?must check ifreceived ACK/NAKcorrupted
twice as manystatesstate must
remember
whether
expected
pkt
should have seq # of0 or 1
receiver:must check ifreceived packet isduplicate
state indicateswhether 0 or 1 isexpected pkt seq #
note: receiver can
not know if its last ACK/NAK receivedOK at sender
8/13/2019 NetWork Service - Chapter_3_V6.0
36/110
Transport Layer 3-36
rdt2.2: a NAK-free protocol
same functionality as rdt2.1, using ACKs onlyinstead of NAK, receiver sends ACK for last pktreceived OK
receiver must explicitly include seq # of pkt being ACKed
duplicate ACK at sender results in same actionas NAK: retransmit current pkt
8/13/2019 NetWork Service - Chapter_3_V6.0
37/110
Transport Layer 3-37
rdt2.2: sender, receiver fragments
Wait forcall 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt,0)
Wait for ACK
0
sender FSMfragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)&& has_seq1(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)
Wait for0 from
below
rdt_rcv(rcvpkt) &&(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)
receiver FSM
fragment
L
8/13/2019 NetWork Service - Chapter_3_V6.0
38/110
Transport Layer 3-38
rdt3.0: channels with errors and loss
new assumption: underlying channelcan also losepackets (data,
ACKs)checksum, seq. #,
ACKs,retransmissions willbe of help but notenough
approach: sender waits
reasonable
amountof time for ACKretransmits if no ACK
received in this timeif pkt (or ACK) justdelayed (not lost):
retransmission will beduplicate, but seq. #
s
already handles thisreceiver must specifyseq # of pkt being
ACKedrequires countdown timer
8/13/2019 NetWork Service - Chapter_3_V6.0
39/110
Transport Layer 3-39
rdt3.0 sendersndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer
rdt_send(data)
Waitfor
ACK0
rdt_rcv(rcvpkt) &&( corrupt(rcvpkt) ||isACK(rcvpkt,1) )
Wait forcall 1 from
above
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer
rdt_send(data)
rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt,0)
rdt_rcv(rcvpkt) &&( corrupt(rcvpkt) ||isACK(rcvpkt,0) )
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)&& isACK(rcvpkt,1)
stop_timer stop_timer
udt_send(sndpkt)start_timer
timeout
udt_send(sndpkt)
start_timer
timeout
rdt_rcv(rcvpkt)
Wait forcall 0from
above
Waitfor
ACK1
L
rdt_rcv(rcvpkt)
L
L
L
8/13/2019 NetWork Service - Chapter_3_V6.0
40/110
Transport Layer 3-40
sender receiver
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0rcv pkt0
pkt0
pkt0
pkt1
ack1
ack0
ack0
(a) no loss
sender receiver
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0rcv pkt0
pkt0
pkt0
ack1
ack0
ack0
(b) packet loss
pkt1 X
loss
pkt1timeout
resend pkt1
rdt3.0 in action
8/13/2019 NetWork Service - Chapter_3_V6.0
41/110
Transport Layer 3-41
rdt3.0 in action
rcv pkt1send ack1
(detect duplicate)
pkt1
sender receiver
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0rcv pkt0
pkt0
pkt0
ack1
ack0
ack0
(c) ACK loss
ack1 Xloss
pkt1timeout
resend pkt1
rcv pkt1send ack1
(detect duplicate)
pkt1
sender receiver
rcv pkt1
send ack0rcv ack0
send pkt1
send pkt0
rcv pkt0pkt0
ack0
(d) premature timeout/ delayed ACK
pkt1timeout
resend pkt1
ack1
send ack1
send pkt0rcv ack1
pkt0
ack1
ack0
send pkt0rcv ack1 pkt0
rcv pkt0send ack0ack0
rcv pkt0send ack0(detect duplicate)
8/13/2019 NetWork Service - Chapter_3_V6.0
42/110
8/13/2019 NetWork Service - Chapter_3_V6.0
43/110
Transport Layer 3-43
rdt3.0: stop-and-wait operation
first packet bit transmitted, t = 0sender receiver
RTT
last packet bit transmitted, t = L / R
first packet bit arrives last packet bit arrives, send ACK
ACK arrives, send nextpacket, t = RTT + L / R
Usender =
. 008
30.008= 0.00027
L / R
RTT + L / R=
8/13/2019 NetWork Service - Chapter_3_V6.0
44/110
Transport Layer 3-44
Pipelined protocols
pipelining: sender allows multiple,
in-flight
,yet-to-be-acknowledged pktsrange of sequence numbers must be increasedbuffering at sender and/or receiver
two generic forms of pipelined protocols: go-Back-N, selective repeat
8/13/2019 NetWork Service - Chapter_3_V6.0
45/110
Transport Layer 3-45
Pipelining: increased utilization
first packet bit transmitted, t = 0
sender receiver
RTT
last bit transmitted, t = L / R
first packet bit arrives last packet bit arrives, send ACK
ACK arrives, send nextpacket, t = RTT + L / R
last bit of 2nd
packet arrives, send ACK
last bit of 3 rd packet arrives, send ACK
3-packet pipelining increasesutilization by a factor of 3!
Usender =
. 0024
30.008= 0.00081
3L / R
RTT + L / R=
8/13/2019 NetWork Service - Chapter_3_V6.0
46/110
Transport Layer 3-46
Pipelined protocols: overview
Go-back-N:sender can have upto N unacked packetsin pipelinereceiver only sendscumulative ack
doesn't ack packet iftheres a gap
sender has timer for
oldest unackedpacketwhen timer expires,retransmit all unackedpackets
Selective Repeat:sender can have up toN unack
ed packets inpipelinercvr sends individualack for each packet
sender maintains timer
for each unackedpacketwhen timer expires,retransmit only thatunacked packet
8/13/2019 NetWork Service - Chapter_3_V6.0
47/110
Transport Layer 3-47
Go-Back-N: senderk-bit seq # in pkt header
window
of up to N, consecutive unacked pkts allowed
ACK(n): ACKs all pkts up to, including seq # n -
cumulative ACK
may receive duplicate ACKs (see receiver)
timer for oldest in-flight pkttimeout(n): retransmit packet n and all higher seq # pktsin window
8/13/2019 NetWork Service - Chapter_3_V6.0
48/110
Transport Layer 3-48
GBN: sender extended FSM
Wait start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])
udt_send(sndpkt[nextseqnum-1])
timeout
rdt_send(data)
if (nextseqnum < base+N) {sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)udt_send(sndpkt[nextseqnum])if (base == nextseqnum)
start_timernextseqnum++}
else
refuse_data(data)
base = getacknum(rcvpkt)+1If (base == nextseqnum)
stop_timerelse
start_timer
rdt_rcv(rcvpkt) &¬corrupt(rcvpkt)
base=1nextseqnum=1
rdt_rcv(rcvpkt)&& corrupt(rcvpkt)
L
8/13/2019 NetWork Service - Chapter_3_V6.0
49/110
Transport Layer 3-49
ACK-only: always send ACK for correctly-receivedpkt with highest in-order seq #
may generate duplicate ACKsneed only remember expectedseqnum
out-of-order pkt:discard (don t buffer): no receiver buffering!re-ACK pkt with highest in-order seq #
Wait
udt_send(sndpkt)
default
rdt_rcv(rcvpkt)&& notcurrupt(rcvpkt)&& hasseqnum(rcvpkt,expectedseqnum)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)
expectedseqnum++
expectedseqnum=1sndpkt =
make_pkt(expectedseqnum,ACK,chksum)
L
GBN: receiver extended FSM
8/13/2019 NetWork Service - Chapter_3_V6.0
50/110
Transport Layer 3-50
GBN in action
send pkt0send pkt1send pkt2send pkt3
(wait)
sender receiver
receive pkt0, send ack0receive pkt1, send ack1
receive pkt3, discard,(re)send ack1
rcv ack0, send pkt4rcv ack1, send pkt5
pkt 2 timeoutsend pkt2send pkt3send pkt4send pkt5
X loss
receive pkt4, discard,(re)send ack1
receive pkt5, discard,(re)send ack1
rcv pkt2, deliver, send ack2rcv pkt3, deliver, send ack3rcv pkt4, deliver, send ack4rcv pkt5, deliver, send ack5
ignore duplicate ACK
0 1 2 3 4 5 6 7 8
sender window (N=4)
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 80 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 80 1 2 3 4 5 6 7 80 1 2 3 4 5 6 7 80 1 2 3 4 5 6 7 8
8/13/2019 NetWork Service - Chapter_3_V6.0
51/110
Transport Layer 3-51
Selective repeat
receiver individually acknowledges allcorrectly received pktsbuffers pkts, as needed, for eventual in-orderdelivery to upper layer
sender only resends pkts for which ACK notreceivedsender timer for each unACKed pkt
sender window
N consecutive seq # s limits seq #s of sent, unACKed pkts
Selective repeat: sender receiver
8/13/2019 NetWork Service - Chapter_3_V6.0
52/110
Transport Layer 3-52
Selective repeat: sender, receiverwindows
8/13/2019 NetWork Service - Chapter_3_V6.0
53/110
Transport Layer 3-53
Selective repeat
data from above:if next available seq # inwindow, send pkt
timeout(n):resend pkt n, restarttimer
ACK(n) in[sendbase,sendbase+N]:
mark pkt n as receivedif n smallest unACKedpkt, advance windowbase to next unACKedseq #
senderpkt n in [rcvbase, rcvbase+N-1]
send ACK(n)out-of-order: bufferin-order: deliver (alsodeliver buffered, in-order pkts), advancewindow to next not-yet-received pkt
pkt n in [rcvbase-N,rcvbase-1] ACK(n)
otherwise: ignore
receiver
8/13/2019 NetWork Service - Chapter_3_V6.0
54/110
Transport Layer 3-54
Selective repeat in action
send pkt0send pkt1send pkt2send pkt3
(wait)
sender receiver
receive pkt0, send ack0receive pkt1, send ack1
receive pkt3, buffer,
send ack3rcv ack0, send pkt4rcv ack1, send pkt5
pkt 2 timeout
send pkt2
X loss
receive pkt4, buffer,send ack4
receive pkt5, buffer,send ack5
rcv pkt2; deliver pkt2,pkt3, pkt4, pkt5; send ack2
record ack3 arrived
0 1 2 3 4 5 6 7 8
sender window (N=4)
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 80 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 80 1 2 3 4 5 6 7 80 1 2 3 4 5 6 7 80 1 2 3 4 5 6 7 8
record ack4 arrived
record ack5 arrived
Q: what happens when ack2 arrives?
S l ireceiver windowsender window
8/13/2019 NetWork Service - Chapter_3_V6.0
55/110
Transport Layer 3-55
Selective repeat:dilemma
example:seq #
s: 0, 1, 2, 3window size=3
(after receipt)(after receipt)
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
pkt0
pkt1
pkt2
0 1 2 3 0 1 2 pkt0
timeoutretransmit pkt0
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2 X
X X
will accept packetwith seq number 0
(b) oops!
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
pkt0
pkt1
pkt2
0 1 2 3 0 1 2pkt0
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
X
will accept packetwith seq number 0
0 1 2 3 0 1 2 pkt3
(a) no problem
receiver can
t see sender side.receiver behavior identical in both cases!something
s (very) wrong!
receiver sees no
difference in twoscenarios!duplicate dataaccepted as new in(b)
Q: what relationshipbetween seq # sizeand window size toavoid problem in(b)?
8/13/2019 NetWork Service - Chapter_3_V6.0
56/110
Transport Layer 3-56
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable datatransfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transfer
flow controlconnectionmanagement
3.6 principles of
congestion control3.7 TCP congestioncontrol
TCP O i
8/13/2019 NetWork Service - Chapter_3_V6.0
57/110
Transport Layer 3-57
TCP: Overview RFCs: 793,1122,1323, 2018,2581
full duplex data:bi-directional dataflow in sameconnection
MSS: maximumsegment sizeconnection-oriented:
handshaking(exchange of controlmsgs) inits sender,receiver state beforedata exchange
flow controlled:
sender will notoverwhelm receiver
point-to-point:one sender, onereceiver
reliable, in-order byte
steam:no
messageboundaries
pipelined:
TCP congestion andflow control setwindow size
8/13/2019 NetWork Service - Chapter_3_V6.0
58/110
Transport Layer 3-58
TCP segment structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence number
acknowledgement numberreceive window
Urg data pointerchecksum
FSRP AUheadlen
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)
C b C
8/13/2019 NetWork Service - Chapter_3_V6.0
59/110
Transport Layer 3-59
TCP seq. numbers, ACKssequence numbers:
byte stream
number
of first byte insegments data
acknowledgements:
seq # of next byteexpected from othersidecumulative ACK
Q: how receiver handlesout-of-order segments
A: TCP spec doesn tsay, - up toimplementor
source port # dest port #
sequence numberacknowledgement number
checksum
rwndurg pointer
incoming segment to sender
A
sent ACKed
sent, not-yet ACKed(
in-flight
)
usablebut notyet sent
notusable
window sizeN
sender sequence number space
source port # dest port #
sequence numberacknowledgement number
checksum
rwndurg pointer
outgoing segment from sender
TCP b
8/13/2019 NetWork Service - Chapter_3_V6.0
60/110
Transport Layer 3-60
TCP seq. numbers, ACK s
Usertypes
C
host ACKsreceipt
of echoed
C
host ACKsreceipt of
C
, echoesback
C
simple telnet scenario
Host BHost A
Seq=42, ACK=79, data =
C
Seq=79, ACK=43, data =
C
Seq=43, ACK=80
8/13/2019 NetWork Service - Chapter_3_V6.0
61/110
Transport Layer 3-61
TCP round trip time, timeout
Q: how to set TCPtimeout value?longer than RTT
but RTT varies
too short: premature timeout,unnecessaryretransmissionstoo long: slowreaction to segmentloss
Q: how to estimateRTT?SampleRTT : measuredtime from segmenttransmission until ACKreceipt
ignore retransmissionsSampleRTT will vary,want estimated RTT
smoother
average several recent measurements, not justcurrent SampleRTT
8/13/2019 NetWork Service - Chapter_3_V6.0
62/110
Transport Layer 3-62
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
R T T ( m i l l i s e c o n
d s
)
Sampl eRT T Esti mated RTT
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
exponential weighted moving averageinfluence of past sample decreasesexponentially fasttypical value: = 0.125
TCP round trip time, timeout
R T T
( m i l l i s e c o n
d s )
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
sampleRTTEstimatedRTT
time (seconds)
8/13/2019 NetWork Service - Chapter_3_V6.0
63/110
Transport Layer 3-63
timeout interval: EstimatedRTT plus safety
margin
large variation in EstimatedRTT -> larger safety margin
estimate SampleRTT deviation from EstimatedRTT:DevRTT = (1- )*DevRTT +*|SampleRTT-EstimatedRTT|
TCP round trip time, timeout
(typically, = 0.25)
TimeoutInterval = EstimatedRTT + 4*DevRTT
estimated RTT safety margin
8/13/2019 NetWork Service - Chapter_3_V6.0
64/110
Transport Layer 3-64
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable datatransfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transfer
flow controlconnectionmanagement
3.6 principles of
congestion control3.7 TCP congestioncontrol
8/13/2019 NetWork Service - Chapter_3_V6.0
65/110
Transport Layer 3-65
TCP reliable data transfer
TCP creates rdtservice on top of IP sunreliable service
pipelined segments
cumulative ackssingle retransmissiontimer
retransmissionstriggered by:
timeout eventsduplicate acks
let's initially considersimplified TCPsender:
ignore duplicate acksignore flow control,congestion control
TCP d t
8/13/2019 NetWork Service - Chapter_3_V6.0
66/110
Transport Layer 3-66
TCP sender events:data rcvd from app:
create segment withseq #seq # is byte-streamnumber of first databyte in segmentstart timer if notalready running
think of timer as for
oldest unackedsegmentexpiration interval:TimeOutInterval
timeout:retransmit segmentthat caused timeoutrestart timer
ack rcvd:if ack acknowledgespreviously unackedsegments
update what is knownto be ACKedstart timer if there arestill unackedsegments
TCP d
8/13/2019 NetWork Service - Chapter_3_V6.0
67/110
Transport Layer 3-67
TCP sender (simplified)
wait
forevent
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
L
create segment, seq. #: NextSeqNumpass segment to IP (i.e.,
send
)NextSeqNum = NextSeqNum + length(data)if (timer currently not running)
start timer
data received from application above
retransmit not-yet-acked segmentwith smallest seq. #
start timer
timeout
if (y > SendBase) {SendBase = y/* SendBase 1: last cumulatively ACKed byte */if (there are currently not-yet-acked segments)
start timerelse stop timer
}
ACK received, with ACK field value y
8/13/2019 NetWork Service - Chapter_3_V6.0
68/110
Transport Layer 3-68
TCP: retransmission scenarios
lost ACK scenario
Host BHost A
Seq=92, 8 bytes of data
ACK=100
Seq=92, 8 bytes of data
X t i m e o u
t
ACK=100
premature timeout
Host BHost A
Seq=92, 8 bytes of data
ACK=100
Seq=92, 8bytes of data
t i m e o u
t
ACK=120
Seq=100, 20 bytes of data
ACK=120
SendBase=100
SendBase=120
SendBase=120
SendBase=92
8/13/2019 NetWork Service - Chapter_3_V6.0
69/110
Transport Layer 3-69
TCP: retransmission scenarios
X
cumulative ACK
Host BHost A
Seq=92, 8 bytes of data
ACK=100
Seq=120, 15 bytes of data
t i m e o u t
Seq=100, 20 bytes of data
ACK=120
8/13/2019 NetWork Service - Chapter_3_V6.0
70/110
Transport Layer 3-70
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 segment
higher-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 cumulative ACK, 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
TCP f i
8/13/2019 NetWork Service - Chapter_3_V6.0
71/110
if sender receives 3 ACKs for same data
(
triple duplicate ACKs
), resendunacked segment withsmallest seq #
likely that unackedsegment lost, so don twait for timeout
Transport Layer 3-71
TCP fast retransmit
time-out period oftenrelatively long:long delay beforeresending lost packet
detect lost segmentsvia duplicate ACKs.
sender often sendsmany segmentsback-to-back
if segment is lost,there will likely bemany duplicate
ACKs.
TCP fast retransmit
TCP f i
8/13/2019 NetWork Service - Chapter_3_V6.0
72/110
Transport Layer 3-72
X
fast retransmit after sender
receipt of triple duplicate ACK
Host BHost A
Seq=92, 8 bytes of data
ACK=100
t i m e o u
t ACK=100
ACK=100
ACK=100
TCP fast retransmit
Seq=100, 20 bytes of data
Seq=100, 20 bytes of data
8/13/2019 NetWork Service - Chapter_3_V6.0
73/110
Transport Layer 3-73
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable datatransfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transfer
flow controlconnectionmanagement
3.6 principles of
congestion control3.7 TCP congestioncontrol
TCP fl t l
8/13/2019 NetWork Service - Chapter_3_V6.0
74/110
Transport Layer 3-74
TCP flow controlapplication
process
TCP socketreceiver buffers
TCPcode
IPcode
application
OS
receiver protocol stack
application may
remove data fromTCP socket buffers .
slower than TCPreceiver is delivering
(sender is sending)
from sender
receiver controls sender, sosender won t overflowreceivers buffer bytransmitting too much, too fast
flow control
TCP fl t l
8/13/2019 NetWork Service - Chapter_3_V6.0
75/110
Transport Layer 3-75
TCP flow control
buffered data
free buffer spacerwnd
RcvBuffer
TCP segment payloads
to application processreceiver
advertises
freebuffer space by includingrwnd value in TCPheader of receiver-to-sender segments
RcvBuffer size set viasocket options (typicaldefault is 4096 bytes)many operating systemsautoadjust RcvBuffer
sender limits amount ofunacked (
in-flight
) datato receivers rwnd valueguarantees receive bufferwill not overflow
receiver-side buffering
8/13/2019 NetWork Service - Chapter_3_V6.0
76/110
Transport Layer 3-76
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable datatransfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transfer
flow controlconnectionmanagement
3.6 principles of
congestion control3.7 TCP congestioncontrol
C ti M g t
8/13/2019 NetWork Service - Chapter_3_V6.0
77/110
Transport Layer 3-77
Connection Managementbefore exchanging data, sender/receiver
handshake
:agree to establish connection (each knowing the otherwilling to establish connection)agree on connection parameters
connection state: ESTABconnection variables:
seq # client-to-serverserver-to-client
rcvBuffer sizeat server,client
application
network
connection state: ESTABconnection Variables:
seq # client-to-serverserver-to-client
rcvBuffer sizeat server,client
application
network
Socket clientSocket =newSocket("hostname","portnumber");
Socket connectionSocket = welcomeSocket.accept();
Agreeing to establish a connection
8/13/2019 NetWork Service - Chapter_3_V6.0
78/110
Transport Layer 3-78
Q: will 2-wayhandshake alwayswork in network?variable delaysretransmitted messages(e.g. req_conn(x)) due tomessage lossmessage reorderingcan't
see
other side
2-way handshake:
Let
s talk
OK
ESTAB
ESTAB
choose xreq_conn(x)
ESTAB
ESTABacc_conn(x)
Agreeing to establish a connection
Agreeing to establish a connection
8/13/2019 NetWork Service - Chapter_3_V6.0
79/110
Transport Layer 3-79
Agreeing to establish a connection2-way handshake failure scenarios:
retransmit
req_conn(x)
ESTAB
req_conn(x)
half open connection!(no client!)
clientterminates
serverforgets x
connectionx completes
retransmit
req_conn(x)
ESTAB
req_conn(x)
data(x+1)
retransmitdata(x+1)
acceptdata(x+1)
choose xreq_conn(x)
ESTAB
ESTAB
acc_conn(x)
clientterminates
ESTAB
choose xreq_conn(x)
ESTAB
acc_conn(x)
data(x+1) acceptdata(x+1)
connectionx completes server
forgets x
8/13/2019 NetWork Service - Chapter_3_V6.0
80/110
8/13/2019 NetWork Service - Chapter_3_V6.0
81/110
TCP: closing a connection
8/13/2019 NetWork Service - Chapter_3_V6.0
82/110
Transport Layer 3-82
TCP: closing a connectionclient, server each close their side ofconnection
send TCP segment with FIN bit = 1respond to received FIN with ACK
on receiving FIN, ACK can be combined with ownFIN
simultaneous FIN exchanges can be handled
8/13/2019 NetWork Service - Chapter_3_V6.0
83/110
Ch 3 li
8/13/2019 NetWork Service - Chapter_3_V6.0
84/110
Transport Layer 3-84
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable datatransfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transfer
flow controlconnectionmanagement
3.6 principles of
congestion control3.7 TCP congestioncontrol
8/13/2019 NetWork Service - Chapter_3_V6.0
85/110
Transport Layer 3-85
congestion :informally:
too many sources sending toomuch data too fast for network to handle
different from flow control!manifestations:
lost packets (buffer overflow at routers)long delays (queueing in router buffers)
a top-10 problem!
Principles of congestion control
8/13/2019 NetWork Service - Chapter_3_V6.0
86/110
Causes/costs of congestion: scenario
8/13/2019 NetWork Service - Chapter_3_V6.0
87/110
Transport Layer 3-87
one router, finite buffers
sender retransmission of timed-out packetapplication-layer input = application-layer output: l in= l outtransport-layer input includes retransmissions : l inl
in
finite shared outputlink buffers
Host A
l in : original data
Host B
l out l 'in: original data, plus retransmitted data
2
Causes/costs of congestion: scenario
8/13/2019 NetWork Service - Chapter_3_V6.0
88/110
Transport Layer 3-88
idealization: perfectknowledgesender sends onlywhen router buffersavailable
finite shared outputlink buffers
l in : original data l out l 'in: original data, plus retransmitted data
copy
free buffer space!
R/2
R/2
l o u t
l in
2
Host B
Host A
Causes/costs of congestion: scenario
8/13/2019 NetWork Service - Chapter_3_V6.0
89/110
Transport Layer 3-89
l in : original data l out l 'in: original data, plus
retransmitted data copy
no buffer space!
Idealization: known
loss packets can belost, dropped at routerdue to full bufferssender only resends ifpacket known to be
lost
2
Host B
Host A
Causes/costs of congestion: scenario
8/13/2019 NetWork Service - Chapter_3_V6.0
90/110
Transport Layer 3-90
l in : original data l out l 'in: original data, plus retransmitted data
free buffer space!
2 Idealization: known
loss packets can belost, dropped at routerdue to full bufferssender only resends ifpacket known to be
lost
R/2
R/2l in
l o u
twhen sending at R/2,some packets areretransmissions butasymptotic goodputis still R/2 (why?)
A
Host B
Causes/costs of congestion: scenario
8/13/2019 NetWork Service - Chapter_3_V6.0
91/110
Transport Layer 3-91
A
l in l out l 'in copy
free buffer space!
timeout
R/2
R/2l in
l o u
twhen sending at R/2,some packets areretransmissionsincluding duplicatedthat are delivered!
Host B
Realistic: duplicates
packets can be lost,dropped at router due tofull bufferssender times outprematurely, sending two
copies, both of which aredelivered
2
Causes/costs of congestion: scenario
8/13/2019 NetWork Service - Chapter_3_V6.0
92/110
Transport Layer 3-92
R/2
l o u
twhen sending at R/2,some packets areretransmissionsincluding duplicatedthat are delivered!
costs
of congestion: more work (retrans) for given
goodput
unneeded retransmissions: link carries multiple copiesof pktdecreasing goodput
R/2l in
2 Realistic: duplicates
packets can be lost,dropped at router due to fullbufferssender times outprematurely, sending two
copies, both of which aredelivered
Causes/costs of congestion: scenario
3
8/13/2019 NetWork Service - Chapter_3_V6.0
93/110
Transport Layer 3-93
four sendersmultihop pathstimeout/retransmit
Q: what happens as l in andl
in
increase ?
finite shared outputlink buffers
Host A l out
3
Host B
Host CHost D
l in : original data l 'in: original data, plus
retransmitted data
A: as red l in
increases, allarriving blue pkts at upperqueue are dropped, bluethroughput g 0
Causes/costs of congestion: scenario3
8/13/2019 NetWork Service - Chapter_3_V6.0
94/110
Transport Layer 3-94
another
cost
of congestion:
when packet dropped, any
upstreamtransmission capacity used for that packetwas wasted!
3 C/2
C/2
l o u
t
l in
Approaches towards congestion
8/13/2019 NetWork Service - Chapter_3_V6.0
95/110
Transport Layer 3-95
control
two broad approaches towards congestion control:
end-endcongestion
control:no explicit feedbackfrom networkcongestion inferredfrom end-systemobserved loss,delayapproach taken byTCP
network-assistedcongestion control:routers providefeedback to endsystems
single bit indicatingcongestion (SNA,DECbit, TCP/IPECN, ATM)explicit rate forsender to send at
Case study: ATM ABR congestion
8/13/2019 NetWork Service - Chapter_3_V6.0
96/110
Transport Layer 3-96
control
ABR: available bitrate:
elastic service
if sender s path
underloaded
:sender should useavailable bandwidth
if sender s pathcongested:
sender throttled tominimumguaranteed rate
RM (resourcemanagement) cells:sent by sender,interspersed with data cells
bits in RM cell set byswitches (
network-assisted
)NI bit: no increase inrate (mild congestion)
CI bit: congestionindicationRM cells returned tosender by receiver, withbits intact
Case study: ATM ABR congestionl
8/13/2019 NetWork Service - Chapter_3_V6.0
97/110
Transport Layer 3-97
control
two-byte ER (explicit rate) field in RM cellcongested switch may lower ER value in cell
senders
send rate thus max supportable rate onpathEFCI bit in data cells: set to 1 in congestedswitch
if data cell preceding RM cell has EFCI set, receiversets CI bit in returned RM cell
RM cell data cell
Chapter 3 outline
8/13/2019 NetWork Service - Chapter_3_V6.0
98/110
Transport Layer 3-98
Chapter 3 outline
3.1 transport-layerservices
3.2 multiplexing anddemultiplexing
3.3 connectionlesstransport: UDP
3.4 principles ofreliable data
transfer
3.5 connection-orientedtransport: TCP
segment structurereliable data transfer
flow controlconnectionmanagement
3.6 principles of
congestion control3.7 TCP congestioncontrol
8/13/2019 NetWork Service - Chapter_3_V6.0
99/110
TCP Congestion Control:d l
8/13/2019 NetWork Service - Chapter_3_V6.0
100/110
Transport Layer 3-100
details
sender limitstransmission:
cwnd is dynamic,function of perceivednetwork congestion
TCP sending rate:roughly: send cwndbytes, wait RTT for
ACKS, then send
more bytes
last byte ACKed sent, not-
yet ACKed(
in-flight
)
last bytesent
cwnd
LastByteSent-LastByteAcked
< cwnd
sender sequence number space
rate ~~cwndRTT
bytes/sec
TCP Slow Start
8/13/2019 NetWork Service - Chapter_3_V6.0
101/110
Transport Layer 3-101
TCP Slow Startwhen connectionbegins, increase rateexponentially until firstloss event:
initially cwnd = 1 MSSdouble cwnd every RTTdone by incrementingcwnd for every ACKreceived
summary: initial rate isslow but ramps upexponentially fast
Host A
R T T
Host B
time
TCP: detecting, reacting to
8/13/2019 NetWork Service - Chapter_3_V6.0
102/110
Transport Layer 3-102
lossloss indicated by timeout:
cwnd set to 1 MSS;window then grows exponentially (as in slowstart) to threshold, then grows linearly
loss indicated by 3 duplicate ACKs: TCPRENO
dup ACKs indicate network capable ofdelivering some segmentscwnd is cut in half window then grows linearly
TCP Tahoe always sets cwnd to 1 (timeoutor 3 duplicate acks)
TCP: switching from slow start to
8/13/2019 NetWork Service - Chapter_3_V6.0
103/110
Transport Layer 3-103
Q: when should the
exponentialincrease switchto linear?
A: when cwnd getsto 1/2 of its
value beforetimeout.
Implementation: variable ssthresh
on loss event,ssthresh is set to 1/2of cwnd just beforeloss event
CA
Summary: TCP CongestionC t l
8/13/2019 NetWork Service - Chapter_3_V6.0
104/110
Transport Layer 3-104
Control
timeoutssthresh = cwnd/2
cwnd = 1 MSSdupACKcount = 0
retransmit missing segment
Lcwnd > ssthresh
congestionavoidance
cwnd = cwnd + MSS (MSS/cwnd)dupACKcount = 0
transmit new segment(s), as allowed
new ACK.
dupACKcount++duplicate ACK
fastrecovery
cwnd = cwnd + MSStransmit new segment(s), as allowed
duplicate ACK
ssthresh= cwnd/2cwnd = ssthresh + 3
retransmit missing segment
dupACKcount == 3
timeoutssthresh = cwnd/2cwnd = 1dupACKcount = 0retransmit missing segment
ssthresh= cwnd/2cwnd = ssthresh + 3retransmit missing segment
dupACKcount == 3cwnd = ssthreshdupACKcount = 0
New ACK
slowstart
timeoutssthresh = cwnd/2
cwnd = 1 MSSdupACKcount = 0
retransmit missing segment
cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s), as allowed
new ACKdupACKcount++
duplicate ACK
L
cwnd = 1 MSSssthresh = 64 KBdupACKcount = 0
NewACK!
NewACK!
NewACK!
TCP throughput
8/13/2019 NetWork Service - Chapter_3_V6.0
105/110
Transport Layer 3-105
TCP throughputavg. TCP thruput as function of window size,RTT?
ignore slow start, assume always data to sendW: window size (measured in bytes) where loss occurs
avg. window size (# in-flight bytes) is Wavg. thruput is 3/4W per RTT
W
W/2
avg TCP thruput = 34W
RTT bytes/sec
TCP Futures: TCP over
long, fat
8/13/2019 NetWork Service - Chapter_3_V6.0
106/110
Transport Layer 3-106
pipes
example: 1500 byte segments, 100ms RTT,want 10 Gbps throughputrequires W = 83,333 in-flight segmentsthroughput in terms of segment lossprobability, L [Mathis 1997]:
to achieve 10 Gbps throughput, need a loss rateof L = 2 10 -10 a very small loss rate!new versions of TCP for high-speed
TCP throughput = 1.22. MSS
RTT L
TCP Fairness
8/13/2019 NetWork Service - Chapter_3_V6.0
107/110
Transport Layer 3-107
fairness goal: if K TCP sessions share samebottleneck link of bandwidth R, each shouldhave average rate of R/K
TCP connection 1
bottleneck
routercapacity R
TCP Fairness
TCP connection 2
Why is TCP fair?
8/13/2019 NetWork Service - Chapter_3_V6.0
108/110
Transport Layer 3-108
Why is TCP fair?two competing sessions:
additive increase gives slope of 1, as throughoutincreasesmultiplicative decrease decreases throughputproportionallyR
R
equal bandwidth share
Connection 1 throughput
congestion avoidance: additive increaseloss: decrease window by factor of 2
congestion avoidance: additive increaseloss: decrease window by factor of 2
Fairness (more)
8/13/2019 NetWork Service - Chapter_3_V6.0
109/110
Transport Layer 3-109
( )Fairness and UDP
multimedia appsoften do not useTCP
do not want rate
throttled bycongestion controlinstead use UDP:
send audio/video atconstant rate,tolerate packet loss
Fairness, parallel TCPconnectionsapplication can openmultiple parallelconnections between twohostsweb browsers do thise.g., link of rate R with 9existing connections:
new app asks for 1 TCP, getsrate R/10new app asks for 11 TCPs, getsR/2
Chapter 3: summary
8/13/2019 NetWork Service - Chapter_3_V6.0
110/110
p : yprinciples behindtransport layer services:
multiplexing,demultiplexingreliable data transferflow controlcongestion control
instantiation,
implementation in theInternetUDP
next:leaving thenetwork
edge
(application,transport layers)into the network
core