[e2e] admission control vs congestion control

[Dah Ming Chiu]

You can think of both congestion control and admission control as
traffic controls used to allocate resources to flows.  Furthermore,
these traffic controls may need to co-exist in the same network,
allocating the same set of resources together somehow.

Maybe if you pre-supposed that these two mechanisms are to
deal with separate pools of resources, then they would not be
related.

Regards
Dah Ming

----- Original Message ----- 
From: "Fahad Dogar" <fahad.dogar at gmail.com>
To: "Lisong Xu" <lisongxu2 at gmail.com>
Cc: "Fred Baker" <fred at cisco.com>; <end2end-interest at postel.org>; "Dah Ming 
Chiu" <dmchiu at ie.cuhk.edu.hk>
Sent: Thursday, April 20, 2006 2:29 AM
Subject: Re: [e2e] admission control vs congestion control


>I can understand the need for admission control and how it can result
> in some QoS guarantees for applications. However, I fail to understand
> the relationship between congestion control mechanisms (employed by
> TCP) and QoS for multimedia applications. Can anyone clarify?
>
> Regards,
> Fahad
>
>
>
> On 4/19/06, Lisong Xu <lisongxu2 at gmail.com> wrote:
>> You are right that no one would pay for it. But if it is free, I guess
>> it is still very attractive compared to the current best-effort
>> service.
>> Lisong
>>
>> On 4/19/06, Fred Baker <fred at cisco.com> wrote:
>> > 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
>> > >>
>> >
>>