[e2e] Question the other way round:

[Joe Touch]

Correction. It's not ischemic; it's isarithmic. I do tend to confuse the 
two words (the hazards of one too many biology classes).

Thanks to Lars Wolf for recalling it correctly. It is applicable only in 
very specific topologies, but it's one of the 'odd' examples I'm fond of.

Joe

On 11/20/2013 10:23 AM, Joe Touch wrote:
>
>
> 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