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

From: "Sinnreich, Henry" <[email-masked]>
Date: Wed, 24 May 2000 23:30:43 +0000

Radhika,
We have taken a stab at this in
http://ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-01.t
xt

Let us know what you think of the model in this draft. Your comments will be
appreciated.
This is a good opportunity to discuss, though under a different title. Such
as sip-qos? :-)

Henry

>-----Original Message-----
>From: Roy, Radhika R, ALARC [mailto:[email-masked]]
>Sent: Wednesday, May 24, 2000 3:57 PM
>To: Dave Oran; Dean Willis
>Cc: Michael Thomas; IETF SIP
>Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task
>for ce in Adelaide)
>
>
>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
>

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