From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8D4A921F1D7 for ; Thu, 21 Mar 2013 01:26:05 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from ) id 1UIaos-00062u-2P; Thu, 21 Mar 2013 09:25:54 +0100 Date: Thu, 21 Mar 2013 09:26:32 +0100 From: Hagen Paul Pfeifer To: Stephen Hemminger Message-ID: <20130321082631.GA16186@localhost.localdomain> References: <514A1A60.2090006@swin.edu.au> <20130320161622.25fbd642@nehalam.linuxnetplumber.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130320161622.25fbd642@nehalam.linuxnetplumber.net> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 21 Mar 2013 08:26:06 -0000 * Stephen Hemminger | 2013-03-20 16:16:22 [-0700]: >Everyone has to go through the phase of thinking > "it can't be that hard, I can invent a better TCP congestion algorithm" >But it is hard, and the delay based algorithms are fundamentally >flawed because they see reverse path delay and cross traffic as false >positives. The hybrid ones all fall back to loss under "interesting >times" so they really don't buy much. > >Really not convinced that Bufferbloat will be solved by TCP. >You can make a TCP algorithm that causes worse latency than Cubic or Reno >very easily. But doing better is hard, especially since TCP really >can't assume much about its underlying network. There maybe random >delays and packet loss (wireless), there maybe spikes in RTT and >sessions maybe long or short lived. And you can't assume the whole >world is running your algorithm. +1 plus: bufferbloat is a queue problem (say link layer), the right way is to address the problem at that level. Sure, the network and transport layer is involved and a key factor. But a pure (probably delay based) TCP congestion control based solution do not solve the problem: we also have to deal with (greedy) UDP (in a ideal world DCCP) applications as well. Imagine a pure UDP setup: one greedy UDP application (media stream) and now try to ping a host. You will experience the same bufferbloat problems. Hagen -- http://protocollabs.com