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 <[email protected]> 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 <david.hayes at ieee.org> and > Grenville Armitage <garmitage at swin edu au> > 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 > > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
