Subject: [ledbat] Ledbat variants

From: Murari Sridharan <[email-masked]>
Date: Fri, 26 Jun 2009 08:46:32 -0700

All,

There is a need for ledbat type CC as an alternative congestion control on TCP. The difference here is that it has to work within TCP as a form of congestion control (or flow control). There are several applications (not including P2P apps) that require this behavior. The main differences are a) there is no additional framing other than TCP framing b) it should be incrementally deployable, that is only one end (sender or receiver) needs to change as you may not always have control over both ends c) given it would work within TCP it would react to RTT (as opposed to one-way delay) and as a result will be affected by reverse path congestion. Even though one of the ledbat requirements is to saturate the bottleneck there are applications that are perfectly fine without saturating the link as long as some basic guarantees on flow completion.

In our charter we have text that says applications of this algorithm to existing transport protocols is expected to occur in WGs that maintain those protocols be it TCP, DCCP or SCTP. Does that mean a ledbat variant such as above gets discussed in TCPM or ICCRG or should we take a stab at it here and move it to ICCRG at some later point?

Thanks

---

From: Lars Eggert <[email-masked]>
Date: Mon, 29 Jun 2009 10:42:07 +0300

Hi,

On 2009-6-26, at 18:46, Murari Sridharan wrote:
> In our charter we have text that says applications of this algorithm  
> to existing transport protocols is expected to occur in WGs that  
> maintain those protocols be it TCP, DCCP or SCTP. Does that mean a  
> ledbat variant such as above gets discussed in TCPM or ICCRG or  
> should we take a stab at it here and move it to ICCRG at some later  
> point?

the - maybe naive - assumption behind the charter text was that LEDBAT  
would produce one experimental CC algorithm that could then be applied  
to different transport protocols in whatever WG maintains those  
protocols.

The issue you raise - what if "the" LEDBAT algorithm requires input or  
behavior that one of the protocols can't provide? - is interesting,  
and I don't think we thought about this case at chartering time.

My personal preference would be to still try and come up with one  
simple algorithm that can actually be applied to several of our  
transport protocols. The reason is that it'll be difficult enough to  
model, simulate and experimentally vet this one algorithm, and  
multiplying this effort will require many more cycles. On the other  
hand, if someone came up with a really good LBE algorithm that for  
example only worked for DCCP, I don't see why we wouldn't want to  
publish this in some form (in cooperation with the DCCP WG, in this  
example case.) But I don't think we should fragment the effort into  
per-protocol algorithms unless we really need to.

On 2009-6-26, at 18:46, Murari Sridharan wrote:
> There is a need for ledbat type CC as an alternative congestion  
> control on TCP.

True. I may be naive again, but the draft-shalunov-ledbat-congestion  
algorithm is adapted from TCP Vegas - do we not believe that it would  
work when re-applied to TCP?

> The difference here is that it has to work within TCP as a form of  
> congestion control (or flow control). There are several applications  
> (not including P2P apps) that require this behavior. The main  
> differences are a) there is no additional framing other than TCP  
> framing b) it should be incrementally deployable, that is only one  
> end (sender or receiver) needs to change as you may not always have  
> control over both ends c) given it would work within TCP it would  
> react to RTT (as opposed to one-way delay) and as a result will be  
> affected by reverse path congestion.

(b) is a new requirement that during the chartering phase wasn't  
discussed much. Obviously, it'd be nice if a one-ended algorithm would  
work, but I'd worry that we're lopping off too much of the design  
space if we make this a hard requirement.

> Even though one of the ledbat requirements is to saturate the  
> bottleneck there are applications that are perfectly fine without  
> saturating the link as long as some basic guarantees on flow  
> completion.

This is again diverging a bit from the goals of the charter. I don't  
think that anyone would be seriously concerned if we came up with an  
otherwise good algorithm that in some corner cases can't fill the  
bottleneck, but if we came up with one that'd never saturate the  
bottleneck, I'd expect the bulk transfer folks to argue a bit.

Lars