From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-da0-x232.google.com (mail-da0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 423FE21F1B5 for ; Wed, 20 Mar 2013 16:16:29 -0700 (PDT) Received: by mail-da0-f50.google.com with SMTP id t1so1265163dae.37 for ; Wed, 20 Mar 2013 16:16:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=i9UHydpUV0UsTWL63SaWbwKhxLdqrTLywkNp7rP7uYo=; b=KYKjO9NMNDiOPthqF9Ehc6ZE3CmH9FBrkuLNcpHt9I9XWXM4eJ2WX9cuV/OTj4CUHU u16jGxme9iWN8Jf9xlJazTmGHn1QAvJKwrDaXgtxja4dwtaJdoOOvU4yyC+0C8F/45fo xO8wyip+LLjaz7wG/MBb9skzqujEpuQ8KmYFApHT2b/1MZ0tUcDlNryhn1LeZe71mLfH /gmhODTUcY5YxC7Yf4wgGP4j1d3c57O8VE6qobmaF8kEyeyumTVAKm2ITrxWNJX/dpTg jCjly2kz9/fo2LLi9lEBL02UrJX6sPwq5WmBgQaO8B4mZXfJiP5VfOQYpDd/2X0XDmpJ gkzQ== X-Received: by 10.68.252.39 with SMTP id zp7mr12009050pbc.184.1363821388351; Wed, 20 Mar 2013 16:16:28 -0700 (PDT) Received: from nehalam.linuxnetplumber.net (static-50-53-71-109.bvtn.or.frontiernet.net. [50.53.71.109]) by mx.google.com with ESMTPS id 1sm3622027pba.32.2013.03.20.16.16.27 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 20 Mar 2013 16:16:27 -0700 (PDT) Date: Wed, 20 Mar 2013 16:16:22 -0700 From: Stephen Hemminger To: grenville armitage Message-ID: <20130320161622.25fbd642@nehalam.linuxnetplumber.net> In-Reply-To: <514A1A60.2090006@swin.edu.au> References: <514A1A60.2090006@swin.edu.au> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnZ5S/KKxVJGLrzCjIFLsql5WM9fn8ew2sc4qIeFYbZaN1xhMZUfi1y10xnrm1Pz0jIrfWg 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 23:16:29 -0000 On Thu, 21 Mar 2013 07:21:52 +1100 grenville armitage wrote: > > > On 03/21/2013 02:36, Steffan Norberhuis wrote: > > Hello Everyone, > > > > For a project for the Delft Technical University myself and 3 > > students are writing a review paper on the buffer bloat problem and > > its possible solutions. > > My colleagues have been dabbling with delay-based CC algorithms, > with FreeBSD implementations (http://caia.swin.edu.au/urp/newtcp/) > if that's of any interest. > > Some thoughts: > > - When delay-based TCPs share bottlenecks with loss-based TCPs, > the delay-based TCPs are punished. Hard. They back-off, > as queuing delay builds, while the loss-based flow(s) > blissfully continue to push the queue to full (drop). > Everyone sharing the bottleneck sees latency fluctuations, > bounded by the bottleneck queue's effective 'length' (set > by physical RAM limits or operator-configurable threshold). > > - The previous point suggests perhaps a hybrid TCP which uses > delay-based control, but switches (briefly) to loss-based > control if it detects the bottleneck queue is being > hammered by other, loss-based TCP flows. Challenging > questions arise as to what triggers switching between > delay-based and loss-based modes. > > - Reducing a buffer's length requires meddling with the > bottleneck(s) (new firmware or new devices). Deploying > delay-based TCPs requires meddling with endpoints (OS > upgrade/patch). Many more of the latter than the former. > > - But yes, in self-contained networks where the end hosts can all > be told to run a delay-based CC algorithm, delay-based CC > can mitigate the impact of bloated buffers in your bottleneck > network devices. Such homogeneous environments do exist, but > the Internet is quite different. > > - Alternatively, if one could classify delay-based CC flows into one > queue and loss-based CC flows into another queue at each > bottleneck, the first point above might not be such a problem. > I also want a pink pony ;) (Of course, once we're considering > tweak the bottlenecks with classifiers and multiple queues, > might as continue the surgery and reduce the bloated buffers too.) 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.