CS 43: Computer Networks

19: TCP Flow and Congestion Control October 31, Nov 2, 2018

Five-layer Internet Model

Lecture19-Slide2

Application:theapplication(e.g.,theWeb,Email)

Transport:end-to-endconnections,reliability

Network:routing

Link(data-link):framing,errordetection

Physical:1’sand0’s/bitsacrossamedium(copper,theair,fiber)

Last class: Practical Reliability Questions

•  Whatdoesconnectionestablishmentlooklike?•  Howdowechoosesequencenumbers?•  Howdothesenderandreceiverkeeptrackofoutstandingpipelinedsegments?

•  Howshouldwechoosetimeoutvalues?•  Howmanysegmentsshouldbepipelined?

Lecture19-Slide3

Last class: Go-back-N

•  Atthesender:•  Atthereceiver:

–  Keeptrackoflargestsequencenumberseen.–  IfitreceivesANYTHING,sendsbackACKforlargestsequencenumberseensofar.(CumulativeACK)

Lecture19-Slide4

Last class: Selective Repeat

Lecture19-Slide5

Last class: TCP Timeout Value

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”

Lecture19-Slide6

ExponentiallyWeightedMovingAverage(EWMA)EstimatedRTT=(1–α)*EstimatedRTT+α*SampleRTT

Today: Practical Reliability Questions

•  Whatdoesconnectionestablishmentlooklike?•  Howdowechoosesequencenumbers?•  Howdothesenderandreceiverkeeptrackofoutstandingpipelinedsegments?

•  Howshouldwechoosetimeoutvalues?•  Howmanysegmentsshouldbepipelined?

Lecture18-Slide7

Sliding window

•  Howmanybytestopipeline?•  Howbigdowemakethatwindow?

–  Toosmall:linkisunder-utilized–  Toolarge:congestion,packetsdropped– Otherconcerns:fairness

Lecture19-Slide8

Discussion: Why do we need rate control ?

A.  tohelptheglobalnetwork(corerouters,andotherend-hosts)

B.  tohelpthereceiverC.  tohelpthesenderD.  someotherreason

Sharedhigh-levelgoal:don’twastecapacitybysendingsomethingthatislikelytobedropped.

Lecture19-Slide9

Rate Control

FlowControl•  Don’tsendsofastthatwe

overloadthereceiver.

•  Ratedirectlynegotiatedbetweenonepairofhosts(thesenderandreceiver).

CongestionControl•  Don’tsendsofastthatwe

overloadthenetwork.

•  Rateinferredbysenderinresponseto“congestionevents.”

Sharedhigh-levelgoal:don’twastecapacitybysendingsomethingthatislikelytobedropped.

Lecture19-Slide10

Flow Control

•  Don’tsendsofastthatweoverloadthereceiver.•  Ratedirectlynegotiatedbetweenonepairofhosts(thesenderandreceiver).

Lecture19-Slide11

Flow Control

•  Examplescenarios:

Fastserver Low-powerdevice

Problem:Sendercansendatahighrate.Networkcandeliveratahighrate.Thereceiverisdrowningindata.

Multiplefastservers FastserverLecture19-Slide12

Flow Control

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Lecture19-Slide13

Flow Control

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Lecture19-Slide14

Flow Control

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Appcallsrecv()

Lecture19-Slide15

Flow Control

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Appcallsrecv()

Lecture19-Slide16

Flow Control

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Lecture19-Slide17

Flow Control

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Lecture19-Slide18

Flow Control

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Stop!

Lecture19-Slide19

TCP Segments

source port # dest port #

32 bits

application data (variable length)

Urg data pointer

F S R P A U head len

not used

URG: urgent data (generally not used)

ACK: ACK # valid

PSH: push data now (generally not used)

RST, SYN, FIN: connection estab (setup, teardown

commands)

checksum

Internet checksum

(as in UDP)

receive window # bytes rcvr willing to accept

sequence number acknowledgement number

counting by bytes of data (not segments!)

options (variable length)

AKA:rwnd

Lecture19-Slide20

Flow Control

•  Senderneversendsmorethanrwnd.

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Lecture19-Slide21

Flow Control

•  Senderneversendsmorethanrwnd.

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Lecture19-Slide22

Flow Control

•  Senderneversendsmorethanrwnd.

Fastserver Low-powerdevice

Finitesocketbufferspaceatthereceiver.

Ack.rwnd:4

last byte ACKed sent,not-

yetACKed(“in-flight”)

last byte sent

min(rwnd,cwnd)

Lecture19-Slide23

Congestion

•  Flowcontrolis(relatively)easy.Thereceiverknowshowmuchspaceithas.

•  Whataboutthenetworkdevices?

Lecture19-Slide24

Congestion

Router

Router’sbuffer.

Lecture19-Slide25

Congestion

Router

Router’sbuffer.

Incomingrateisfasterthanoutgoinglinkcansupport.

Lecture19-Slide26

Trash

Congestion

Router

Router’sbuffer.

Incomingrateisfasterthanoutgoinglinkcansupport.

Ugh.Isocan’tdeal

withthisrightnow!

Lecture19-Slide27

What’s the worst that can happen?

A.  Thisisnoproblem.Sendersjustkeeptransmitting,andit’llallworkout.

B.  Therewillberetransmissions,butthenetworkwillstillperformwithoutmuchtrouble.

C.  Retransmissionswillbecomeveryfrequent,causingaseriouslossofefficiency.

D.  Thenetworkwillbecomecompletelyunusable.

Lecture19-Slide28

Congestion Collapse

…

…

…

…

LinkA LinkB

Lecture19-Slide29

Congestion Collapse

…

…

…

…

LinkA LinkB

Onesenderstarts,butthere’sstillcapacityatlinkA.

S1Lecture19-Slide30

Congestion Collapse

…

…

…

…

LinkA LinkB

S1

S2Anothersenderstartsup.LinkAisshowingslightdelay,butstilldoingok.

Lecture19-Slide31

Congestion Collapse

…

…

…

…

LinkA LinkB

S1

S2

UnrelatedtrafficpassesthroughandcongestslinkB.

Lecture19-Slide32

Congestion Collapse

…

…

…

…

LinkA LinkB

S1

S2 S2’strafficisbeingdroppedatLinkB,soitstartsretransmittingontopofwhatitwassending.

Thisisverybad.S2isnowsendinglotsoftrafficoverlinkAthathasnohopeofcrossinglinkB. Lecture19-Slide33

Congestion Collapse

…

…

…

…

LinkA LinkB

S1

S2

IncreasedtrafficfromS2causesLinkAtobecomecongested.S1startsretransmitting.

Lecture19-Slide34

Congestion Collapse

…

…

…

…

LinkA LinkB

S1

S2

Lecture19-Slide35

Without Congestion Control

•  Congestion…–  Increasesdeliverylatency–  Increaseslossrate–  Increasesretransmissions,manyunnecessary– Wastescapacityontrafficthatisneverdelivered–  Increasescongestion,cyclecontinues…

Lecture19-Slide36

Congestion Collapse

•  ThishappenedtotheInternet(thenNSFnet)in1986.–  Ratedroppedfromablazing32kbpsto40bps–  Thishappenedonandofffortwoyears–  In1988,VanJacobsonpublished“CongestionAvoidanceandControl”

–  Thefix:sendersvoluntarilylimitsendingrate

Lecture19-Slide37

TCP Congestion Control: details

•  senderlimitstransmission:

•  cwndisdynamic,functionofperceivednetworkcongestion

TCPsendingrate:•  sendcwndbytes,waitRTT

forACKS,thensendmorebytes

lastbyteACKed

sent,not-yetACKed(“in-flight”)

lastbytesent

cwnd

cwnd ≤ LastByteSent- LastByteAcked

sendersequencenumberspace

~ ~ rate cwnd

RTT bytes/sec

Lecture19-Slide38

How should we set cwnd?

A.  Weshouldkeepraisingituntila“congestionevent”,thenbackoffslightlyuntilwenoticenomoreevents.

B.  Weshouldraiseituntila“congestionevent”,thengobackto0andstartraisingitagain.

C.  Weshouldraiseituntila“congestionevent”,thengobacktoamedianvalueandstartraisingitagain.

D.  Weshouldsendasfastaspossibleatalltimes.

Lecture19-Slide39

What is a “congestion event” from the perspective of a sender in TCP?

A.  Asegmentloss

B.  Receivingduplicateacknowledgement(s)

C.  Aretransmissiontimeoutfiring

D.  Somesubsetoftheabove

E.  Alloftheabove

Lecture19-Slide40

Whatwecareaboutissegmentloss,andbothBandCgiveusawaytoknowthatasegmentlosshasoccurred.

TCP Congestion Control Phases

•  Slowstart–  Senderhasnoideaofnetwork’scongestion–  Startconservatively,increaseratequickly

•  Congestionavoidance–  Increaserateslowly–  Backoffwhencongestionoccurs

•  HowmuchdependsonTCPversion

Lecture19-Slide41

TCP Slow Start

•  Whenconnectionbegins,increaserateexponentiallyuntilfirstlossevent:§  initiallycwnd=1MSS§  doublecwndeveryRTT§  donebyincrementingcwndforeveryACKreceived

•  Summary:initialrateisslowbutrampsupexponentiallyfast

•  Whendowestop?

Host A

one segment

RTT

Host B

time

two segments

four segments

Lecture19-Slide42

TCP Slow Start

•  Whendowestop?

•  Initially–  Onacongestionevent

•  Later–  Onacongestionevent– Whenwecrossapreviously-determinedthreshold

Host A

one segment

RTT

Host B

time

two segments

four segments

Lecture19-Slide43

TCP Congestion Avoidance

•  ssthresh:Thresholdwhereslowstartends–  initiallyunlimited

•  Incongestionavoidance,insteadofdoubling,increasecwndbyoneMSSeveryRTT.–  IncreasecwndbyMSS/cwndbytesforeachACK–  Backoffoncongestionevent

Lecture19-Slide44

We can determine that a packet was lost two different ways: via 3 duplicate ACKS, or via a timeout. We should…

A.  Treattheseeventsdifferently.

B.  Treattheseeventsthesame.

(Fordiscussion:Isoneoftheseeventsworsethantheother,ordotheyrepresentequallybadscenarios?Ifthey’renotequal,whichisworse?)

Lecture19-Slide45

Detecting, Reacting to Loss (Tahoe vs. Reno)

Lossindicatedbytimeout:TahoeandReno:

–  cwndsetto1MSS;–  windowthengrowsexponentially(asinslowstart)tothreshold,

–  thengrowslinearly

Lecture19-Slide46

Lossindicatedby3duplicateACKs:•  Tahoe:

–  cwndsetto1MSS;–  windowgrowsexponentially(asinslowstart)tothreshold

–  thengrowslinearly•  Reno

–  cwndiscutinhalfwindowthengrowslinearly

–  dupACKsindicatenetworkcapableofdeliveringsomesegments

Q:whenshouldtheexponentialincreaseswitchtolinear?

A:whencwndgetsto1/2ofitsvaluebeforetimeout.

Implementation:•  variablessthresh •  onlossevent,ssthreshis

setto1/2ofcwnd justbeforelossevent

TCP: switching from slow start to congestion avoidance

Lecture19-Slide47

Additive Increase, Multiplicative Decrease (AIMD)

•  approach:senderincreasestransmissionrate(windowsize),probingforusablebandwidth,untillossoccurs

•  additiveincrease:increasecwndby1MSS(MaximumSegmentSize)everyRTTuntillossdetected

•  multiplicativedecrease:cutcwndinhalfafterlosscwnd:

TC

P se

nder

co

nges

tion

win

dow

siz

e

AIMD saw tooth behavior: probing

for bandwidth

additively increase window size … …. until loss occurs (then cut window in half)

time Lecture19-Slide48

linkcapacity

Q:whenshouldtheexponentialincreaseswitchtolinear?

A:whencwndgetsto1/2ofitsvaluebeforetimeout.

Implementation:•  variablessthresh •  onlossevent,ssthreshis

setto1/2ofcwnd justbeforelossevent

TCP: switching from slow start to CA

Lecture19-Slide49

TCP Variants

•  Therearetonsofthem!

•  Tahoe,Reno,NewReno,Vegas,Hybla,BIC,CUBIC,Westwood,CompoundTCP,DCTCP,YeAH-TCP,…

•  Eachtweaksandadjuststheresponsetocongestion.

•  Whynotjustfindacwndvaluethatworks,andstickwithit?

Lecture19-Slide50

fairnessgoal:ifKTCPsessionssharesamebottlenecklinkofbandwidthR,eachshouldhaveaveragerateofR/K

TCP connection 1

bottleneck router capacity R

TCP Fairness

TCP connection 2

Lecture19-Slide51

TCP Fairness

Time

FlowRates

Lecture19-Slide52

Twocompetingsessions:•  additiveincreasegivesslopeof1,asthroughputincreases•  multiplicativedecrease,decreasesthroughputproportionally

Since TCP is fair, does this mean we no longer have to worry about bandwidth hogging?

A.  Yep,solvedit!

B.  No,wecanstillgamethesystem.

Ifyouwantedtocheattogetextratrafficthrough,howmightyoudoit?

Lecture19-Slide53

Fairness (more)

FairnessandUDP•  Multimediaappsoftendo

notuseTCP–  donotwantratethrottledbycongestioncontrol

•  InsteaduseUDP:–  sendaudio/videoatconstantrate,toleratepacketloss

Fairness,parallelTCPconnections•  Applicationcanopenmultiple

parallelconnectionsbetweentwohosts

•  Webbrowsersdothis•  e.g.,linkofrateRwith9

existingconnections:–  newappasksfor1TCP,getsrateR/10

–  newappasksfor11TCPs,getsR/2

Lecture19-Slide54

Summary

•  TCPhasmechanismstocontrolsendingrate:–  Flowcontrol:don’toverloadreceiver–  Congestioncontrol:don’toverloadnetwork

•  min(rwnd,cwnd)determineswindowsizeforTCPsegmentpipelining(typicallycwnd)

•  AIMD:additiveincrease,multiplicativedecrease

Lecture19-Slide55