• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
A Baker's dozen of TCP

A Baker's dozen of TCP



Linux Plumbers Conference discussion of TCP and Bufferbloat

Linux Plumbers Conference discussion of TCP and Bufferbloat



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Created congestion infrastructure Implemented (broke) several algorithms from papers Trying to stay CC neutral
  • How the Formula behaves Using the above formula with an MSS of 1460 bytes, we can plot the throughput as a function of loss and RTT as shown in the chart below for the range RTT from 0.25ms (typical LAN RTTs) to 650ms (typical geostationary satellite speed). If one takes the speed of light in fibre as roughly 0.6c or msec = alpha * 100km where empirically alpha ~0.4 accounts for non direct paths, router delays etc. then the distances corresponding to 10, 50, 100, 250, 500, 1000, 2500, 5000, 10000, 25000km are 0.25, 1.25, 2.5, 6.25, 12.5, 25, 62.5, 125, 250, 625 msec.

A Baker's dozen of TCP A Baker's dozen of TCP Presentation Transcript

  • Congestion Control vs Bufferbloat Stephen Hemminger shemminger@vyatta.com7 Sept 2011
  • AgendaWhat is TCP congestion control?What are some of the alternatives?Problems in congestion controlSpeculation
  • TCP congestion controlis the result of years ofresearch.
  • AcronymnsRTT → Round Trip TimeBDP → Bandwidth Delay ProductAIMD → Additive Increase Multiplicative Decrease
  • Goals of Congestion control?UtilizationFairnessAdaptability What about latency?
  • Evolution of TCP Congestion Control
  • TCP Congestion Control TypesLoss based Delay based RENO Vegas BIC, CUBIC HTCP Hybrid Illinois Veno Yeah
  • Traditional TCP (Reno) http://www.deneholme.net/tom/
  • Whats wrong with RENO? Rate Recovery Time @ 200ms RTT1Mbps 1.7s10Mbps 10.7s100Mbps 2min1Gbps 28min10Gbp 4 hrs 43min http://www.deneholme.net/tom/
  • http://www.slac.stanford.edu/comp/net/wan-mon/thru-vs-loss.html
  • Title:cubic2.epsCreator:gnuplot 4.0 patchlevel 0CreationDate:Sun Jul 29 00:11:16 2007 King of the hill problem
  • HTCPUse Epoch as estimate of BDP
  • Performance with small QueuesTitle:util.epsCreator:gnuplot 4.0 patchlevel 0CreationDate:Tue Jul 31 13:59:03 2007
  • Vegas
  • Delay based IssuesSample size Delayed ACK Short lived flowsRTT Data quality Packet trains Timer resolutionNot aggressive Works great in “well behaved” network
  • General IssuesMiddleboxes: broken, cheatingMost connections too short No persistenceSender chooses, receiver loses
  • CC Rap SheetReno → Too slow to recoverBIC → Unfair at short RTT or low speedCUBIC → Slow to convergeHTCP → Slower with small queuesVegas → Too wimpy and sensitiveHybrid → Reverts to delay based
  • IdeasResearch Hybrid congestion control Refine delay based portion Detect mega queues Best CC discoveryTesting More real world testing Googlish – random testing