ComputerNetworks:ArchitectureandProtocols

CS4450

Lecture20

ReliableTransport

RachitAgarwal

1

Announcements

• Prelim

• Wewillhaveprelimon30thofApriland1stofMay

• Examreleasedoncanvasonthe30that00:01AMET

• Youcanstartworkingwheneveryouwant• Scannedcopiestobesubmittedby1stofMay,11:59AMET

• Overall48hourstofinishtheexam,submitthecopies

• Pleaseletusknowimmediatelyifthereisanissuewiththis

• Wewillpostapracticeprelim(andsolutions)byThursday

• However,itsforpracticeonly;themainprelimmaybedifferent

2

GoalofToday’sLecture

• Understandingreliabletransportconceptually• Whatarethefundamentalaspectsofreliabletransport

• Backtoarchitecturalprinciplesforonelecture

• ThegoalisnottounderstandTCP• TCPinvolveslotsofdetailedmechanisms,coveredlater

• Groundrulesfordiscussion• NomentionofTCP

• Nomentionofdetailedpracticalissues

• Focusonlyon“ideal”worldofpacketsandlinks

3

DecisionsandTheirPrinciples

• Howtobreaksystemintomodules?

• Dictatedbylayering

• Wherearemodulesimplemented?

• DictatedbyEnd-to-EndPrinciple

• Wherestateisstored?

• Dictatedbyfate-sharing

5

TodayWeDesignReliableDelivery

• Theend-to-endprincipletellsus?• Putreliabilityintheend-host,notthenetwork

• Layeringdictatesputtingreliabilityinwhatlayer?• Abovenetworklayer• L4focussesonprocess-to-processdelivery(“flow”)

• Fatesharingtellsus?• Keepallreliabilitystateinends,notinnetwork

6

BestEffortService(L3)

• Packetscanbelost• Packetscanbecorrupted• Packetscanbereordered• Packetscanbedelayed• Packetscanbeduplicated• …

Howcanyoupossiblemakeanythingwork

withsuchaservicemodel?

7

ChallengeForToday

• Buildingastackthatsupportsreliabletransfer• Sothatindividualapplicationsdon’tneedtodealwithpacketlosses,etc.

• Whatmechanismscanweputinthetransportlayertoprovidereliability?

• Reliabilityisfocusedonsingle“flow”• Flow:streamofpacketsbetweentwoprocesses

• Usuallydefinedusingthe5-tuple:• (sourceIP,destIP,sourcePort,destPort,protocol)

8

FourGoalsforReliableTransfer

• Correctness• Tobedefined

• “Fairness”• Everyflowmustgetafairshareofnetworkresources

• FlowPerformance

• Latency,jitter,etc.

• Utilization• Wouldliketomaximizebandwidthutilization

• Ifnetworkhasbandwidthavailable,flowsshouldbeabletouseit!

9

StartWithTransferofaSinglePacket

• Wecanlaterworryaboutlargerfiles,butinthebeginningitiscleanertofocusonthissimplecase

10

CorrectnessCondition

• Routinghadacleancorrectnesscondition

• Wewantsamekindof“ifandonlyif”characterizationof“correct”

reliabletransportdesigns

• Thisconditionisforthedesigntobecorrect,notthebestperformant

• Oneobviousrequirement:

• Transportneverclaimstohavedelivereddatathatwasn’tdelivered…

• Butweneedmorethanthat.What?

11

CorrectnessCondition?

• Howabout:“Packetisalwaysdeliveredtoreceiver”?

• i.e.,Transportisreliableifandonlyifpacketsarealwaysdeliveredtothereceiver…

• Isn’tthatsimple?

12

WRONG!

• Whatifnetworkispartitioned?

• Partitionedmeansthatthenetworkisbrokenintotwoormoredisconnectedcomponents…

• Wecan’tclaimatransportdesignisincorrectifitdoesn’tworkinapartitionednetwork!

• Afterall,thereisnowaytoreachthedestination!

13

CorrectnessCondition?

• Packetisdeliveredtoreceiverifandonlyifitspossibletodeliverpacket

14

WRONG!

• Ifthenetworkisonlyavailableatoneinstantoftime,onlyanOraclewouldknowwhentosend

• Wecan’tclaimatransportdesignisincorrectifitdoesn’tknowthe

unknowable…

• Soweneedtofocusonwhatthetransportdesignistryingtodo,notwhatitactuallyaccomplishes

15

CorrectnessCondition?

• Resendpacketifandonlyiftheprevioustransmissionwaslostorcorrupted

• Thisisbetterbecauseitrefersto:• whatthedesigndoes(whichitcancontrol)• notwhetheritalwayssucceeds(whichitcan’t)

16

WRONG!

• Impossible

• “CoordinatedAttack”overanunreliablenetwork

• Considertwocases:• Packetdelivered;allpacketsfromreceiveraredropped

• Packetdropped;allpacketsfromreceiveraredropped

• Theyareindistinguishabletosender• Inbothcases,packetwassent,andnofeedbackatall• Doesitresend,ornot?

17

CorrectnessCondition?

• Packetisalwaysresentiftheprevioustransmissionwaslostorcorrupted

• Packetmayberesentatothertimes

• Note:• Thisinvariantgivesusasimplecriterionfordecidingifanimplementationiscorrect

• Efficiencyandsimplicityareseparatecriteria

18

AlmostRight!

• What’swrongwithit?

• Animplementationthatneversentthepacketatallisreliableaccordingtothedefinition.

19

CompleteCorrectnessCondition

• Atransportmechanismis“reliable”ifandonlyif

(a) Itresendsalldroppedorcorruptedpackets

(b) Itattemptstomakeprogress

• Makingprogressmeans:

• Ifthereisdatatosend,transporteventuallyattemptstosenddata

• Veryimportant:“eventuallyattempts”!

• Itshouldnotbeblockedforever

• And,itmaynotsucceed,butitmustattempt

• Example:Iftherearetenpacketstosend,transportcan’tjustsendthefirstfiveandthenstopforever

20

CompleteCorrectnessCondition

• Atransportmechanismis“reliable”ifandonlyif

(a) Itresendsalldroppedorcorruptedpackets

(b) Itattemptstomakeprogress

• Sufficient(“if”):transportalgorithmwillkeeptryingtodeliverpackets

thathavenotyetreachedthedestination

• Necessary(“onlyif”):ifiteverletsapacketgoundeliveredwithouttryingagain,ornevertriestosendapacketwhenallothershavebeen

delivered,itisn’treliable

21

Note!

• Atransportmechanismcan“giveup”,butmustannouncethisto

application

• Ifthetransportmechanismhastriedforsomeperiodtodeliverthedata,andhasnotsucceeded:

• Itmightdecidethatitisbettertogiveup

• Andapplicationscanreinitiatedatatransfer• Thatisallowed…

• Butitcanneverfalselyclaimtohavedeliveredapacket

22

WehaveCorrectnessCondition

23

• Howdoweachieveit?

• Focusonsingle-packetsolutions

FourGoalsforReliableTransfer

• Correctness

• “Fairness”• Everyflowmustgetafairshareofnetworkresources

• FlowPerformance

• Latency,jitter,etc.

• Utilization• Wouldliketomaximizebandwidthutilization

• Ifnetworkhasbandwidthavailable,flowsshouldbeabletouseit!

24

Solutionv1

• Sendthepacketasoftenandfastaspossible…

• Isitcorrect• No.• Why?

• The“if”conditionisnotsatisfied:(a) Transportmustattempttomakeprogress

• Nowaytocheckwhetherthepacketwasdroppedorcorrupted• So,mustcontinuesendingthesamepacket

• Willnevermakeprogressonotherflows(fromsamesource)

25

What’smissing?

• Feedbackfromreceiver!

• Ifreceiverdoesnotrespond,nowayforsendertotellwhentostopresending

• Cannotachievecorrectnesswithoutfeedback

26

FormsofFeedback

• ACK:Yes,Igotapacket

• NACK:No,Ididnotgetthepacket

• WhenisNACKanaturalidea?

• PacketCorruption(Igotpacket#5butitwascorrupted)

• IgnoreNACKsforrestofthelecture…

27

Solutionv2

• ResendpacketuntilyougetanACK• Andreceiversendsper-packetACKsuntildatafinallystops

• Correct?• Yes:

• Alldropped/corruptedpacketswillberetransmitted• Thetransportwillattempttomakeprogress

• Fair?• Overlong-term,yes:

• allsourceswillgetanequalchancetousenetworkresources

• Flowperformance?• Goodbutnotnecessarilyoptimal

• Unnecessarilyretransmittedpacketsmayinflatelatency

• Utilization:• suboptimal;packetsretransmittedunnecessarily28

Solutionv3

• Sendpacket• Butnow,setatimer

• Whenreceivergetspacket,sendsACK

• IfsenderreceivesACK,done• IfnoACKwhentimerexpires,resend

• Stillcorrect,andfair• Performancewouldargueforsmalltimeout

• Utilizationwouldargueforlargertimeout

• Maywanttoincreasetimereachtimeyoutry

• Maywanttocapthenumberofretries

• Problemswiththisdesign?

29

Have“Solved”theSinglePacketCase

• Sendpacket• Setatimer

• IfnoACKwhentimergoesoff,resendpacket

• Andresettimer

• Tradeoffbetweenperformanceandutilizationinselectionoftimeout:

• Toosmall:unnecessaryretransmissions(underutilization)

• Toolarge:waitingunnecessarily(poorperformance)

30

MultiplePackets

• Servicemodel:reliablestreamofpackets

• Handupcontiguousblockofpacketstoapplication

• Whynotusesingle-packetsolution?

• Sendthenextpacketoncethefirstonehasbeendelivered• Problem:Onlyonepacket“inflight”atatime

• LowEffectivethroughput:PacketSize/RTT

• Usewindowbasedapproach• AllowforawindowofWpacketsin-flightatanytime(unack’ed)

• Slidethewindowaspacketsareack’ed• SlidingwindowimpliesWpacketsarecontinuous

31

Window-basedAlgorithms

• Verysimpleconcept

• SendWpackets

• WhenonegetsACK’edsendthenextpacketinline

• Itreallyisthatsimple(untilwegottoTCP)

• Willconsiderseveralvariations…

• Butfirst…

32

HowBigShouldtheWindowbe?

• Windowsservethreepurposes

• Takingadvantageofthebandwidthofthelinks• Limitingbandwidthusedbyaflow(congestioncontrol)

• Limitingtheamountofbufferingneededatthereceiver

• Whydoreceiversneedtobufferpackets?

• Answer:packetre-ordering(discussedlater)

• Ifweignoreallbutthefirstgoal,thenwewanttokeepthesenderalwayssending(intheidealcase)

• RTT:fromsendingfirstpacketuntilreceivedfirstACK

• Condition:• RTTxB~WxPacketSize

33

Whatdoesthismean?

• Bistheminimumlinkbandwidthalongthepath

• Obviouslyshouldn’tsendfasterthanthat

• WewanttosetWsuchthat:

• ifIamsendingatrateB,then

• theACKofthefirstpacketarrives• exactlywhenIjustfinishsendingthelastofmyWpackets

• Letsmesendasfastasthepathcandeliver…

34

RTTxB~WxPacketSize

• RecallthatBandwidthDelayProduct• BDP=bandwidthxpropagationdelay

• BxRTTismerely2xBDP

• Windowsizingrule:

• Totalbitsinflightisroughlytheamountofdatathatfitsinto

forwardandreverse“pipes”

• Herepipeiscompletepath,notsinglelink…

• Thisisnot“detail”,thisisafundamentalconcept…

bandwidth

Propagation delay

delay x bandwidth

35

WhereAreWe?

• Figuredoutcorrectnesscondition:• Alwaysresendlost/corruptedpackets• Alwaystrytomakeprogress(butcangiveupentirely)

• Figuredoutsinglepacketcase:• Sendpacket,settimer,resendifnoACKwhentimerexpires

• Someprogresstowardsmultiplepacketcase:

• Allowmanypackets(W)inflightatonce

• Andknowwhattheidealwindowsizeis• RTTxB/Packetsize

• What’slefttodesign?

36

ThreeDesignConsiderations

• Natureoffeedback• WhatshouldACKstelluswhenwehavemanypacketsinflight

• Detectionofloss

• Responsetoloss

37

ACKIndividualPackets

• Natureoffeedback:simple-thereceiverACKseachpacket

• Responsetoloss:moderate:

• +RetransmitthepacketforwhichACKnotreceived

• +Reorderingnotaproblem

• +Simplewindowalgorithm

• Windependentsinglepacketalgorithms

• Whenonefinishesgrabnextpacket

• -LossofACKpacketrequiresaretransmission

38

FullInformationFeedback

• Listallpacketsthathavebeenreceived• GivehighestcumulativeACKplusanyadditionalpackets

• Ifpackets1,2,3,4,6received:sendACK(4,6)

• Strengths?• Asmuchinformationasyoucouldhopefor

• ResilientformofindividualACKs

• Weaknesses?

• Couldrequiresizableoverheadinbadcases• Feasibleifonlysmallholes

• Ifpackets1,2,3,4,6,….,100received:ACK(4,6,…,100)

39

• Natureoffeedback:complex-feedbackmayhavehighoverheads

• Ifpackets1,2,3,4,6,….,100received:ACK(4,6,…,100)

• Responsetoloss:simple:

• +RetransmitthepacketforwhichACKnotreceived

• +Reorderingnotaproblem

• +Simplewindowalgorithm

• -LossofACKdoesnotnecessarilyrequiresaretransmission

• ThenextACKwilltellthatthepacketwasindeedreceived• ResilientformofindividualACKs

40

FullInformationFeedback

CumulativeACK

• IndividualACKscangetlost,andrequireunnecessaryretransmission

• FullinformationfeedbackcanhandlelostACKsbuthashighoverheads

• CumulativeACKs:asweetspotbetweenthetwo

• Justthefirstpartoffullinformationfeedback

• ACKthehighestsequencenumberforallpreviouslyreceivedpackets

• Implementationsoftensendback“nextexpectedpacket”,butthat’sjustadetail

41

CumulativeACKs(sameexample;saypacket5lost)

42

Fullinformationfeedback:

• StreamofACKswillbe

• Upto1• Upto2• Upto3• Upto4• Upto4,plus6• Upto4,plus6,7• Upto4,plus6,7,8• …

CumulativeACKs:

• StreamofACKswillbe

• Upto1• Upto2• Upto3• Upto4• Upto4• Upto4• Upto4• …

Tells“some”packetarrived,andwhichpacketdidnot

Tells“which”packetarrived,andwhichpacketdidnot

CumulativeACK

• IndividualACKscangetlost,andrequireunnecessaryretransmission

• FullinformationfeedbackcanhandlelostACKsbuthashighoverheads

• CumulativeACKs:asweetspotbetweenthetwo

• Justthefirstpartoffullinformationfeedback

• ACKthehighestsequencenumberforallpreviouslyreceivedpackets

• Implementationsoftensendback“nextexpectedpacket”,butthat’sjustadetail

• Strengths?• ResilienttolostACKs

• Weaknesses?

• Confusedbyreordering• Incompleteinformationaboutwhichpacketshavearrived

43

DetectingLoss

• Ifpackettimesout,assumeitislost…

• Howelsecanyoudetectloss?

44

LossWithIndividualACKs

• Assumethatpacket5islost,butnoothers

• StreamofACKswillbe

• 1• 2• 3• 4• 6• 7• 8• …

45

LossWithIndividualACKs

• Couldresendpacketwhenk“subsequentpackets”arereceived

• Responsetoloss• Resendmissingpacket

• Continuewindowbasedprotocol

46

LossWithFullInformation

• Samestory,exceptthatthe“hole”isexplicitineachACK

• StreamofACKswillbe

• Upto1• Upto2• Upto3• Upto4• Upto4,plus6• Upto4,plus6,7• Upto4,plus6,7,8• …

47

LossWithFullInformation

• Couldresendpacketwhenk“subsequentpackets”arereceived

• Responsetoloss• Resendmissingpacket

• Continuewindow-basedprotocol

48

LossWithCumulativeACKs

• Assumepacket5islost,butnoothers

• StreamofACKswillbe

• 1• 2• 3• 4• 4(Sentwhenpacket6arrives)• 4(Sentwhenpacket7arrives)• 4(Sentwhenpacket8arrives)• …

49

LossWithCumulativeACKs(cont’d)

• DuplicateACKsareasignofloss• ThelackofACKprogressmeans5hasn’tbeendelivered

• StreamofduplicateACKsmeanssomepacketsarebeingdelivered(oneforeachsubsequentpacket)

• Responsetolossistrickier…Whenshallthesourceretransmitpacket5?

• Packetmaybedelayed(so,sourceshouldwait)

• Packetmaybereordered(so,sourceshouldwait)

• Or,packetmaybedropped(sourceshouldimmediatelyretransmit)

• Impossibletoknowwhichoneisthecase

• Lifelesson:beoptimistic!

• Untiloptimismstartshurting

• Solution:retransmitafterkduplicateACKs

• forsomevalueofk,dependingonhowoptimisticyoufeel!

50

CumulativeACKs(howisreorderinghandled;largek)

51

Receiverevents:

• Packet1received• Packet2received• Packet3received• Packet4received• Packet6received• Packet7received• Packet5received• Packet8received• …

CumulativeACKs:

• Upto1• Upto2• Upto3• Upto4• Upto4• Upto4• Upto7• Upto8• …

CumulativeACKsnaturallyhandlepacketreordering(Packetdelaysaresimilartoreordering)

LossWithCumulativeACKs(cont’d2)

• Twochoices• Sendmissingpacketandoptimisticallyassumethatsubsequentpacketshavearrived

• i.e.,increaseWbythenumberofduplicateACKs

• Sendmissingpacket,waitforACK

• Timeout-detectedlossesalsoproblematic

• Ifpacket5timesout,packet6isabouttotimeoutalso

• Doyouresendboth?• Doyouresend5andwait?• …

52

• ProduceduplicateACKs• CouldbeconfusedforlosswithcumulativeACKs

• Butduplicationisrare…

53

Receiverevents:

• Packet1received• Packet2received• -• Packet4received• Packet5received• Packet6received• Packet3received• Packet3received• Packet7received• …

CumulativeACKs:

• Upto1• Upto2• -• Upto2• Upto2• Upto2• Upto6• Upto6• Upto7• …

Sourceevents:

• Packet1sent• Packet2sent• Packet3sent• Packet4sent• Packet5sent• Packet6sent• Packet3resent• Packet7sent• …

CumulativeACKs(confusionwithduplication)

CumulativeACKs

• Theymakenosense,exceptasacheapalternativetofullinformation

• Lessstatethanfullinformation

• MoreresilientthanindividualACKs

• Butambiguityinfeedbackleadstomanyproblems

• Haveotherpacketsarrived?

• Makesretransmissionandcongestionwindowmanagementhard

• WilldealwiththeseissueswhenwecometoTCP

54

AllTheBadThingsBestEffortCanDo

• Packetscanbelost

• Packetscanbecorrupted

• Packetscanbereordered

• Packetscanbedelayed

• Packetscanbeduplicated

55

EffectofReordering?

• Foralldesignsthislookslike“subsequentACKs”

• Thiscanbemistakenforpacketloss

• Hardtorealizethedifferencebetweenthesepacketarrivalpatterns:• 1,2,3,4,6,7,8,9,…• 1,2,3,4,6,7,8,9,5,10,…

56

EffectofLongDelays?

• Possibletimeouts(foralldesigns)

57

EffectofDuplication

• ProduceduplicateACKs• CouldbeconfusedforlosswithcumulativeACKs

• Butduplicationisrare…

58

PossibleDesignForReliableTransport

• FullinformationACKs

• Windowbased,withretransmissionsafter

• Timeout

• KsubsequentACKs

• Thisiscorrect,high-performantandhigh-utilization

• Howaboutfairness?

59

Fairness?(Comebacktolater)

• AdjustWbasedonlosses…

• Inawaythatflowsreceivesameshares

• Shortversion:• Loss:cutWby2

• Successfulreceiptofwindow:Wincreasedby1

60

OverviewofReliableTransport

• Windowbasedselfcontrolseparateconcerns

• SizeofW

• Natureoffeedback• Responsetoloss

• Candesigneachaspectrelativelyindependently

• Canbecorrect,fair,high-performantandhigh-utilization

61

ManyImplementationChoices

• Feedbackfromreceiver:ACKsvsNACKs

• CanNACKsaloneachievecorrectness• CanACKsaloneachievecorrectness

• VariationsonACKs• Fullinformation

• Individualpackets• Cumulative(TCP)

• Whentoresend

• Timeout

• DuplicateACKs• NACKs

62

ImplementationChoices

• Theseimplementationchoicesaffect:

• Performance

• Utilization• Fairness• ..

• Theseareimportantconcerns

• Butcorrectnessismorefundamental

• Designmuststartwithcorrectness

• Canthen“engineer”itsperformancewithvarioushacks

• Thesehackscanbe“fun”,butdon’tletthemdistractyou

63

WhatHaveWeDonesofar?

• Startedfromfirstprinciples

• Correctnessconditionforreliabletransport

• …tounderstandingwhyfeedbackfromreceiverisnecessary(sol-v1)

• …tounderstandingwhytimersmaybeneeded(sol-v2)

• …tounderstandingwhywindow-baseddesignmaybeneeded(sol-v3)

• …toradicallydifferentmanypossibledesignchoices

• SomeofthemclosetomodernTCP

• YouarenowreadytolearnTCP

64

Wetriedtounderstand:

WhyisTCPdesignedthewayitisdesigned!

Whyisalmostalwaysthemostimportantquestion!!!

65