Hello Bob,<br><br>Thanks a lot for your feedback. See inline for comments. <br><br><div class="gmail_quote">On Sun, Mar 21, 2010 at 12:48 AM, Bob Briscoe <span dir="ltr"><<a href="mailto:rbriscoe@jungle.bt.co.uk" target="_blank">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>
It seems a good idea to try to decompose the sub-functions of CC. I suspect this is best kept to the CC design process though (primarily ICCRG). Rather than an organising principle for standardisation as well (as suggested in the draft).<br>
</blockquote><div><br style="color: rgb(51, 102, 255);"><span style="color: rgb(51, 102, 255);">Our primary focus was to attempt such a decoupling in the LEDBAT WG for a scavenger transport protocol, before attempting a more general one in the ICCRG</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>
So I'll split my thoughts into 2 mails:<br>
#1 (this one) Applicability of the decomposition: design, or standards too?<br>
#2 (next) thoughts on the decomposition itself<br>
<br>
Sub-questions to help determine whether we should decompose CC standards:<br>
<br>
Q1. Are we likely to need lots of different scavenger CCs, or are we more likely to be refining and improving a single track of progressively more generic/graceful/cool ones?<br>
A1. I say we probably need just one track<br></blockquote><div><br><span style="color: rgb(51, 102, 255);">I would agree to having just one track too, but based on a decoupled architecture (not completely decoupled though). This would make it easier to propose extensions. For e.g, if someone comes up with a better delay based congestion detection tool, or a more efficient available bandwidth estimation tool, we could just standardize the mechanism. The mechanism could then be used not only by a scavenger protocol, but also by other congestion control protocols. To phrase it differently, once the LEDBAT WG standardizes a one-way delay based scavenger protocol, other CC protocols may want to use the one-way delay based mechanism to detect congestion, but their reaction to detected congestion might vary from that of a scavenger CC protocol. </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>
Q2. Does experience show that the sub-functions are cleanly separated, to the extent that they could be plugged together in different ways?<br>
A2. I think the skill of designing a good congestion control is about how well the parts complement each other. In fact, one theme of the talk I'm planning for ICCRG this week is that we need to be more careful to think about the cross-effects of some flows in slow-start on others in congestion avoidance (& vv) when designing CC.<br>
</blockquote><div><br><span style="color: rgb(51, 102, 255);">I agree that the various modules need to complement each other. This draft is an attempt to study how and to what extent can we decouple the various components.</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;">
So rather than showing Fig 1 as if there is one common interface between the paris of modules, it's more important to show that the interface depends on which type of outer module is used. For instance "CONGESTION_DETECTED" could be a binary congestion event, or a delay variable, or a QS bit-rate.<br>
</blockquote><div><br><span style="color: rgb(51, 102, 255);">Currently, what I had in mind was a binary indicator (congested/not-congested) or a multilevel indicator. We need to give more thought to whether we require multiple interfaces between the modules or could we come up with a method to map the various indicators to a common "CONGESTION_DETECTED" indicator. </span></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>
Here's an example of where we've already got more modularisation than we should have in the TCP standards (in your I-D's terminology, the flow control module behaviour should depend on the which congestion detection module we choose):<br>
<br>
If my window is 30x yours, and I get 40 ECN marks within one RTT and you get 1, I should reduce more than once within the RTT. Whereas if I get 40 drops in one RTT, it's more correct to only reduce once.<br>
<br>
Reasoning: If congestion detection is by ECN not drop, it implies the congestion must be from AQM not tail drop. Whereas 40 drops can mean a whole load of synchronised tail drop, 40 ECN marks can't mean synchronised drop. So I should take 40 ECN marks more seriously.<br>
<br></blockquote><div><span style="color: rgb(51, 102, 255);">I would take this example as a pro for a decoupled architecture. The congestion-detection module could take this into consideration while mapping the <br>obtained indication to the "CONGESTION_DETECTED" variable. The flow control module could be designed based on just the value returned by the "CONGESTION_DETECTED" variable and need not have to differentiate between a drop, an ecn marking or increase in delay. </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>
Finally, another thought on applicability: This I-D isn't only applicable to scavenger CCs. It's clearly applicable to all CC design work (again primarily ICCRG).<br>
<br>
That's not to say it can't help LEDBAT in future. LEDBAT is on the experimental track, so it would be fine if we learn something from this decomposition that can help improve LEDBAT between experimental and Proposed Standard stages.<br>
</blockquote><div><br><span style="color: rgb(51, 102, 255);">Yes, we are planning to present it at the LEDBAT and make a short presentation at the ICCRG too. We feel that the LEDBAT WG might be a good starting point, and that the approach could be extended to all kinds of congestion control protocols. </span><br>
<br>Mayutan <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>
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>