From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu1sys200aog114.obsmtp.com (eu1sys200aog114.obsmtp.com [207.126.144.137]) by huchra.bufferbloat.net (Postfix) with SMTP id BB4BC21F182 for ; Tue, 9 Jul 2013 14:38:11 -0700 (PDT) Received: from mail-lb0-f181.google.com ([209.85.217.181]) (using TLSv1) by eu1sys200aob114.postini.com ([207.126.147.11]) with SMTP ID DSNKUdyCwnXrtpsjXxTjiaEmIVKWCZChZ5hH@postini.com; Tue, 09 Jul 2013 21:38:11 UTC Received: by mail-lb0-f181.google.com with SMTP id w10so5053793lbi.40 for ; Tue, 09 Jul 2013 14:38:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-gm-message-state; bh=tu2ipqa49Qt1qswHpdWccIvxl4aNFf08LEoeD8lIo0k=; b=h/UkWguwL7OSQ16pislAVytip198ziyGoSFRT8aGXpNuopLW5dfd/A/NrrOdwiHilS 33fuYC60tLgpIYC0F3wSVQuz1eQ5FLo7wCobyazV47kb+UqQU9CVr9V8lfrdoV8q+jiP 9e3JBI0JzpXajhPYkkDxhV7xP71D0kASy4Y6TMfNfzqSHcFbHaKDZbBHMumT+gpC6GWa Kvo0GteqRC/6uB/kNNYYUVCw7QyBSQx4r+4mo1ldlOxS2nHbO7ZHt80AhhUQPv9wSTyn QEzNhlmohLMW5keqZBb1eucgk0yA+koBo9XrXmVMmZWJlQ9LgeLoN4CtnnraKA6RSwea 4jKA== X-Received: by 10.152.28.66 with SMTP id z2mr13513217lag.5.1373405890578; Tue, 09 Jul 2013 14:38:10 -0700 (PDT) X-Received: by 10.152.28.66 with SMTP id z2mr13513212lag.5.1373405890276; Tue, 09 Jul 2013 14:38:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.9.33 with HTTP; Tue, 9 Jul 2013 14:37:50 -0700 (PDT) In-Reply-To: <20130709193309.GA1272@order.stressinduktion.org> References: <1373397048.4979.187.camel@edumazet-glaptop> <20130709193309.GA1272@order.stressinduktion.org> From: Jaume Barcelo Date: Tue, 9 Jul 2013 23:37:50 +0200 Message-ID: Cc: bloat@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmWJ1imHx9mUr+gzvu5JXIppvtYf3SxtscXURUw50lPt5QoJlih9u0IQDWRIKNk6wPeJUPem6mtJ10B6TY8s7kI5dknMQy3hAiimWQkE1dFCLQt9lKo28L8shRQf6bZA6Q5UXcj8m9dvapDOxKE7/RZd8GiwexCnCNHRiIMckeau7SsiN0= Subject: Re: [Bloat] sweet tcp 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: Tue, 09 Jul 2013 21:38:12 -0000 Thanks for your insights :) I have to read that paper by Hayes and Armitage. It seems very promising. Cheers On Tue, Jul 9, 2013 at 9:33 PM, Hannes Frederic Sowa wrote: > On Tue, Jul 09, 2013 at 12:10:48PM -0700, Eric Dumazet wrote: >> On Tue, 2013-07-09 at 19:38 +0200, Jaume Barcelo wrote: >> > Hi, >> > >> > I was explaining the bufferbloat problem to some undergrad students >> > showing them the "Bufferbloat: Dark Buffers in the Internet" paper. I >> > asked them to find a solution for the problem and someone pointed at >> > Fig. 1 and said "That's easy. All you have to do is to operate in the >> > sweet point where the throughput is maximum and the delay is minimum". >> > >> > It seemed to me that it was a good idea and I tried to think a way to >> > force TCP to operate close to the optimal point. The goal is to >> > increase the congestion window until it is larger than the optimal >> > one. At that point, start decreasing the congestion window until is >> > lower than the optimal point. >> > >> > To be more specific, TCP would be at any time increasing or decreasing >> > the congestion window. In other words, it will be moving in one >> > direction (right or left) along the x axis of Fig. 1 of Getty's paper. >> > Each RTT, the performance is measured in terms of delay and >> > throughput. If there is a performance improvement, we keep moving in >> > the same direction. If there is a performance loss, we change the >> > direction. >> > >> > I tried to explain the algorithm here: >> > https://github.com/jbarcelo/sweet-tcp-paper/blob/master/document.pdf?raw=true >> > >> > I am not an expert on TCP, so I decided to share it with this list to >> > get some expert opinions. >> >> Are you familiar with existing delay based algorithms ? >> >> A known one is TCP Vegas. >> >> Problem is that it would work well only if all flows would use it. >> >> Alas, lot of flows (or non flows traffic) will still use Reno/cubic (or >> no congestion at all) and they will clamp flows that are willing to >> reduce delays. >> >> So that's definitely not 'easy' ... > > FreeBSD recently imported a new CC algorithm. From the commit msg[0]: > > Import an implementation of the CAIA Delay-Gradient (CDG) congestion control > algorithm, which is based on the 2011 v0.1 patch release and described in the > paper "Revisiting TCP Congestion Control using Delay Gradients" by David Hayes > and Grenville Armitage. It is implemented as a kernel module compatible with the > modular congestion control framework. > > CDG is a hybrid congestion control algorithm which reacts to both packet loss > and inferred queuing delay. It attempts to operate as a delay-based algorithm > where possible, but utilises heuristics to detect loss-based TCP cross traffic > and will compete effectively as required. CDG is therefore incrementally > deployable and suitable for use on shared networks. > > In collaboration with: David Hayes and > Grenville Armitage > MFC after: 4 days > Sponsored by: Cisco University Research Program and FreeBSD Foundation > > I had no time to play with it myself, yet. > > [0] http://svnweb.freebsd.org/base/head/sys/netinet/cc/cc_cdg.c?revision=252504&view=markup > >