From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by huchra.bufferbloat.net (Postfix) with ESMTP id 94B3421F0F2 for ; Wed, 20 Mar 2013 09:35:51 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id BBC192016D; Wed, 20 Mar 2013 12:44:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5F6DB63860; Wed, 20 Mar 2013 12:35:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4D32363827; Wed, 20 Mar 2013 12:35:42 -0400 (EDT) From: Michael Richardson To: Steffan Norberhuis In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Solving bufferbloat with TCP using packet delay X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:35:52 -0000 >>>>> "Steffan" == Steffan Norberhuis 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 [