[e2e] Question the other way round:

[Jon Crowcroft]

i think we're mixing up two discussions here

1. congestion was the original cause of the cwnd  mech in tcp, BUT the
rate adaption using feedback as a way to distributed resource
allocation is the solution of the optimisation problem of net + user
addressed by several researchers (kelly/voice et al, also folks at
caltech) - these aren't the same thing - they got conflated in
protocols in practice because we couldn't get ECN out there completely
(yet) - ECN (when implemented with some decent queue (see 3 below) can
be part of an efficient decentralised rate allocation

congestion is bad - avoiding it is good

distributed rate allocation for flows 
that have increasing utility for higher rate transfer 
is also good (actually its betterer:)

2. for flows that have an a priori known rate, distributed rate
allocation is a daft idea, a priori - so some sort of admission
control for the flow seems better (but you can do probe/measurement
based admission control if you like, and are allergic to complex
signaling protocols)

3. orthogonal to both 1&2 is policing and fairness - flow state means you
can do somewhat better in fairness for 1 (e.g. do fair queus, a la
keshav), and a lot better for policing for 2...

but then we've been round the best effort, integrated service,
differentated service, core stateless fair queue, probe based
admission control, ecn, pcn loop about 6 times since this list
existed:)

yes, to detlef's  original point, causing congestion (and buffer
overrun) to find out the rate is a bit of a sad story...

In missive <528CFE15.7070808 at isi.edu>, Joe Touch typed:

 >>
 >>
 >>On 11/19/2013 7:14 PM, Ted Faber wrote:
 >>> On 11/19/2013 10:15, Joe Touch wrote:
 >>>> On 11/19/2013 10:09 AM, Dave Crocker wrote:
 >>>>> Given the complete generality of the question that was asked, is there
 >>>>> something fundamentally deficient in the answer in:
 >>>>>
 >>>>>      http://en.wikipedia.org/wiki/Congestion_control#Congestion_control
 >>>>>
 >>>>> ?
 >>>>>
 >>>>> In particular, I think it's opening sentence is quite reasonable.
 >>>>
 >>>> I agree, but it jumps in assuming packets. Given packets, it's easy to
 >>>> assume that oversubscription is the natural consequence of avoiding
 >>>> congestion.
 >>>
 >>> Unless someone's edited it, you should read the first sentence again.  I
 >>> see:
 >>>
 >>>> Congestion control concerns controlling traffic entry into a
 >>>> telecommunications network, so as to avoid congestive collapse by
 >>>> attempting to avoid oversubscription of any of the processing or link
 >>>> capabilities of the intermediate nodes and networks and taking resource
 >>>> reducing steps, such as reducing the rate of sending packets.
 >>>
 >>> I read the reference to packets as an example.
 >>
 >>Me too.
 >>
 >>But circuits don't have a collapse or oversubscription. They simply 
 >>reject calls that aren't compatible with available capacity.
 >>
 >>I'm not disagreeing with the definition; I'm disagreeing with the 
 >>assumption that having a network implies congestion and thus the need 
 >>for congestion control.
 >>
 >>There are a variety of mechanisms that avoid congestion, typically by 
 >>a-priori reservation (circuits), or by limiting resource use implicitly 
 >>(e.g., ischemic control). These are a kind of proactive control that 
 >>avoid congestion in the first place.
 >>
 >>That's not to say whether these mechanisms are scalable or efficient 
 >>compared to the resource sharing afforded by packet multiplexing.
 >>
 >>Joe

 cheers

   jon