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

From: "Sinnreich, Henry" <[email-masked]>
Date: Sat, 20 May 2000 13:10:14 +0000

>The real question is to define a mechanism that allows the 
>health of the network to be assessed in some sort of 
>meaningful way so that this knowledge may be made available to the UAC.

The model in <sinnreich-sip-qos-osp> actually deals with this problem.
Upon failure of the RSVP request, the telephony endpoint can alert the user:
"QoS cannot be provided, would you like to proceed with the call".

The awareness of the originating SIP server, though we not explicitly
discussed is can also be dealt with by the model.

We have shown that the transit network providing DiffServ to the edge
networks have to police the ingress traffic, to make sure that that the
premium QoS traffic injected does not exceed the SLS. This job is done by
the border routers in the transit networks.

The border router can alert the edge router in the access network when
excess traffic is being passed, and this could be also used to alert the
bandwidth and policy manager in the access network. The policy manager will
refuse to authorize new requests for QoS enabled voice calls coming from
application servers, including the SIP server. The SIP server will therefore
know...

Please let me know if there are any weaknesses in the model, as shown in the
diagrams and call flows.
http://ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-01.t
xt

Henry

>-----Original Message-----
>From: Dean Willis [mailto:[email-masked]]
>Sent: Friday, May 19, 2000 5:35 PM
>To: Michael Thomas
>Cc: IETF SIP
>Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task
>force in Adelaide)
>
>
>
>Ah. The networkstatus-aware proxy is effectively advising the 
>SIP user of congestion in the DiffServ network. Kind of like 
>those radio announcers that say "Highway 18 is shut down again 
>-- please use surface streets or just stay home".
>
>The real question is to define a mechanism that allows the 
>health of the network to be assessed in some sort of 
>meaningful way so that this knowledge may be made available to the UAC.
>
>--
>Dean
>
>
>
>> -----Original Message-----
>> From: Michael Thomas [mailto:[email-masked]]
>> Sent: Thursday, May 18, 2000 4:32 PM
>> To: Dean Willis
>> Cc: IETF SIP; Michael Thomas
>> Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP 
>Security task force
>> in Adelaide)
>> 
>> 
>> Dean Willis writes:
>>  > Consider it in an aggregation model, like a donut. The chewy 
>> outside parts of the donut are controlled by IntServ. Traffic 
>> leaps across the DiffServ donut-hole only if the heuristic 
>> process thinks (IE, is reasonably sure) that there is 
>adequate bandwidth.
>> 
>>    OK, but I still don't see what that has to do
>>    with proxies. That sounds like something an
>>    edge router would do before it admits diffserv
>>    traffic into the diffserv core. Proxies are even
>>    more clueless because they never see the actual
>>    traffic patterns.
>> 
>> 		Mike
>> Hfæj)bz	b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿(tm)¨¥(tm)©ÿ-+-SwèþÈ©
>

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

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 21 May 2000 02:41:22 -0500

Henry wrote:
> Dean wrote:

Perhaps, but I'm trying to find a way to get knowledge about the state of the backbone network into an edge device WITHOUT using RSVP.

It just occurred to met that this could also be used as a means of traffic shaping enterprise access to fit within the bounds of a slightly elastic SLA.

Let's say CorpA has an SLA whereby they are allowed to admit up to an average of 1Mb/S of expedited traffic across any 10-minute window, and whatever their port will carry of best-effort.

Here's one possible way:

The access routers feeds class-usage counters periodically (say, 1 minute intervals) to a network management system. This NMS then calculates a sliding average for each traffic class.  From the current average, it calculates the maximal steady-state bandwith allowable over the next ten minutes to stay within the SLA minus a safety margin. The NMS then divides this number by the average bandwith requirement of a phone call at this site, thereby generating a number which is roughly the equivalent of the number of calls that may be admitted RIGHT NOW without causing a violation of the SLA to occur. The NMS posts this data to a proxy, which then decrements this number for each additional call admitted. When a new estimate comes in, it replaces the current working number. If the working number drops to zero (or some low threhold to allow for emergency calls), calls are not admitted unlesss they appropriately marked "urgent".

I suppose one could do a monte-carlo simulation of this and get a reasonable feel for the efficacy.

--
Dean

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú?

---

From: Cary FitzGerald <[email-masked]>
Date: Sun, 21 May 2000 19:42:47 -0700

This technique is the moral equivalent of H.323 GK-based bandwidth management.  The results from that set of experiences leaves the proposition unproven.  To my way of thinking, there are a number of inherent weaknesses in the model (for example, in your scenario, you won't discover anything about the backbone, only something about the access routers).  On the other hand, you don't need anything new in SIP itself to build such a proxy, right?

Cary.

Dean Willis wrote:

> Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ©

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 22 May 2000 09:09:44 -0500

I'm really not trying to propose the "gatekeeper control" here -- the fundaments of that are well-established. What I'm attempting to do is show how knowledge about the state of the network can be made available to SIP UAs without having to have the UA explicitly sharing (and understanding)that knowledge.

I'm also somewhat muddlingly trying to consider what sort of knowledge might be available at a relatively low cost (both in network and development terms) and how we might apply that knowledge in a variety of SIP environs.

--
Dean

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Cary FitzGerald
> Sent: Sunday, May 21, 2000 9:43 PM
> To: Dean Willis
> Cc: Sinnreich, Henry; IETF SIP
> Subject: Re: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task
> for cein Adelaide)
> 
> 
> This technique is the moral equivalent of H.323 GK-based 
> bandwidth management.  The results from that set of experiences 
> leaves the proposition unproven.  To my way of thinking, there 
> are a number of inherent weaknesses in the model (for example, in 
> your scenario, you won't discover anything about the backbone, 
> only something about the access routers).  On the other hand, you 
> don't need anything new in SIP itself to build such a proxy, right?
> 
> Cary.
> 
> Dean Willis wrote:
> 
> > Henry wrote:
> > > Dean wrote:
> > Perhaps, but I'm trying to find a way to get knowledge about 
> the state of the backbone network into an edge device WITHOUT using RSVP.
> >
> > It just occurred to met that this could also be used as a means 
> of traffic shaping enterprise access to fit within the bounds of 
> a slightly elastic SLA.
> >
> > Let's say CorpA has an SLA whereby they are allowed to admit up 
> to an average of 1Mb/S of expedited traffic across any 10-minute 
> window, and whatever their port will carry of best-effort.
> >
> > Here's one possible way:
> >
> > The access routers feeds class-usage counters periodically 
> (say, 1 minute intervals) to a network management system. This 
> NMS then calculates a sliding average for each traffic class.  
> From the current average, it calculates the maximal steady-state 
> bandwith allowable over the next ten minutes to stay within the 
> SLA minus a safety margin. The NMS then divides this number by 
> the average bandwith requirement of a phone call at this site, 
> thereby generating a number which is roughly the equivalent of 
> the number of calls that may be admitted RIGHT NOW without 
> causing a violation of the SLA to occur. The NMS posts this data 
> to a proxy, which then decrements this number for each additional 
> call admitted. When a new estimate comes in, it replaces the 
> current working number. If the working number drops to zero (or 
> some low threhold to allow for emergency calls), calls are not 
> admitted unlesss they appropriately marked "urgent".
> >