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

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Sat, 20 Mar 2010 21:43:39 -0500

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: [email-masked] [[email-masked]] On Behalf Of Bob Briscoe [[email-masked]]
Sent: Saturday, March 20, 2010 8:03 PM
To: Mayutan A.; Xiaoming Fu; KK RAMAKRISHNAN
Cc: [email-masked]; 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
[email-masked]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

---

From: Michael Welzl <[email-masked]>
Date: Sun, 21 Mar 2010 14:01:23 +0100

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:

> From: [email-masked] [[email-masked]] On  
> Behalf Of Bob Briscoe [[email-masked]]
>> <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
>
>
>
>
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat