Subject: Re: [ledbat] Ledbat variants

From: Bob Briscoe <[email-masked]>
Date: Mon, 06 Jul 2009 15:24:32 +0100

Lars, Murari,

A specific example: Measuring one-way delay, which:
- isn't trivial to add to most existing protocols - requiring a new option
- isn't typically incrementally deployable at only one end

Nonetheless, it's good for a congestion control to avoid getting 
confused by delay on the return path. However, if we take the view 
that avoiding this confusion is a luxury and incremental deployment 
is more important, we'll never actually get rid of being confused by 
return path delays. It is better to have a protocol that will do 
one-way delay where it can, but fall back to two-way only if it can't.

Bob

At 08:42 29/06/2009, Lars Eggert wrote:
>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
>
>
>
>
>_______________________________________________
>ledbat mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ledbat

_________________________________________________________________________
Notice: This contribution is the personal view of the author and does 
not necessarily reflect the technical nor commercial direction of BT plc.
_________________________________________________________________________
Bob Briscoe,                       Networks Research Centre, BT Research