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

Sun Mar 21 02:43:39 GMT 2010

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