Subject: Re: [Tsvwg] HEADS UP: consensus call ondraft-floyd-tsvwg-cc-alt

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 02 Mar 2007 20:32:45 +0000

> -----Original Message-----
> From: Erblichs [mailto:[email-masked]]
> Sent: Friday, March 2, 2007 07:46 PM
> To: 'Bob Briscoe'
> Cc: 'Sally Floyd', 'tsvwg', 'Mark ALLMAN'
> Subject: Re: [Tsvwg] HEADS UP: consensus call ondraft-floyd-tsvwg-cc-alt
> 
> > If alternate congestion controllers send at high rates during times when
> > they believe there is no congestion, they always run the risk that traffic
> > in flight will cause congestion.
> 
> Interesting. All inflight traffic generates some form of congestion, by
> minimally increasing latencies, generating higher rates of interrupts,
> and filling input queues. IMO, The question is whether the increased 
> data rate reaches a threshold at a address that causes RED 
> or tail-drop or some other congestion response OR removes a excess
> range of capacity as to allow a non congestion aware flow to effect
> congestion flows OR a combination of the above..
> 
> However, all the above assume somewhat consistent traffic flows where
> over short periods of time this may be true or averaged over longer
> time periods again may be true, but don't we have to assume that 
> normal bursts of traffic will be generated for a number of reasons?
> And thus a certain excess amount of capacity must be kept within a
> environment to absorb hopefully most of these bursts without generating
> repeated congestion responses.
> 

Any algorithm that attempts to regulate transission speed based on
prior experience is assuming *some* correlation between recent traffic
loading and what the sent packets will actually experience.

And any of them should consider the risk of an increase.

So I don't see how that is relevant to the discussion of any specific
method of congestion control unless you think a specific algorithm
is failing to properly account for inherent variability.