<span style="color: rgb(51, 102, 255);">Hi Bob,</span><br style="color: rgb(51, 102, 255);"><br style="color: rgb(51, 102, 255);"><span style="color: rgb(51, 102, 255);">Thanks once again for your feedback. See inline. </span><br>
<br><div class="gmail_quote">On Sun, Mar 21, 2010 at 1:03 AM, Bob Briscoe <span dir="ltr"><<a href="mailto:rbriscoe@jungle.bt.co.uk">rbriscoe@jungle.bt.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mayutan, Xiaoming, KK,<br>
<br>
Mail #2 of 2: Thoughts on the decomposition itself<br>
<br>
Bandwidth-estimation module<br>
---------------------------<br>
I propose it's better to think of this as a Window-overshoot-mitigation module.<br>
<br>
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.<br>
</blockquote><div><br style="color: rgb(51, 102, 255);"><span style="color: rgb(51, 102, 255);">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. </span><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.<br></blockquote><div><br><span style="color: rgb(51, 102, 255);">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. </span><br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Flow-control module<br>
-------------------<br>
Unfortunately ambiguous terminology.<br>
How about Load-response module?<br></blockquote><div><br><span style="color: rgb(51, 102, 255);">Yes, this sounds good too. </span><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Suggestions for additional functions?<br>
------------------------------------<br>
- Congestion signal conditioning (filtering out synchronised loss within a RTT, smoothing in TFRC, etc)<br>
<br>
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.<br></blockquote>
<div><br><span style="color: rgb(51, 102, 255);">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. <br>
</span><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Bob<br>
<br>
<br>
At 19:40 03/03/2010, Mayutan A. wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
We are looking forward to all your comments.<br>
<<a href="http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00" target="_blank">http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00</a>><a href="http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00" target="_blank">http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00</a><br>
<br>
<br>
Feedback is welcome,<br>
Mayutan Arumaithurai<br>
</blockquote>
<br>
<br>
<br>
<br>
________________________________________________________________<br><font color="#888888">
Bob Briscoe, BT Innovate & Design <br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Mayutan Arumaithurai<br>0049-551-2712647 (Home number) <br>0049-176-20322049 (mobile number)<br>