Re: [re-ECN] Acronym for BoF / w-g?

[Fred Baker <[e-mail]>]

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.