Review:!Congestion!Control! What!gives!rise!to!congestion?!

Advanced! Computer Networks

•  packets!arriving!faster!than!a!router!can!forward!them!

Why!is!congestion!bad?! •  routers!queue!packets!that!cannot!be!served!immediately!

[H96]!Hoe,!“Improving!the!Start3up!Behavior!of!a! Congestion!Control!Scheme!for!TCP,”!Proc.&of&ACM& SIGCOMM&'96,!26(4):2703280,!Oct.!1996!

•  if!queue!overflows,!packets!are!dropped! •  queued!packets!experience!delay! packet!being! transmitted!(delay)!

A 10 Mbps!

B

10 Mbps!

10 Mbps!

packets!queued!(delay)! free!(available)!buffers:!arriving!packets!! dropped!(loss)!if!no!free!buffers!

Congestion!and!TCP! If!queueing!delay!>!RTO,!sender!retransmits!packets,! adding!to!congestion! Dropped!packets!also!lead!to!more!retransmissions! If!unchecked,!could!result!in!congestion.collapse. When!packet!dropped,!any!“upstream”!transmission! capacity!used!for!that!packet!was!wasted! What!prevention?! Constraints:! •  decentralized!control! •  unlike!routing,!no!local!reaction!at!routers!

(beyond!buffering!and!dropping)! •  long!feedback!time! •  dynamic!network!condition:!connections!come!and!go!

Congestion!Control! How!can!senders!prevent/avoid!congestion?! •  senders!must!know!system!capacity! •  senders!must!try!to!operate!system!below!capacity!

System!Capacity!

Discovering!System!Capacity! How!do!senders!know!where!the!“knee”!is!and! how!do!they!know!when!the!system!has! “gone!off!the!cliff”?!

Load!vs.!throughput:! •  congestion!avoidance:!

operate!system!at!“knee”! •  congestion!control:! operate!system!near!“cliff”! !

What!TCP!and!other!congestion!control! schemes!do:! •  probe!for!point!right!before!cliff!(“pipe!size”)! •  slow!down!transmission!on!detecting!cliff!!(congestion)!

How!do!senders!discover!system! capacity!and!control!congestion?! •  senders!must!detect!congestion! •  senders!must!slow!down!transmission!

Jain et al.!

up!to!a!threshold!(“slow!start”)! •  slower!probing!after!threshold!! is!reached!(“linear!increase”)!

Why!not!send!a!large!amount!! of!data!and!then!slow!down?!

TCP!Slow3start!

congestion window (cwnd)

•  fast!probing!initially,!!

Jain et al.! packet! dropped!

TCP Tahoe!

Self3Clocking!TCP!

•  double!cwnd!every!RTT!

(every!ACK!received)!   initial!rate!is!slow!but!ramps!up! exponentially!fast!

Host!A!

RTT!

When!connection!begins,!increase! rate!exponentially!until!first!loss! event:!

ACK!is!used!for!flow!control!and!retransmission!request! TCP!also!uses!ACK!for!congestion!control!

Host!B! one!segmen

t!

two!segmen

ts!

four!segm ents!

time!

Jacobson and Karels!

TCP!follows!a!so3called!“Law!of!Packet!Conservation”:! Do!not!inject!a!new!packet!into!the!network!until!a! resident!departs!(ACK!received)! Since!packet!transmission!is!timed!by!receipt!of!ACK,! TCP!is!said!to!be!self3clocking!

TCP!Congestion!Control!

TCP!Congestion!Control! packet! dropped!

•  cwnd:!congestion!window!

Sender’s!send!window!(wnd)!is:!!

wnd!= MIN(rwnd, floor(cwnd)),! •  where!rwnd:!receiver’s!advertised!window! •  initially!set!cwnd!to!1! •  increase!cwnd!if!there’s!no!congestion! •  on!congestion,!! Questions:! decrease!cwnd! 1.  How!to!determine!that!there’s!no!congestion?! 2.  By!how!much!do!we!increase!cwnd?! 3.  How!to!detect!congestion?!! 4.  By!how!much!must!cwnd!be!decreased?!

Increasing!cwnd

(initially!set!to!1)! •  ssthresh:!threshold!for!! slowing!down!cwnd!increase!! (initially!set!to!64KB)!

congestion window (cwnd)

Variables:!

Sender!maintains!a!congestion!window!(cwnd)! Sender!does!congestion!control!! by!expanding!and!shrinking!cwnd

TCP Tahoe!

Recall!that!TCP!uses!cumulative!ACK:! •  ACKs!the!last3byte!received!in!order! •  tells!sender!the!next3expected!seq#! •  subsequent!out3of3order!packets!generate!the!same!

cumulative!ACK!

TCP!Slow!Start!Example

Probing!the!“pipe3size”!(system!capacity)!in!two!phases:! 1.  slow3start:!exponential!increase! while (cwnd ssthresh) { cwnd += 1 } for every cwnd-full of ACKs! incrementally:!cwnd += 1/floor(cwnd)!for!every!ACK!

Jacobson & Karels!

Stevens!

Decreasing!cwnd

Fast!Retransmit Motivation:!waiting!for!RTO!is!too!long!

How!to!detect!congestion?! Interpret!packet!loss!as!congestion!signal!

TCP!Tahoe!does!fast!retransmit:!

!

•  with!cumulative!ACK,!receipt!of!packets!following! a!lost!packet!cause!duplicate!ACKs!to!be!returned!

When!is!packet!considered!lost?!

•  interpret!3!duplicate!ACKs!as!an!implicit!NAK!

•  RTO!timer!goes!off!

•  retransmit!upon!receiving!3!dupACKs,!i.e.,!on!receipt! of!the!4th!ACK!with!the!same!seq#,!retransmit!segment!

•  receipt!of!3!duplicate!ACKs!(fast!retransmit)!

•  why!3,!instead!of!2!or!4,!dupACKs?!

With!fast!retransmit,!TCP!can!retransmit! after!1!RTT!instead!of!waiting!for!RTO!

Fast!Retransmit!Example

TCP!Congestion!Recovery Once!congestion!is!detected,! •  by!how!much!do!we!decrease!cwnd?! •  how!do!we!recover!from!congestion?! •  which!packet(s)!do!we!retransmit?! •  how!do!we!increase!cwnd!again?!

•  retransmit!using!Go3Back3N! •  reset!cwnd!to!1!

sent segments! 3 dupACKs! ACKed seq#!

[H96]!

retransmit on! 4th dupACK!

•  restart!slow3start! time (secs)!

congestion window (cwnd)

rwnd!

! First,!reset!ssthresh = cwnd/2 TCP!Tahoe:!

packet! dropped!

TCP Tahoe!

TCP!Reno!and!Fast!Recovery cwnd!re3opening!and!retransmission!of!lost!! packets!regulated!by!returning!ACKs! •  duplicate!ACK!doesn’t!grow!cwnd,!so!TCP!must!wait!at!least!1!RTT!for!

Fast!Recovery 1.  on!congestion,!retransmit!lost!segment,!

set!ssthresh = cwnd/2

2.  remember!highest!seq#!sent,!

fast!retransmitted!packet!to!cause!a!non3duplicated!ACK!to!be!returned!

•  if!RTT!is!large,!Tahoe!re3grows!cwnd!very!slowly! 3. 

TCP!Reno!does!fast!recovery:! •  current!value!of!cwnd!is!the!estimated!system!capacity! •  after!congestion!is!detected,!want!to!continue!! transmitting!at!half!the!estimated!capacity,!how?! •  each!returning!ACK!signals!that!an!outstanding!! packet!has!left!the!network! •  don’t!send!any!new!packet!until!half!of!the!! expected!number!of!ACKs!have!returned!

Summary:!TCP!Congestion!Control! •  when!cwnd!is!below!ssthresh,! sender!in!slow3start!phase,!window!grows!exponentially!

4. 

5.  6.  7. 

snd_high;! and!remember!current!cwnd,!! let’s!call!it!pipe decrease!cwnd!by!half! increment!cwnd!for!every!returning! dupACK,!incl.!the!3!used!for!fast! retransmit! don’t!send!any!packets!while! cwnd < pipe exit!fast3recovery!when!a!non3dup!ACK! is!received!(may!be!< snd_high)! set!cwnd = ssthresh + 1! and!resume!linear!increase! cwnd:!number!of! bytes!unACKed!

Summary:!! Factors!in!TCP!Performance •  RTT!estimate!

•  when!cwnd!is!above!ssthresh,!sender!is!in! congestion3avoidance!phase,!window!grows!linearly!

•  RTO!computation!

•  when!a!3!dupACKs!received,!ssthresh!set!to! cwnd/2!and!cwnd!set!to!new!ssthresh

•  receiver’s!window!(rwnd)!

•  if!more!dupACKs!return,!do!fast!recovery!

•  slow3start!threshold!(ssthresh)!

•  else!when!RTO!occurs,!ssthresh!set!to! cwnd/2!and!cwnd!is!set!to!1!MSS!

•  fast!retransmit!

•  sender’s!sliding!window!(wnd)! •  congestion!window!(cwnd)!

•  fast!recovery!

Summary!of!TCP!Variants Original!TCP:!!

•  loss!recovery!depends!on!RTO!

TCP!Tahoe:! •  slow3start!and!linear!increase! •  3!dupACKs!as!loss!signal,!but!restart!slow3start!after!fast!retransmit!

Reno!Redux Reno!works!fine!for!single3 packet!losses,!but!struggles! with!multiple!losses,!most! pronounced!at!start!up!

TCP!Reno:! •  fast!recovery,!i.e.,!consume!half!returning!dupACKs!before!transmitting!one! new!packet!for!each!additional!returning!dupACKs! •  on!receiving!a!non3dupACK,!resume!linear3increase!from!half!old!cwnd!value!

TCP!New!Reno![H96]:! •  partial!ACK:!a!non3dupACK!that!is!
Reno!Start!Up!Behavior!

cwnd: number of bytes unACKed!

Failure!of!Fast!Retransmit! Multiple!packet!losses!scenario:!!

Initial!ssthresh!too! large,!leading!to!multiple! lost!packets!

Retransmissions!of!received!packets! (due!to!Go3Back3N)!elicit!more!than!3! dupACKs!leading!to!false!fast!retransmit!

• rwnd!=!50,!packets!0!to!100!sent!(assume!1!seq#/pkt)! • all!odd!seq#s!between!50!and!62!lost! • 3!dupACKs!for!51!received,! triggered!by!50,!52,!54,!56!! • packet!51!retransmitted! • more!dupACKs!asking!for!51" RTO! triggered!by!receipt!of!58-100! • received!ACK!for!52,!asking!for!53! partial!ACK! • no!other!packet!sent!because! cwnd=rwnd!already!

Why!do!we!care?! Transfer!sizes!are!small!

Lost!self3clocking!by!ACKs!! Must!wait!for!timeout!before!retransmitting!packet!53!!

Fast!retransmit!alone! doesn’t!allow!TCP!to! recover!from!multiple!losses!

Must rely on RTO for retransmission!

1!RTT!

Fast!Retransmit!Phase!

Fast!Retransmit!Phase!

Let!snd_high:!the!highest!seq#!outstanding!

Partial!ACK:!

Continue!re3transmitting!lost!packets!every!RTT!upon! receipt!of!partial!ACKs!(ACKed!seq#!
•  an!ACK!that!acknowledges!some!

but!not!all!outstanding!packets! •  brings!Reno!out!of!fast!recovery! •  stalls!self3clocking!by!ACKs!

2!retransmission!alternatives:!

! New!Reno’s!fast!retransmit!phase:!

•  until!all!packets!sent!out!before!fast!retransmit!have!been!

acknowledged,!continue!retransmitting!lost!packets!every! RTT,!upon!receipt!of!partial!ACKs! •  do!not!let!dupACKs!initiate!another!fast!retransmit!while!in! fast!retransmit!phase!to!prevent!false!fast!retransmit!

Fast!Retransmit! Only!vs.! Fast!Retransmit! Phase!

End!fast!retransmit!phase! when!snd_high!is!acknowledged!

1!RTT!

Send!one!new!packet!beyond!snd_high!for!every!2!dup! ACKs:!to!continue!self3clocking!by!ACKs!(not!implemented)!

[HoeTR95]!

Multiple!Losses! Main!culprit:!initial!ssthresh!too! large,!leading!to!multiple!lost!packets! 1!RTT!

Want:!an!initial!ssthresh!that! matches!the!knee!capacity!of!the!pipe!

RTO!

While!in!fast!retransmit! phase,!retransmit!packets! using!slow!start! End!fast!retransmit!phase! when!snd_high!is! acknowledged! ! Note:!timing!of!the!two! experiments!are!not!of!the! same!scale!

1.  retransmit!packets!using!slow! start,!increasing!cwnd!up!to! half!of!old!cwnd ![H96] 2.  retransmit!one!lost!packet! every!RTT! ![H95]!

Solution:! Probe!the!network!for!bandwidth×delay!

Jain et al.!

• delay:!RTT!between!packet!and!ACK!(use!SYN!packet)! • bottleneck!bandwidth:!1/interarrival!of!2!closely!spaced!ACKs!! RTO!

1!RTT!

1!RTT!

Potential!issues:!ACK!dilation! 1!RTT!

Effect!of!Asymmetry!on!TCP

Effect!of!Asymmetry!on!TCP

Example!of!asymmetric!networks:! •  cable!modem:!10!Mbps!down,!512!Kbps!up! •  ADSL:!8!Mbps!down,!1!Mbps!up! •  etc.! !

Fine!for!web!surfing,!but!transfer!can!be!slowed! down!by!bandwidth!asymmetry.!!How?! ! Slower!bandwidth!on!reverse!path!stretches!out! ACKs!(ACK!dilation),!resulting!in!slower!throughput! on!the!forward!path!

TCP!SACK Selective!ACK!(SACK)!gives!sender!a!better!idea!of!which! packets!have!been!successfully!delivered!

Maximum!transmission!speed!determined!by! “normalized!bandwidth!ratio”:! ! forward bandwidth/datasize ! reverse bandwidth/ACKsize ! For!example:! •  10!Mbps!forward/100!Kbps!reverse!=!bandwidth!ratio!of!100! •  1!KB!data!packet/403byte!ACK!=!data/ACK!ratio!of!25! •  normalized!bandwidth!ratio!= 100/25 = 4!   if!there!are!more!than!1!ACK!for!every!4!packets,!reverse!

bottleneck!link!will!be!saturated!before!forward!bottleneck!is!

TCP!SACK!Example Pkts: 1 2 3 4 5 6 7 8 9 10 11 12 13 lost

TCP!SACK!does!Selective!Repeat!instead!of!Go3Back3N! Added!2!TCP!options:!

SACK for 13:

1.  SACK!Permitted!(option!4):!!

carried!only!by!SYN!packets! 2.  SACK!Option!(option!5):!! NAK!for!missing!segments!

Decouples!when!and!how! much!to!send!(congestion! control)!from!which!to!send! (loss!recovery)!

dst port

src port

last to arrive After 5, 6 arrive, SACK for 6:

seq # cumulative ack 1

hl

Usual TCP header

rwin

checksum

5

0 first next

next

next first next

9

11 14 7 9

11 14

cumulative ack

len must be most recently received fragment

first

first

5

urgent

SACK Option

sack