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

[Bob Briscoe <[e-mail]>]

Lars,

At 08:57 03/08/2006, Lars Eggert wrote:
>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.

Yes, I said the TSV needs congestion and delay, but I only focused on the 
NET signalling congestion upwards, because...:

i) If you meant specifically RTT delay (= propagation + congestion delay), 
the TSV can measure that as often as it needs to without explicit signalling.

ii) However, if you meant specifically congestion delay I disagree - this 
is less useful as a congestion metric (implying I don't believe FAST TCP or 
Vegas are the long term direction - fine as tactical hacks).

Arguments against congestion delay as a metric:
a) Explicit congestion signalling is a richer way for the NET to signal how 
much the TSV should change its rate because, if the NET signals (or the TSV 
measures) congestion delay, in order to signal an equivalent amount of info 
to the TSV for it to know how to change its rate, the NET would also have 
to say what the output line rate of each interface was (meaning numerous 
metrics across a path - yuk). Just signalling congestion does that all in 
one metric, even when accumulated across a path.
b) Measuring congestion delay is fine as a tactical hack to get more 
precise info from the network than 1-bit drop or 1-bit ECN, but it won't be 
useful long term as link speeds increase. Then congestion delay becomes so 
small relative to propagation delay that it becomes a very imprecise metric 
to do congestion control on (IOW, the equiv no. of bits of info per packet 
is currently >1, but will become <1 as the net scales).

(We're in the early stages of writing up and proving the above argument as 
a full paper.)

BTW, I do agree with FAST & Vegas (and Siris's weighted window-based cc) on 
another count: Unlike Reno, delay should only determine the second order 
behaviour, not the first order. Ie the equilibrium rate shouldn't depend on 
RTT, but how fast it gets there should.

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


If the NET says "something's changed",
* 1RTT later the TSV probes.
* The TSV has to probe for everything, because it doesn't know what 
"something" is (unless the NET allows the question "what's changed?" which 
is silly - it would have been better for the NET to say what changed in the 
first place otherwise this would take yet another RTT).
* 1 more RTT later the TSV finds out the info.

That's 2RTTs already.

If we can get down to exactly what the "something's" are, we can know how 
many bits would be needed to continuously repeat them, rather than 
implement the more complicated probe interfaces necessary above.

Additionally, when talking about changes in load/congestion, the NET 
doesn't know what threshold all the different TSVs would like it to use to 
decide when a change has been big enough to say "something's changed". 
Congestion changes all the time. Some changes are bigger than others. So 
the approach of continuously reporting the current level avoids the NET 
second guessing what changes TSVs are interested in.


Bob


____________________________________________________________________________
Bob Briscoe, <[e-mail]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone]