[re-ECN] Congestion is relative (was: Re: Acronym for BoF / w-g?)

[Bob Briscoe <[e-mail]>]

Fred,

It was fine to say this on the list. I wasn't trying to protect the 
nameless correspondent. The only reason I responded off-list was so 
as not to send the acronym thread off into a side topic, when we have 
to focus on getting this BOF acronym sorted.

The side topic is important, and I agree with you.


Bob

At 01:48 29/09/2009, Fred Baker wrote:

>On Sep 28, 2009, at 5:08 PM, Bob Briscoe wrote:
>
>A nameless correspondent told [you] that...
>
>>The Internet should also be able to connect machines next door to
>>each other together. They might have sub-ms RTTs. We shouldn't
>>prevent scaling to tiny RTTs. One workround is not to standardise a
>>timescale for smoothing the queue, but allow a queue to be
>>configured in the knowledge of whether it might have v short RTT
>>paths through it.
>
>You sent this to me privately, but I'm am going to completely blow
>etiquette to the winds and reply publicly.
>
>I agree with your correspondent. To my way of thinking, the term
>"congestion" has many possible "correct" definitions; the key thing is
>that that sessions related to one set of applications and/or users
>prevents another set of applications and/or users from doing something
>that they would otherwise reasonably expect. TCP Reno measures
>congestion by loss; CalTech FAST measures congestion by change in mean
>delay. If the re-ecn model is being applied to a class of traffic that
>is priority-queued and traffic above some rate is dropped, the only
>model I can make any sense out of is one that determines what fraction
>of a stated rate is currently in use. In an 802.11 network, one could
>discuss the collision rate perceived by the interface. And in your
>corespondent's case of a sub-ms RTT (which would be characteristic of
>a data center), I'm not sure what measure applies best. Maybe the
>percentage of the time a queue has something in it?
>
>And then there is the question - is that aggregated by source address,
>as in the way a BitTorrent server (file source) behaves, or by
>destination address, as in how a BitTorrent client (file sink)
>behaves, or is it by individual sessions? Or should one maybe track
>all three and let any of them mark the packet?
>
>Now imagine typical web service behavior - a datagram starts in a data
>center, crosses a fiber-optic backbone, enters my home through a
>broadband interface, and crosses my WiFi to my computer.
>
> From my perspective, each interface in the network is likely to apply
>its own congestion model, and therefore its own congestion measure.
>What is important to control is not the specifics of the measure, but
>the fact that someone along the way is feeling trodden upon, that the
>offending traffic appears to have the potential to prevent another
>"customer", for some definition of the term, from doing their thing.
>If we have reasonable measures - not "the same measures", but
>"appropriate measures for the class of congestion under consideration"
>- in each place, the right thing should happen. The congested
>interface should be able to declare its pain, and the implicated
>sessions should back off.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design