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

From: Bob Briscoe <[email-masked]>
Date: Sat, 20 Mar 2010 23:48:12 +0000

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

---

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

Hello Bob,

Thanks a lot for your feedback. See inline for comments.

On Sun, Mar 21, 2010 at 12:48 AM, Bob Briscoe <[email-masked]>wrote:

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

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.

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

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.

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

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.

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

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.

>
>
> 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.
>
> 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.
>
> I would take this example as a pro for a decoupled architecture. The
congestion-detection module could take this into consideration while mapping
the
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.

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

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.

Mayutan

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

-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)

---

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

Mayutan,

inline marked "[BB]:"

At 15:19 21/03/2010, Mayutan A. wrote:

Hello Bob,

On Sun, Mar 21, 2010 at 12:48 AM, Bob Briscoe
<[email-masked]
> wrote:

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

#1 (this one) Applicability of the decomposition: design, or
standards too?

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?

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.

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.

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.

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.

[BB]: Altho this sounds fine in theory, at a practical level, code that
responds to binary events is very different to code that uses numbers in
equations. In event-based code, the outcome emerges from the frequency of
different behaviours following different events. Whereas in the
equation-based code, the outcome is always present internally, in the
values of the parameters.

Hence my point about using this at the conceptual design phase vs the
practical stages like standardisation and coding.

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.

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.

I would take this example as a pro for a decoupled architecture. The
congestion-detection module could take this into consideration while
mapping the

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.

[BB]: Yes, perhaps you're right. We'd need to try coding this.

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.

[BB]: I'm suspect LEDBAT won't want to be distracted from it's very
focused task. While I suspect folks in ICCRG might be more receptive to
thinking like this.

Cheers

Bob

Mayutan

Bob

<

Feedback is welcome,

Mayutan Arumaithurai

Bob
Briscoe,
BT Innovate & Design

--

Mayutan Arumaithurai

Bob
Briscoe,
BT Innovate & Design