Re: [Bloat] Solving bufferbloat with TCP using packet delay

[Michael Richardson <mcr@sandelman.ca>]

>>>>> "Steffan" == Steffan Norberhuis <steffan@norberhuis.nl> writes:
    Steffan> But hardly any talk about solving buffer bloat by using a
    Steffan> TCP variant that that uses packet delay as a way to
    Steffan> determine the send rate. We did not come across any papers
    Steffan> that argue that these TCP variants are not a good
    Steffan> solution. We went to several professors with the question
    Steffan> if TCP using packet delay was not a good solution. But we
    Steffan> did not get a concise answer.  In our view AQM needs alot
    Steffan> of new hardware to be implemented and a TCP variant would
    Steffan> perhaps be easier to implement and is also able to solve
    Steffan> bufferbloat.

I'm not going to argue the protocol at all (because I don't know the
details of what you propose), but rather the economics.

1) Deploying a new TCP is a multi-decade effort.
  Sure, a new Linux kernel with a new default might have significant (80%)
  data centre presence is 12 months or so, and a really smart change to
  the protocol might work even when only one end is upgraded.  
  However, significant numbers of systems out there will essentially
  never get a firmware patch, and will continue to operate until they
  wear out.  I'm thinking not just of desktop computers in public
  libraries, but media devices like Nintendo Wii. (mine runs Netflix)

  Most of the owners of these devices have little knowledge, and little
  ability to fix them, or even know that the device needs to be fixed.
  As long as there even a few bad senders, and there are excessive
  buffers out there, the bad senders will fill the buffers and ruin it
  for the rest of us.  Many excessive buffers are unseen at layer 3.

2) fixing routers is not as difficult as you think.
  First, most equipment gets replaced and/or redeployed (perhaps thanks
  to an ebay event) every three years or so. 

  Second, most equipment is field upgradable, and even a lot of the 10G
  forwarding engines have upgradeable firmware to implement things like
  queues.  

  Third, and most importantly, in markets which are not distorted by
  idiotic regulation, ISPs get paid based upon their performance.
  Bufferbloat, once people can measure it, will be impact the bottom
  line of an ISP, particularly those that are reaching into the business
  data/voip pie.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [