[e2e] admission control vs congestion control

[Fred Baker]

Would you find that acceptable as a service? Would you pay for it? Or  
would you say "this crappy service is unreliable; I would rather go  
to the corner store and rent the movie than wonder whether the rental  
from my ISP is going to actually stay up or maybe have little squares  
all over it half the time"?

On Apr 18, 2006, at 11:00 PM, Dah Ming Chiu wrote:

> 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
>>