[Iccrg] #1/2 draft-mayutan-ledbat-congestionarchitecture-00.txt
Bob Briscoe
rbriscoe at jungle.bt.co.uk
Sat Mar 20 23:48:12 GMT 2010
Mayutan, Xiaoming, KK,
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).
So I'll split my thoughts into 2 mails:
#1 (this one) Applicability of the decomposition: design, or standards too?
#2 (next) thoughts on the decomposition itself
Sub-questions to help determine whether we should decompose CC standards:
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?
A1. I say we probably need just one track
Q2. Does experience show that the sub-functions are cleanly
separated, to the extent that they could be plugged together in different ways?
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.
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.
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):
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.
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.
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).
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.
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
More information about the Iccrg
mailing list