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

From: "Mayutan A." <[email-masked]>
Date: Sun, 21 Mar 2010 16:37:58 +0100

Hi Bob,

Thanks once again for your feedback. See inline.

On Sun, Mar 21, 2010 at 1:03 AM, Bob Briscoe <[email-masked]>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)

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 21 Mar 2010 20:13:41 +0000

Mayutan,

At 15:37 21/03/2010, Mayutan A. wrote:
>On Sun, Mar 21, 2010 at 1:03 AM, Bob Briscoe 
><<mailto:[email-masked]>[email-masked]> wrote:
>Mayutan, Xiaoming, KK,
>
>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.

I'm not concerned about just the name. The semantics of window is 
what I think you need here, not bandwidth. This is important to get right.

[A similar example: Stas Shalunov pointed out to me once (I think 
repeating someone else) that if MTU had been defined in units of 
time, not bytes, packets would have grown naturally as link 
technology increased and data networking would have evolved very 
differently. Effectively the MTU is the liaison concept between IETF 
and IEEE. Similarly, the interface to your top module is important to 
get in the right units.]

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

Cheers

Bob