[e2e] Question the other way round:
Jon.Crowcroft at cl.cam.ac.uk
Wed Nov 20 23:29:41 PST 2013
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
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
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:
>>>>> 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
>>> Unless someone's edited it, you should read the first sentence again. I
>>>> 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.
>>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.
More information about the end2end-interest