[e2e] admission control vs congestion control

[Dah Ming Chiu]

How about a "quick-brobing delayed blocking" approach?
In other words, you only probe for tolerable "post-dial delay" and
admit if okay or uncertain. When things get bad, the call may be
dropped in the middle. Hopefully with sufficient over-provisioning,
the "delayed blocking" happens very rarely.  This may be what is
already "implemented" in the sense that the "quick probing" part is "no
probing" and the "delayed blocking" part is done by the human user.

Dah Ming

----- Original Message ----- 
From: "Henning Schulzrinne" <hgs at cs.columbia.edu>
To: "Lisong Xu" <lisongxu2 at gmail.com>
Cc: "Fred Baker" <fred at cisco.com>; <end2end-interest at postel.org>
Sent: Wednesday, April 19, 2006 4:52 AM
Subject: Re: [e2e] admission control vs congestion control


>- Delay until admission decision makes many such techniques unsuitable 
> for applications where humans are waiting ("post-dial delay")
> - Overhead of probing, particularly if the probe has to be repeated 
> after a failure
> - Guarantees tend to be weak, i.e., you may get a positive answer and 
> still suffer packet loss, particularly if the number of flows is small 
> and flows are bursty or on-off (such as voice) if the probe gets "lucky"
> 
>> I agree with you that "people don't want to build large amounts of
>> state into the network." But there are also admission control methods
>> that do not build any state into the network, such as probing-based
>> methods. Why these methods have not been widely accepted and
>> implemented? I guess the tcp friendliness is one of the reasons, are
>> there any other fundamental reasons?
>> 
>> Thanks
>> Lisong
>