Re: Congestion control as a hot topic in IETF

On Mar 8, 2013, at 1:09 AM, Emmanuel Lochin wrote:

> On 07/03/2013 15:28, Barath Raghavan wrote:
>> Just to weigh in on our work on Decongestion Control -- Jon is right that it wasn't about making a congestion-free Internet, but rather about making the case that it's possible for an Internet-like network to achieve high goodput despite extreme packet loss.
>> 
>> We did significant followup work beyond our 2006 HotNets paper, but it was never published.  A few of the things we found:
>> 
>> 1. The notion of dead packets, per Patterns of Congestion Collapse (Kelly, Floyd, and Shenker), is key when you have a protocol that induces heavy loss.
>> 
>> 2. That a refined notion of dead packets, which we called zombie packets, reflected the true loss of capacity when using Decongestion Control.  The idea is that if an eventually-dropped packet is wasting network resources that could have been used by packets that would have contributed to overall goodput, then the packet is a zombie packet.
>> 
>> 3. For networks structured like those of backbone ISPs (circa 2008), firehose Decongestion Control, in which senders send as fast as possible, would result in poor network-wide goodput due to high zombie packet rates.  However, another approach, ratio Decongestion Control, in which senders send at a fixed fraction above their goodput, achieved near optimal goodput (we used 20% -- i.e., if a flow is getting 10Mbps goodput, send at 12Mbps).  This latter approach is aligned with a sender's incentives (i.e., there's no reason for them to send faster than their goodput), and yet also yields good performance from the network's perspective.
> 
> Hi Barath,
> 
> Did you use Achoo for your experiments or did you slide to another mechanism? We've developed our own ns-2 Achoo prototype to compare with our Tetrys proposal and noticed some limitation of Achoo when the RTT increases (might be due to the fact that Achoo remains a block erasure coding scheme). If you have a pseudo code or any prototype of Achoo, we will be interested in to allow a fair comparison.
> 
> Emmanuel


We used a few different implementations over the lifetime of the project, but this was years ago so unfortunately I'm not sure I have anything to share.  There were two distinct focuses to our work: a) the impact on the network of large scale use of Decongestion Control and b) the design and implementation of the protocol itself.  For the former, John McCullough built a flow-based simulator (to try out larger topologies than ns2 could handle).  For the latter I built a Linux user-level implementation (that used library interposition to make TCP-based apps use Decongestion), and later we built a simplified ns2 implementation.

You're right that there is a potential issue with the naive scheme as RTT increases -- this can be largely though not completely mitigated by a) using the ratio send approach rather than firehose, b) SACKs (ours were a bit vector of blocks received), and c) overlapping the sending of coding windows, scaling one down in rate while scaling the next up (we only partially explored this).

-Barath