[Bloat] Solving bufferbloat with TCP using packet delay
Michael Richardson
mcr at sandelman.ca
Wed Mar 20 12:35:42 EDT 2013
>>>>> "Steffan" == Steffan Norberhuis <steffan at 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 at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
More information about the Bloat
mailing list