[ledbat] [Iccrg] #2/2 draft-mayutan-ledbat-congestionarchitecture-00.txt

[Michael Welzl]

Hi,

Sorry if I'm simply getting something wrong here - I might...
but really, I wonder what's the point in trying to standardize something
as described in this draft?

The "CC. other than LEDBAT" case:

Pluggable congestion control already exists in Linux and BSD, and
seems to work fine there, without the need for a standard. What exactly
would become better because of this draft?

It seems to me that following such a new specification would probably  
mean
a major code rewrite, with no benefits attained except for being able to
say that it complies to this specification.


The LEDBAT case:

I think that, what LEDBAT needs is a specified encapsulation, i.e.
something explaining how the packets and ACKs look, or how this
could be implemented by, e.g., changing TCP a bit without changing
the way packets look (it seems likely that this could be done,
and because of TCP's great ability to fly through firewalls, it seems
to be a good choice to me).
- but how does this generic building block description help LEDBAT?


Again, sorry if this is just me misunderstanding things.

Cheers,
Michael


On Mar 21, 2010, at 3:43 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE  
CORP] wrote:

> The decomposition struck me as a nice start for an abstraction,
> though it seems to me like the implementation is probably a lot
> more complex :).  I think the interfaces between modules are
> probably quite a bit more complex when fleshed out, and then
> it could be "fun" to try to orchestrate the data flow between the
> modules (who gets to look at, and react to, packets first, who
> gets to handle timers first, do modules operate in serial or in
> parallel with one another, etc.).
>
> I think I agree with some of Bob's comments, but I have a more
> basic question that would be good to clear up, if possible, before
> the presentation.  To me, it seems like the "flow-control module" is
> hooked up to a set of sensors that tell it how fast it might be able  
> to
> go (the "bandwidth-estimation module") and another set of sensors
> that tell it when it needs to slow down (the "congestion-detection
> module").  But if we rely on same ACK traffic within a flow to feed
> both of those sets of sensors, then isn't that division a bit  
> artificial?
>
> I took a little bit of a leap in reading it by assuming that maybe you
> would have this incorporated with something like the Congestion
> Manager (RFC 3124) so maybe the sets of signals would be shared
> between flows as appropriate, in which case it then made a little more
> sense to me to split the bandwidth-estimation from the congestion-
> detection since they might each be happening through other
> processes outside of the flow controlled by an individual flow-
> controller.  But the document didn't exactly say this, so I don't know
> if that's an assumption or part of the rationale for this  
> decomposition
> or not.
>
> Also, there might be potential for the modules to fight with each  
> other
> a bit ... won't doing some types of packet probing in the bandwidth-
> estimation module adversely impact a delay-based congestion-
> detection module, for instance.  I guess there may be certain
> combinations that are to be avoided?
>
>
> ________________________________________
> From: iccrg-bounces at cs.ucl.ac.uk [iccrg-bounces at cs.ucl.ac.uk] On  
> Behalf Of Bob Briscoe [rbriscoe at jungle.bt.co.uk]
> Sent: Saturday, March 20, 2010 8:03 PM
> To: Mayutan A.; Xiaoming Fu; KK RAMAKRISHNAN
> Cc: ledbat at ietf.org; iccrg
> Subject: [Iccrg] #2/2 draft-mayutan-ledbat- 
> congestionarchitecture-00.txt
>
> Mayutan, Xiaoming, KK,
>
> Mail #2 of 2: Thoughts on the decomposition itself
>
> Bandwidth-estimation module
> ---------------------------
> I propose it's better to think of this as a Window-overshoot- 
> mitigation module.
>
> i) Bandwidth is the wrong concept. A cc is looking for how much data
> it can risk setting off in flight when it's got insufficient
> information to determine a precise answer. That's a window concept
> [unit: byte], not a bandwidth concept [unit: b/s]. Take QS. The
> router thinks in terms of spare b/s. But the transport has to
> multiply that by RTT to get the initial window it should use.
>
> ii) It's not so much about estimating the right window. It's more
> about ensuring the window is not too wrong, while trying to otherwise
> be as greedy as possible.
>
> Flow-control module
> -------------------
> Unfortunately ambiguous terminology.
> How about Load-response module?
>
> Suggestions for additional functions?
> ------------------------------------
> - Congestion signal conditioning (filtering out synchronised loss
> within a RTT, smoothing in TFRC, etc)
>
> Finally, it needs to be stated explicitly whether this decomposition
> is meant to be all within the sender, or within the transport
> (sender-receiver-pair), or too abstract for this question to be  
> relevant.
>
>
>
>
> Bob
>
>
> At 19:40 03/03/2010, Mayutan A. wrote:
>
>> We have submitted a new draft to the LEDBAT WG and are planning to
>> make a short presentation at the LEDBAT WG and the ICCRG.
>> We are looking forward to all your comments.
>> <http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00 
>> >http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>>
>>
>> Feedback is welcome,
>> Mayutan Arumaithurai
>
>
>
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design
>
>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> _______________________________________________
> ledbat mailing list
> ledbat at ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat