Subject: Re: [NSIS] RE: QSPEC - admission priority parameter

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 2 Feb 2006 15:48:16 +0100

Hi Jerry

Please see bellow:
> The procedures for the 16-bit admission priority parameter defined in 
> http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.txt 
> appears to derive heavily on procedures specified for RSVP Preemption 
> Priority:
> [RSVP-PREEMP]  Herzog, S., "Signaled Preemption Priority Policy Element", 
> RFC 3181, October 2001.
>
> The QSPEC I-D specifies preemption/defending priority parameters in 
> Section 7.2.7.1 (Preemption Priority> & <Defending Priority> Parameters 
> [RFC 3181]).
>

But the 
http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.txt 
draft specifies that:
"
[RSVP-POLICY] defines extensions for supporting generic policy based
   admission control in RSVP. These extensions include the standard
   format of POLICY_DATA objects and a description of RSVP handling of
   policy events.

   The POLICY_DATA object contains one or more of Policy Elements, each
   representing a different (and perhaps orthogonal) policy. As an
   example [RSVP-PREEMP] specifies the Preemption Priority Policy
   Element.
       This document defines a new Policy Element called the Admission
   Priority Policy Element.

-//- skip
 Admission Priority: 16 bit (unsigned)
       The admission control priority of the flow, in terms of access
       to resources set aside in order to provide higher probability of
       call completion to selected flows. Higher values represent
       higher Priority. A reservation established without an Admission
       Priority policy element is equivalent to a reservation
       established with an Admission Priority policy element whose
       Admission Priority value is 0.  "

Thus the semantics of the <Preemption priority & Defending priority> 
parameter, defined in RFC3181,
are different than the semantics required for the admission priority 
parameter.

Furthermore, suppose that one will use the "<RPH Priority> Parameter", I am 
not sure
how a router, during the admission control process will be able to 
distinguish between the different priorities
that are differently specified for the different RPH namespaces. How a 
router will know when to use the DRSN namespace and when to use
the ETS name space. See also the e-mail from Percy:

"Within a DRSN domain, having multiple priority levels is permitted by the 
SIP RPH header. However, DRSN messages if carried over public IP networks, 
would be considered to be a single High priority class of traffic over the 
public domain."

Thus it is not clear to me how we could use the <RPH Priority> and
<Preemption priority & Defending priority>
parameters during the admission control process?

It will be better if we could have just one Admission priority parameter 
that could be used during the admission control process.
This means that we should have the possibility to use the sematincs of the 
Admission Priority policy element
given in:
http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.txt
That is:
       The admission control priority of the flow, in terms of access
       to resources set aside in order to provide higher probability of
       call completion to selected flows. Higher values represent
       higher Priority. A reservation established without an Admission
       Priority policy element is equivalent to a reservation
       established with an Admission Priority policy element whose
       Admission Priority value is 0.  "

As starting point we should currently allow at least 6 priorities instead of 
the current 3 priorities!

Best regards,
Georgios

----- Original Message ----- 
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>; 
<[email-masked]>; "Nsis (E-mail)" <[email-masked]>; "Attila 
Báder (IJ/ETH)" <[email-masked]>
Sent: Tuesday, January 31, 2006 1:04 PM
Subject: RE: [NSIS] RE: QSPEC - admission priority parameter

> Hi Georgios,
>
>> Yes I agree that the "<RPH Priority> can provide this mapping, but
>> what I would like to have is the possibility to use more than three
>> priorities in the Admission Priority parameter.
>> For more info, please see:
>> http://www.watersprings.org/pub/id/draft-lefaucheur-emergency-rsvp-00.txt
>
> We specified 3 levels of admission priority in the QSPEC I-D 
> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt based on the 
> requirements agreed to in several standards bodies, for example:
> [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority Levels for IP 
> Networks and Services," T1A1/2003-196 R3, November 2004.
>
> Furthermore, Section 9 "IANA Considerations" in the QSPEC I-D specifies:
>
>   Admission Priority Parameter (8 bits):
>   The following values are allocated by this specification:
>   0-2: assigned as specified in Section 7.2.6.2
>   The allocation policies for further values are as follows:
>   3-63: Standards Action
>   64-255: Reserved
>
> Therefore, ample space (256 possible admission priority parameter values) 
> is allocated for additional admission priority parameters to be defined, 
> should requirements arise.
>
> The procedures for the 16-bit admission priority parameter defined in 
> http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.txt 
> appears to derive heavily on procedures specified for RSVP Preemption 
> Priority:
> [RSVP-PREEMP]  Herzog, S., "Signaled Preemption Priority Policy Element", 
> RFC 3181, October 2001.
>
> The QSPEC I-D specifies preemption/defending priority parameters in 
> Section 7.2.7.1 (Preemption Priority> & <Defending Priority> Parameters 
> [RFC 3181]).
>
> Thanks,
> Regards,
> Jerry
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: ken carlberg <[email-masked]>
Date: Thu, 2 Feb 2006 12:18:19 -0300

just a thought, but it may be good to wait for the next version of  
the Le Faucheur draft comes out before digging deeply into a detailed  
discussion between it and the QSPEC.  Francois' -00 draft was  
presented in TSWG for the first time at the last IETF and I know he  
received some feedback since then, so it will be of interest to see  
how the draft evolves.

note: I don't wish to muzzle discussion, but just ask that we keep  
Francois's draft in perspective.  I would assume a new version will  
come out in the next month or so

regards,

-ken

On Feb 2, 2006, at 11:48 AM, Georgios Karagiannis wrote:

> Hi Jerry
>
> Please see bellow:
>> The procedures for the 16-bit admission priority parameter defined  
>> in http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency- 
>> rsvp-00.txt appears to derive heavily on procedures specified for  
>> RSVP Preemption Priority:
>> [RSVP-PREEMP]  Herzog, S., "Signaled Preemption Priority Policy  
>> Element", RFC 3181, October 2001.
>>
>> The QSPEC I-D specifies preemption/defending priority parameters  
>> in Section 7.2.7.1 (Preemption Priority> & <Defending Priority>  
>> Parameters [RFC 3181]).
>>
>
> But the http://www.ietf.org/internet-drafts/draft-lefaucheur- 
> emergency-rsvp-00.txt draft specifies that:
> "
> Thus the semantics of the <Preemption priority & Defending  
> priority> parameter, defined in RFC3181,
> are different than the semantics required for the admission  
> priority parameter.
>
> Furthermore, suppose that one will use the "<RPH Priority>  
> Parameter", I am not sure
> that are differently specified for the different RPH namespaces.  
> How a router will know when to use the DRSN namespace and when to use
> "Within a DRSN domain, having multiple priority levels is permitted  
> by the SIP RPH header. However, DRSN messages if carried over  
> public IP networks, would be considered to be a single High  
> priority class of traffic over the public domain."
>
> It will be better if we could have just one Admission priority  
> parameter that could be used during the admission control process.
> This means that we should have the possibility to use the sematincs  
> of the Admission Priority policy element
> given in:
> As starting point we should currently allow at least 6 priorities  
> instead of the current 3 priorities!
>
> Best regards,
> Georgios
>
>
>
>
>
>
>
> ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS"  
> <[email-masked]>
> <[email-masked]>; "Nsis (E-mail)" <[email-masked]>;  
> "Attila Báder (IJ/ETH)" <[email-masked]>
>> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt based  
>> on the requirements agreed to in several standards bodies, for  
>> example:
>> [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority  
>> Levels for IP Networks and Services," T1A1/2003-196 R3, November  
>> 2004.
>>
>> Therefore, ample space (256 possible admission priority parameter  
>> values) is allocated for additional admission priority parameters  
>> to be defined, should requirements arise.
>>
>> The procedures for the 16-bit admission priority parameter defined  
>> in http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency- 
>> rsvp-00.txt appears to derive heavily on procedures specified for  
>> RSVP Preemption Priority:
>> [RSVP-PREEMP]  Herzog, S., "Signaled Preemption Priority Policy  
>> Element", RFC 3181, October 2001.
>>
>> The QSPEC I-D specifies preemption/defending priority parameters  
>> in Section 7.2.7.1 (Preemption Priority> & <Defending Priority>  
>> Parameters [RFC 3181]).
>>
>> Thanks,
>> Regards,
>> Jerry
>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 2 Feb 2006 17:08:21 +0100

Hi Ken

The problem that I have is related to the fact that it is not easy to
use the <RPH Priority> and <Preemption priority & Defending priority>
parameters for admission control.
It should be possible to have a common parameter that could be used for 
admission priority.
I thought that the common parameter is the <Admission Priority> Parameter.

The only point that I am asking is to allow to have instead of three 
priorities, at least seven priorities in the
<Admission Priority> Parameter:

0 - best-effort priority flow
1 - normal priority flow
2 - high priority flow
3-  high2  priority flow
4 - high3 priority flow
5 - high4 priority flow
6 - high5 priority flow

Furthermore, the following sentence is required in Section 7.2.7.2 :
"A reservation established without an Admission
Priority policy element is equivalent to a reservation established
with an Admission Priority policy element whose
Admission Priority value is 1. "

Best Regards,
Georgios

----- Original Message ----- 
From: "ken carlberg" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>
Cc: "Ash, Gerald R ((Jerry)), ALABS" <[email-masked]>; 
<[email-masked]>; "Nsis ((E-mail))" <[email-masked]>; " Attila 
Báder (IJ/ETH) " <[email-masked]>
Sent: Thursday, February 02, 2006 4:18 PM
Subject: Re: [NSIS] RE: QSPEC - admission priority parameter

> just a thought, but it may be good to wait for the next version of  the Le 
> Faucheur draft comes out before digging deeply into a detailed  discussion 
> between it and the QSPEC.  Francois' -00 draft was  presented in TSWG for 
> the first time at the last IETF and I know he  received some feedback 
> since then, so it will be of interest to see  how the draft evolves.
>
> Francois's draft in perspective.  I would assume a new version will  come 
> out in the next month or so
>
> regards,
>
> -ken
>
>>> http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency- 
>>> rsvp-00.txt appears to derive heavily on procedures specified for  RSVP 
>>> Preemption Priority:
>> Furthermore, suppose that one will use the "<RPH Priority>  Parameter", I 
>> am not sure
>> "Within a DRSN domain, having multiple priority levels is permitted  by 
>> the SIP RPH header. However, DRSN messages if carried over  public IP 
>> networks, would be considered to be a single High  priority class of 
>> traffic over the public domain."
>>
>> This means that we should have the possibility to use the sematincs  of 
>> the Admission Priority policy element
>> given in:
>>> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt based  on 
>>> the requirements agreed to in several standards bodies, for  example:
>>> [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority  Levels for 
>>> IP Networks and Services," T1A1/2003-196 R3, November  2004.
>>>
>>> values) is allocated for additional admission priority parameters  to be 
>>> defined, should requirements arise.
>>>
>>> http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency- 
>>> rsvp-00.txt appears to derive heavily on procedures specified for  RSVP 
>>> Preemption Priority: