Computer Networks

Lecture29:TCPConnectionEstablishment

InternetProtocolStack

application:supportingnetworkapplications•  HTTP,SMTP,FTP,etc.

transport:endhost-endhostdatatransfer•  TCP,UDP

network:routingofdatagramsfromsourcetodestination•  IP,routingprotocols

link:datatransferbetweenneighboringnetworkelements•  Ethernet,WiFi

physical:bits“onthewire”

application

transport

network

link

physical

TransportProtocolsProvidelogicalcommunicationbetweenapplicationprocessesrunningondifferenthosts

Runonendhosts• sender:breakseachapplicationmessageintosegments,andpassesthemontothenetworklayer

• receiver:reassemblessegmentsintomessages,passesthemtotheapplicationlayer

Multipletransportprotocolsareavailabletoapplications

InternetTransportProtocolsReliable,in-orderdelivery(TCP)• connectionsetup• flowcontrol• congestioncontrolUnreliable,unordereddelivery(UDP)• no-frillsextensionofbest-effortIPServicesnotavailable• delayguarantees• bandwidthguarantees

WhyWouldAnyoneUseUDP?

Lightweightcommunicationbetweenprocesses:• fasterthanTCP,noconnectionestablishment/tear-downstages(1vs.2.5rtts)•  simplysendmessagestoandreceivethemfromasocket

• noconnectionstateatserverandclient•  avoidoverheadanddelaysofordered,reliabledelivery•  noallocationofbuffers,parameters,sequence#s,etc.• makingiteasiertohandlemanyactiveclientsatonce

Lightweightcommunicationbetweenprocesses:• smallsegmentheader•  UDPheaderisonlyeight-byteslong• finecontroloverwhatdataissentandwhen

•  assoonasanapplicationprocesswritesintothesocket•  UDPpackagesthedataandsendsthepacket• nocongestioncontrol• UDPcanblastawayasfastasthenetworkcanhandle

• broadcast&multicastcanonlyuseUDP(Why?)

WhyWouldAnyoneUseUDP?

PopularApplicationsThatUseUDPSimplequeryprotocolslikeDNS• overheadofconnectionestablishmentisoverkill• easiertohavetheapplicationretransmitifnecessary

Multimediastreaming•  losstolerant,ratesensitive

•  bythetimealostpacketisretransmitted,it’stoolate•  congestioncontrolintroducestoomuchjitter•  e.g.,calls,videostreaming,gaming

ReliableUDP:addreliabilityatapplicationlayer•  application-specificerrorrecovery!

�www.umich.edu?�

�141.211.243.44�

Connectionoriented• explicitset-upandtear-downofTCPsession

Stream-of-bytesservice• sendsandreceivesastreamofbytes,notdiscretemessages

Flowcontrol•  preventoverflowofthereceiver’sbufferspace

Reliabledelivery•  retransmissionoflostpackets

Congestioncontrol• adapttonetworkcongestionforthegreatergood

Doesnotprovidetimingguaranteenorminimumbandwidthguarantee

TCP:TransmissionControlProtocol

TCP“StreamofBytes”Service

Byte 0

Byte 1

Byte 2

Byte 3

Byte 0

Byte 1

Byte 2

Byte 3

HostA

HostB

Byte 80

Byte 80

[Rexford]

EmulatedUsingTCP“Segments”

Byte 0

Byte 1

Byte 2

Byte 3

Byte 0

Byte 1

Byte 2

Byte 3

HostA

HostB

Byte 80

TCP Data

TCP Data

Byte 80

Segmentsentwhen:1.  segmentfull(MaxSegmentSize),2.  notfull,buttimesoutwaitingfor

moredatafromapp,or3.  “pushed”byapplication

[Rexford]

TCP:TransmissionControlProtocolProvidesreliabilityondatagramnetworkWhatdoesreliabledeliveryentail?• • • • LinklayeralreadyprovidesreliabledeliveryWhydoweneedprovideitagainatthetransportlayer?• • 

NeedforE2EReliability

1 0 1

1 0 1 1 1 1

1 1 1

2

1

5

34

67

1

2

3

5

4

7

pkt3corruptedordropped

E2EReliabilityLackofreliabledeliverydueto:•  re-routedpackets•  biterror•  dropped/lostpackets(duetocongestion)•  systemrebootsWhataresomeofthetoolsavailabletoustoachievereliabilityatthetransportlayer,givenunreliablenetworklayer?•  •  •  • 

SequenceNumberWhataretheusesofsequencenumberinprovidingreliability?• • • 

TCP’sCumulativeACKACKsthelastbytereceivedin-orderTellssenderthenext-expectedseq#Ifbytes0tonhavebeenreceived,ACKsaysn+1subsequentout-of-orderpacketsgeneratethesamecumulativeACK:

Advantage:lostACKcanbe“covered”bylaterACKsDisadvantage:sizeofgapbetweentwopacketsnotknowntosender

TCPCumulativeACK

16

HostA

HostB

TCP Data

TCP Data

TCP HDR

TCP HDR

ISN (initial sequence number)

Sequencenumber=1stbyte

ACKsequencenumber=nextexpectedbyte

ConnectionEstablishment

TCPSYNchronizationpackettoestablishaconnectioncarriestheInitialSequenceNumber(ISN)

Firsttry:Lesson:connectionrequestmustbeACKed

SenderS

DestinationD

SYN ISN=Xreboot

SYN ISN=Z

Expected Seq# ESN = X+1,ESTABLISHED

discardZ+1

Z+2dropped,but connection with ESN = X+1remainsESTABLISHED

Host S Host D

ConnectionEstablishment

Secondtry:Lesson:connectionACKmustbeACKedorrejected

SenderS

DestinationD

stray SYN ISN=X

SYN ISN=Y ACK X+1

ESN = X+1

ESTABLISHED

discard

Y+1

(piggy-backed ACK)

Host S Host D

TCPConnectionEstablishmentThree-wayhandshake:SYNusesaseq#

SenderS

DestinationD

SYN ISN=X

SYN ISN=Y ACK X+1

X+1

ESN = Y+1ESTABLISHED

ESN = X+1ESTABLISHED

ACK Y+1

Host D Host S

Three-WayHandshake

Howthree-wayhandshakesolvestheoriginalproblems:WhatiftheSYNpacketislost?• sincethere’snogoodwaytogaugeRTT• someTCPsendertimesoutafter3-6seconds

SenderS

DestinationD

SYN ISN=X

reboot

SYN ISN=Z

SYN ISN=Y ACK X+1

RST ZRST Y

SenderS

DestinationD

stray SYN ISN=X

SYN ISN=Y ACK X+1

ESN = X+1

ESTABLISHED

discard

RST Y

Host S Host D Host S Host D

TCPSegment

IPpacket• nobiggerthanMaximumTransmissionUnit(MTU)• e.g.,upto1500bytesonanEthernet

TCPpacket•  IPpacketwithaTCPheaderanddatainside• TCPheaderistypically20byteslong

TCPsegment• nomorethanMaximumSegmentSize(MSS)bytes• e.g.,upto1460consecutivebytesfromthestream•  (note:PA3’sMSSincludesIPheader)

IP Hdr TCP Hdr TCP Data (segment)

MSS MTU

[Rexford]

TCPHeader

srcport# dstport#

32bits

applicationdata

(variablelength)

sequencenumber

acknowledgementsequence#

windowsize

urgdatapointerchecksum

FSRPAUheadlen

notused

options(variablelength)URG:urgentdatapointerisvalid/used

(seldomused)

ACK:ACK#valid(ACKpiggy-backed)

PSH:pushdatanow(fflush()called)

RST,SYN,FIN:connectionestablishment

(setup,teardown)

InternetchecksumsameasUDP

receiverwindowsize(rwnd,inbytes)

countingbybytesofdata(notsegments!)

endofurgentdata,e.g.,^C

numberof32-bitfields

inheader

MaximumSegmentSizenegotiation,default(minimumrequired)536bytesofdata

TCPHeaderFieldsSequencenumber:•  sequencenumberscountbytessent•  seq#ofapacketistheseq#ofthefirstbyteitcarries

Acknowledgementsequencenumber:allowsforpiggy-backedACK• TCPtrafficisoftenbidirectional•  bothdataandACKstravelinbothdirections• ACKpacketshavehighoverhead•  40bytesfortheTCP/IPheaders,carryingnodata• piggy-backingallowsahostDtosenditsACKtohostSalongwithitsdataforhostS• delayedACK:TCPallowsthereceivertodelaysendingofACKstoincreasechancesofpiggy-backingandtoreducenumberofACKs(sincethey’recumulative)

Step1:S’sInitialSYNPacket

S’sport D’sport

S’sISN

AcknowledgmentSeq#

windowsize5 0

Checksum Urgentpointer

Options(variable)

Flags: SYNFINRSTPSHURGACK

HostStellsHostDitwantstoopenaconnection…

FSRPAU

[Rexford]

Step2:D’sSYNACKPacket

D’sISN

S’sISNplus1

Options(variable)

Flags: SYNFINRSTPSHURGACK

HostDtellsHostSitaccepts,andisreadytohearthenextbyte…

UponreceivingHostD’sSYNACKpacket,HostScanstartsendingdata

FSRPAU

[Rexford]

D’sport S’sport

windowsize

Checksum Urgentpointer

5 0

UponreceivingHostS’spacket,HostDcanstartsendingdata

Step3:S’sACKoftheSYNACK

D’sISNplus1

Options(variable)

Flags: SYNFINRSTPSHURGACK

HostStellsHostDitisokaytostartsending

Sequencenumber

FSRPAU

[Rexford]

S’sport D’sport

windowsize

Checksum Urgentpointer

5 0

ConnectionTear-downWhentoreleaseaconnection?Howdoyouknowtheothersideisdonesendingandallsentpacketshavearrived?Use3-wayhandshaketotear-downconnection:FINalsousesaseq#

SenderS

DestinationD

FIN X

ACK X+1 FIN Y

ACK Y+1

Host S Host D

ConnectionTear-down

Iftheothersidestillhasdatatosend:WhynotdelayACK X+1untilFIN Y?

SenderS

DestinationD

FIN X

ACK X+1

ACK Y+1

FIN Y

More datapacketsfrom D

Host S Host D

ConnectionTear-down

Stilldependsontimeoutforcorrectness:

SenderS

DestinationD

FIN X

ACK X+1 FIN Y

ACK Y+1

X

rto

FIN X

ACK X+1 FIN Y

SenderS

DestinationD

FIN X

ACK X+1 FIN Y

ACK Y+1X

rto

times out andtears down connectionunilaterally

Host S Host D Host S Host D

ConnectionTear-downStilldependsontimeoutforcorrectness:TCPconnectiontear-downdependsontimersforcorrectness,butuses3-wayhandshakeforperformanceimprovement

SenderS

DestinationD

FIN X

ACK X+1 FIN Y

FIN X

Xrto

times out and tears downconnectionunilaterally

X

FIN X

rto

rto

ACK X+1 FIN Y

X

after n attemptstears downconnection

unilaterally

Host S Host D

SocketConnectionQueues

Stevens TCP/IP Illustrated v. 2 pp. 441, 461

sd

td

TCPConnectionEstablishmentDemo

% ifconfig –a % sudo tcpdump –i en0 –S host web.eecs.umich.edu

TCPConnectionManagementFSM

TCPclientlifecycle

TCPserverlifecycle

Puttogether...

FiniteSequenceNumberSpaceIssuesarisingfromhavingfinitesequencenumberspace:1.  choiceofsequencespacesize2.  sequencenumberwraparound3.  initialsequencenumber(ISN)choice

SequenceNumberSpaceSizeIfwehadonly2bitstokeeptrackofsequencenumbers:Let:A:timetakenbyreceivertoACKpacketT:timesendercontinuesretransmitting

ifanACKisnotreceived

MaximumSegmentLifetime(MSL):2MPL + T + A

2 1 123 00S D

new? or rexmit?

T

MPL: Max. Pkt. Lifetime

A

MPL

DuplicatedSequenceNumberMaximumSegmentLifetime(MSL):2MPL + T + AWant:nosequencenumbermaybeduplicatedwithinanMSLWhatwouldcauseasequencenumbertobeduplicatedwithinanMSL?• sequencenumberwrapsaround(withinasingleconnection)• sequencenumberre-used(acrossconnections)

SequenceNumberWrapAroundSequencespace(N)isfiniteandsequencenumbercanwraparound:Assumings1ands2arenotmorethanN/2apart,s1 > s2ifeither:1.  |s1 – s2| < N/2ands1 > s2,or2.  |s1 – s2| > N/2ands1 < s2

0

3

1

2

0

which isnewer?

pkt 3 queued/delayed

S2 S1

0 N

0 N

S1 S2

RequiredSequenceNumberSizeTopreventduplicatesequencenumber:fors1 > s2,s1ands2cannotbemorethanN/2 apart(|s1 – s2| < N/2)withinanMSL

ForTCP,N = 232–1,N/2maximumseparationrequirementmeansthatonlyn = 31bitsareusable

Letµbethetransmissionbandwidth,worstcase,assumingsendercan“fillthepipe”,want:µ < (N/2)/MSLor,2n > µ*MSL• example:SF-NYMPLis25msec.letMSL = 2min,forn = 31bits,µmustbe<17.8MB/s(143Mbps)

RequiredSequenceNumberSizeButTCPtransmissionisconstrainedbythereceiver’sadvertisedwindow(rwnd),whichisof16-bitsize

Only64KBcanbeoutstandingatanyonetime,whichtakeslessthan⅓ofasecondtoclearthenetworkevenat“slow”T1speed(1.5Mbps)

Sowedon’thavetoworryaboutsequencenumberre-useduetowraparound

InitialSequenceNumber(ISN)SequencenumberfortheveryfirstbyteWhynotalwaysstartwithanISNof0?IPaddressesandport#suniquelyidentifyaconnection,butportnumbersgetreusedwhen:• •  andconnectionsget“reincarnated”WewantISNsthatwillnotletpacketsfromanoldconnectionthatarestillinflighttobemistakenforpacketsfromthenewconnection

ISNfromSystemClockAssumeclockkeepstickingevenwhenmachineisdownWant:noseq.numbermaybeduplicatedwithinanMSLForbiddenregion:usingsequencenumbercurrentlyinforbiddenregioncouldcauseduplicateISNchosenby“reincarnated”connectionWhattodoonhittingforbiddenregion(d)?d) nothing:seqnoduplicatedby“reincarnated”connectione) waitforMSLbeforeresumingtransmissionf)  resynchronizesequencenumbereither(e)or(f),connectionstalled

2n

connectionstart time

last timethis seq#may be used

slowxmission

fastxmission

sequence #wraps around

MSL

Seq #

ForbiddenRegion

wait for MSL

resynchronize

clock tick

ab

dc

e

f

TCP’sHandlingofISN

TCPrequireschangingtheISNovertime• setfroma32-bitclockthatticksevery4µseconds• whichonlywrapsaroundonceevery4.55hours•  unlikelyforreincarnatedconnectiontoshareseqno

ConnectioncannotbereusedforMSLtime•  onconnectiontear-down,waitfor2MSL(TIME-WAITstate,30secs)bind: Address already in use

•  onreboot,donotcreateconnectionforMSL(2minutesboottime,sonotaproblem)