Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task for ce in Adelaide)

From: "Roy, Radhika R, ALARC" <[email-masked]>
Date: Wed, 24 May 2000 16:56:50 -0400

Hi, Dave and Dean:

Let me try to understand the issues correctly.

A SIP proxy server is an application level entity that deals with the
application layer signaling scheme.

RSVP, DiffServ, etc are the network layer QOS signaling schemes.

So, I believe that it would be better to have a clear separation between the
two although there can be an abstraction for interworking between the two
layers. The question is: How do we this without creating scalability
problems?

In this context, let us analyze the following:

Should the SIP proxy server do the bandwidth allocation and admission
control?

It depends what the abstraction of bandwidth and admission control is.

In true sense, the admission control to the network based on bandwidth and
other performance criteria will fall into the category of the lower network
layer entities because the network layer resource allocation will be done by
them. 

Now the challenge is: How can this lower network layer information be
abstracted (or coupled) to the application layer SIP proxies that are
responsible to set up the call on end-to-end basis between the SIP agents?

Did I miss something?

Best regards,
Radhika R. Roy

> -----Original Message-----
> From:	Dave Oran [SMTP:[email-masked]]
> Sent:	Wednesday, May 24, 2000 4:09 PM
> To:	Dean Willis
> Cc:	Michael Thomas; IETF SIP
> Subject:	RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security
> task force in Adelaide)
> 
> Ah. I understand. no RSVP == no explicit admission control.
> That's the bug. Hijacking SIP proxies to do the job of a bandwidth
> allocation and admission control signaling protocol is ugly at best. You'd
> need one of these beasts for every application in the universe - rtsp,
> quake, you name it.
> 
> If you build SIP proxies the way some people build web server farms you'll
> have an entirely different scaling problem, which is 100's of SIP proxies
> polling a poor overworked network managmeent system trying to figure out
> what it knows about the state of the core (or better stated, what it knew
> about the core 5 minutes ago when it last gathered enough measurements to
> make a guess).
> 
> Register me as a skeptic.
> 
> Dave.
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:[email-masked]]
> > Sent: Wednesday, May 24, 2000 3:53 PM
> > To: Dave Oran
> > Cc: Dean Willis; Michael Thomas; IETF SIP
> > Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task
> > force in Adelaide)
> >
> >
> >
> >
> > Dave Oran wrote:
> > >
> > > If you're using Intserv at the edge the router at the edge of
> > the Diffserv
> > > cloud will likely know this and reject the reservation. No need for
> the
> > > proxy to get involved.
> >
> > In general, I'm not. The WorldCom net, for example, is TOS-priority from
> > end to end.
> >
> > >
> > > The car analogy is not a good one because in the case of highways
> you're
> > > already stuck at the bottleneck when you find out you're
> > screwed, as opposed
> > > to RSVP when you are essentailly clearing all the dead wrecks
> > out of your
> > > way before driving up the highway, ala Mad Max.
> > >
> > > Positing that a SIP proxy has a better idea what the QoS state of the
> > > Diffserv core is than the edge router at the edge of that core is like
> > > saying the radio announcer knows more about the tornado than the
> Twister
> > > crew chasing it.
> >
> > A SIP proxy is in a better position to have a persistent relationship
> > with a network management system which can feed it information about the
> > state of the network than a dynamically romin SIP UA is. So, even though
> > the announceer may not know as much about the tornado as the chaser
> > does, he is in a MUCH better position to share that information with the
> > listening audience.
> >
> > > If there's a oracle which knows the state of the core it can
> > tell the edges
> > > as easily or MORE easily than it can tell an undefined sea of
> > application
> > > proxy boxes.
> >
> > Sure, the edges probably know truckloads of cool stuff.
> >
> > But I have no mechanism for the edges to relay this knowledge to the
> > UAs.
> >
> > --
> > Dean
> >
> >
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 24 May 2000 17:40:41 -0400

Actually, I think I completely failed to make my point.

I was not suggesting that the proxy do either bandwidth allocation or
admission control. It might make sense in some cases, but that's not
what I'm talking about.

I'm trying to say that a proxy could be a way to get ADVICE about the
state of a core network to devices on the edge -- that it could
RECOMMEND that a client not try to traverse the net when there is a low
probability of success.

In general, I don't expect "controls" to survive hostile users.
Especially admission-control proxies that one can just go around. Bad
idea, don't go there.

Or maybe we need a general "Hey, how's the net doing?" protocol . . .

--
Dean

---

From: "Dave Oran" <[email-masked]>
Date: Wed, 24 May 2000 19:42:13 -0400

> Or maybe we need a general "Hey, how's the net doing?" protocol . . .
Ping?

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 May 2000 11:00:56 -0400

Ping doesn't really tell me much about load distribution between traffic
priorities, nor about timing variations. Maybe a priority PING . . .

--
Dean