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

[Bob Briscoe]

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