[e2e] admission control vs congestion control

[Fahad Dogar]

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