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

[Mayutan A.]

Hi Bob,

Thanks once again for your feedback. See inline.

On Sun, Mar 21, 2010 at 1:03 AM, Bob Briscoe <rbriscoe at jungle.bt.co.uk>wrote:

> 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.
>

Currently, what I have in mind is the estimation of actual bandwidth to
assist the flow-control module and leave it to the flow-control module to
convert this to a relevant window size. In theory, this module could
indicate window size too. Thanks for the alternate name suggestion.

>
> 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.
>

By estimation, I meant the above. Thanks for phrasing it well. I should
probably use a different word here or the name suggested by you.


> Flow-control module
> -------------------
> Unfortunately ambiguous terminology.
> How about Load-response module?
>

Yes, this sounds good too.


>
> 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.
>

The decomposition could be performed within the sender, and might be
necessary within the transport depending on the choice of the bandwidth
estimation mechanism. According to me, this kind of a decomposition is
implicitly followed in some of the current specifications. For e.g TCP
variants state that an ECN marking is to be treated similar to a loss, or
that the reaction to loss is to halve the congestion window, similar to that
performed by standard TCP.


>
>
> 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
>



-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100321/e5bbb08d/attachment-0001.html