network service - chapter_3_v6.0

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


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


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


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


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:


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









7/110Transport Layer 3-7

Chapter 3 outline











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



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



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


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: ?


12/110


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


13/110


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


three segments, all destined to IP address: B,dest port: 80 are demultiplexed to different sockets

server:IP

addressB


14/110


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



P4

threaded server


15/110


Chapter 3 outline










16/110


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!


17/110


UDP: segment header


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?


18/110


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


19/110


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


20/110


Chapter 3 outline










21/110


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)


22/110






23/110






24/110


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


25/110


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


26/110


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


27/110


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?


28/110


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


29/110


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) &&notcorrupt(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


30/110


rdt2.0: operation with no errors

Wait forcall from

above





udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK

Wait forcall from

below

rdt_send(data)

L


31/110


rdt2.0: error scenario

Wait forcall from

above





udt_send(sndpkt)


udt_send(NAK)


Wait for ACK or

NAK

Wait forcall from

below

rdt_send(data)

L


32/110


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


33/110


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) )


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


34/110


Wait for0 frombelow

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) &&not 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) &&not 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


35/110


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


36/110


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


37/110


rdt2.2: sender, receiver fragments

Wait forcall 0 from

above


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


38/110


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


39/110


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


40/110


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


41/110


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)


42/110


43/110


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=


44/110


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


45/110


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=


46/110


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


47/110


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


48/110


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


base=1nextseqnum=1

rdt_rcv(rcvpkt)&& corrupt(rcvpkt)

L


49/110


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


50/110


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



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


51/110


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


52/110


Selective repeat: sender, receiverwindows


53/110


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


54/110


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


55/110


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)?


56/110


Chapter 3 outline






segment structurereliable data transfer

flow controlconnectionmanagement

3.6 principles of

congestion control3.7 TCP congestioncontrol

TCP O i


57/110


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


58/110


TCP segment structure


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


59/110


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


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


sequence numberacknowledgement number

checksum

rwndurg pointer

outgoing segment from sender

TCP b


60/110


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


61/110


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


62/110


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


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)


63/110


timeout interval: EstimatedRTT plus safety

margin

large variation in EstimatedRTT -> larger safety margin

estimate SampleRTT deviation from EstimatedRTT:DevRTT = (1- )*DevRTT +*|SampleRTT-EstimatedRTT|


(typically, = 0.25)

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT safety margin


64/110


Chapter 3 outline








3.6 principles of



65/110


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


66/110


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


67/110


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


68/110


TCP: retransmission scenarios

lost ACK scenario

Host BHost A

Seq=92, 8 bytes of data

ACK=100


X t i m e o u

t

ACK=100

premature timeout

Host BHost A


ACK=100

Seq=92, 8bytes of data

t i m e o u

t

ACK=120


ACK=120

SendBase=100

SendBase=120

SendBase=120

SendBase=92


69/110


TCP: retransmission scenarios

X

cumulative ACK

Host BHost A


ACK=100


t i m e o u t


ACK=120


70/110


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


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


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


72/110


X

fast retransmit after sender

receipt of triple duplicate ACK

Host BHost A


ACK=100

t i m e o u

t ACK=100

ACK=100

ACK=100

TCP fast retransmit




73/110


Chapter 3 outline








3.6 principles of


TCP fl t l


74/110


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


75/110


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


76/110


Chapter 3 outline








3.6 principles of


C ti M g t


77/110


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


78/110


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)




79/110


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


80/110


81/110

TCP: closing a connection


82/110


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


83/110

Ch 3 li


84/110


Chapter 3 outline








3.6 principles of



85/110


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


86/110

Causes/costs of congestion: scenario


87/110


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



88/110


idealization: perfectknowledgesender sends onlywhen router buffersavailable


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



89/110


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



90/110


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



91/110


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



92/110


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


3


93/110


four sendersmultihop pathstimeout/retransmit

Q: what happens as l in andl

in

increase ?


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


94/110


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


95/110


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


96/110


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


97/110


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


98/110


Chapter 3 outline




3.4 principles ofreliable data

transfer




3.6 principles of



99/110

TCP Congestion Control:d l


100/110


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


101/110


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


102/110


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


103/110


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


104/110


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


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


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


105/110


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


106/110


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


107/110


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?


108/110


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)


109/110


( )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


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

network service - chapter_3_v6.0

Documents