Re: [TERNLI] Notes from tonight's ad hoc

[Lars Eggert <[e-mail]>]

Hi,

On Aug 2, 2006, at 22:29, Bob Briscoe wrote:
> We certainly know what info the *congestion control* part of the  
> transport needs: congestion and delay. So for that we merely need  
> to signal the information the transport needs in packets. And if  
> either of these values changes, it's obvious it's changed. Surely  
> the transport doesn't then need a "something's changed" message.

actually, it's not that obvious. Yes, the transport eventually learns  
that things have changed based on its ongoing path probing, but that  
may be several RTTs later, during which it has transmitted at a rate  
based on stale state. Furthermore, its reaction to the change may be  
too conservative (not a big issue) or not conservative enough.

> Surely the problem is that the netwk layer doesn't signal  
> congestion information with enough precision for the modern  
> transport's needs.

It's not only congestion, it's also delay, plus maybe additional  
information. One work item from the ad hoc meeting was to figure out  
which kinds of information transports do or could operate on.

> My personal preference is to keep the DoS-resistant model...

<I need to think about the snipped parts more.>

> Basically, I'm saying
> a) Instead of signalling "something's changed", I believe it is  
> more practical to continuously signal the "something".

That's an interesting observation. By constantly providing the raw  
information, it is up to the transports to decide what difference  
constitutes a "change" vs. having the network layer decide that a  
"change" has occurred. It also allows transports to process the raw  
information into events any way they see fit, instead of assuming one  
specific way at the layer below.

> b) What congestion control needs most is greater precision for the  
> congestion signal
> c) There are strong but subtle reasons for using probability as a  
> universal congestion signal that lead to overall simplicity when  
> the whole picture is taken into account (which we lose if we adopt  
> QS or XCP).

Lars
-- 
Lars Eggert                                     NEC Network Laboratories