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

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 2 Feb 2006 13:45:00 -0600

Georgios,

I agree with Ken Carlberg that that we should keep the RSVP-priority draft http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.txt in perspective.  It is a new draft, in progress.  Furthermore, I believe the RSVP-priority draft was inspired by suggestions from An Nguyen of NCS (see acknowledgements), to align RSVP priority capabilities with NSIS capabilities in the 'priority signaling' area.  So perhaps comments should be directed to the RSVP-priority draft to align it with NSIS/QSPEC (if you think they're not aligned).

IMO there is no functionality proposed in the RSVP-priority document that is not already possible in the NSIS/QSPEC.

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

Of course the semantics are different.  The comment about the relationship to [RSVP-PREEMP] comes from the RSVP-priority document itself (see Acknowledgements "this document borrows heavily from some of the work of S. Herzog on Preemption Priority Policy Element [RSVP-PREEMP]").
 
> 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?

As you know, detailed behaviors and procedures are defined in QOSM drafts.  

General behaviors are discussed in the QSPEC I-D http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt. 

Section 5.2.1 specifies:

"  <Priority> = <Preemption Priority> <Defending Priority>
                <Admission Priority> <RPH Priority>

   <Preemption Priority> is the priority of the new flow compared with
   the defending priority of previously admitted flows.  Once a flow is
   admitted, the preemption priority becomes irrelevant.  <Defending
   Priority> is used to compare with the preemption priority of new
   flows.  For any specific flow, its preemption priority MUST always be
   less than or equal to the defending priority.  <Admission Priority>
   and <RPH Priority> provide an essential way to differentiate flows
   for emergency services, ETS, E911, etc., and assign them a higher
   admission priority than normal priority flows and best-effort
   priority flows."

Section 7.2.7 specifies:

"7.2.7.1 <Preemption Priority> & <Defending Priority> Parameters
      [RFC 3181]

   Preemption Priority: The priority of the new flow compared with the
   defending priority of previously admitted flows.  Higher values
   represent higher priority.

   Defending Priority: Once a flow is admitted, the preemption priority
   becomes irrelevant.  Instead, its defending priority is used to
   compare with the preemption priority of new flows.

   As specified in [RFC3181], <Preemption Priority> and <Defending
   Priority> are 16-bit integer values and both MUST be populated if the
   parameter is used.

7.2.7.2 <Admission Priority> Parameter [PRIORITY-RQMTS]

   High priority flows, normal priority flows, and best-effort priority
   flows can have access to resources depending on their admission
   priority value, as described in [PRIORITY-RQMTS], as follows:

   Admission Priority:

   0 - high priority flow
   1 - normal priority flow
   2 - best-effort priority flow

7.2.7.3 <RPH Priority> Parameter [SIP-PRIORITY]

   [SIP-PRIORITY] defines a resource priority header (RPH) with
   parameters "RPH Namespace" and "RPH Priority" combination,
   and if populated is applicable only to flows with high reservation
   priority, as follows:

   RPH Namespace:

   0 - dsn
   1 - drsn
   2 - q735
   3 - ets
   4 - wps
   5 - not populated

   RPH Priority:
   Each namespace has a finite list of relative priority-values.  Each
   is listed here in the order of lowest priority to highest priority:

   4 - dsn.routine
   3 - dsn.priority
   2 - dsn.immediate
   1 - dsn.flash
   0 - dsn.flash-override

   5 - drsn.routine
   4 - drsn.priority
   3 - drsn.immediate
   2 - drsn.flash
   1 - drsn.flash-override
   0 - drsn.flash-override-override

   4 - q735.4
   3 - q735.3
   2 - q735.2
   1 - q735.1
   0 - q735.0

   4 - ets.4
   3 - ets.3
   2 - ets.2
   1 - ets.1
   0 - ets.0

   4 - wps.4     
   3 - wps.3
   2 - wps.2
   1 - wps.1
   0 - wps.0"

Hence, <Preemption Priority> & <Defending Priority> behaviors are specified in [RFC3181], and are required for backward compatibility with [RFC3181].  <Admission Priority> (high, normal, best-effort) behaviors are specified in published standards/requirements from ATIS/ITU and other SDOs (e.g., see [PRIORITY-RQMTS]).  <RPH Priority> behaviors are specified in [SIP-PRIORITY] and if populated are applicable only to flows with high admission priority.

For example, <RPH Priority> values may be used to modify queuing or other behaviors of high-priority admissions, where an E911 voice call and an ETS data session are marked high priority, but different QoS mechanisms are used to support them.  Once again, this is a hypothetical example, specific behaviors for services are specified in NSIS/QSPEC-QOSM documents.
 
> 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!

Note that RSVP-priority is not doing away with <Preemption Priority> & <Defending Priority>, but adding admission priority.  So far, no RSVP mechanisms have been proposed to support <RPH Priority>.

If more (e.g., 6) admission priority elements are defined, this would have to modify current requirements for 3 admission priority elements.  If you wish to undertake such an effort, I think it should be done in concert with the other SDOs that have generated the current requirements.  Furthermore, [RFC3181]-specified <Preemption Priority> & <Defending Priority>, and [SIP-PRIORITY]-specified <RPH Priority> need to be maintained for backward compatibility.

Regards,
Jerry

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

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 9 Feb 2006 10:30:28 -0500

Sorry for the late response.

The RPH document contains the following statement, in the Introduction.
"   While the 'Resource-Priority' header field does not directly
   influence the forwarding behavior of IP routers or the use of
   communications resources such as packet forwarding priority,
   procedures for using this header field to cause such influence may be
   defined in other documents."

Janet

             "Roy, Radhika R."                                             
             <[email-masked]                                             
             m>                                                         To 
             Sent by:                  "Tarapore, Percy S, ALABS"          
             nsis-bounces@ietf         <[email-masked]>, "Nguyen, An P   
             .org                      CIV NCS NC2" <[email-masked]>, 
                                       Georgios Karagiannis                
                                       <[email-masked]>, "Ash,     
             01/31/2006 10:04          Gerald R (Jerry), ALABS"            
             AM                        <[email-masked]>,                     
                                       [email-masked],       
                                       Attila Báder (IJ/ETH)               
                                       <[email-masked]>         
                                                                        cc 
                                       "Nsis \(E-mail\)" <[email-masked]>   
                                                                   Subject 
                                       RE: [NSIS] QSPEC - admission        
                                       priority parameter                  

                                                                           

Folks:

SIP provides the indication for "PRIORITY" how a call (indication in
signaling messages) will be handled for admission in the network.

However, a SIP call may transfer more than one media: Audio (real-time),
video (real-time), and/or data (non-real-time). The call level priority in
signaling messages does NOT explain how each media (audio, video, data)
payload type will be handled to provide QoS in terms of PRIORITIES.

It may so happen audio may have to be treated with highest priority, while
video may have the lowest priority, etc.

In the light of the above, let us synthesize where the chips fall in terms
of providing "priority treatments" of different traffic over the IP network
from the call level to the IP packet/media payload level.

Cheers,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tarapore, Percy S, ALABS
Sent: Tuesday, January 31, 2006 9:29 AM
To: Nguyen, An P CIV NCS NC2; Georgios Karagiannis; Ash, Gerald R (Jerry),
ALABS; [email-masked]; Attila Báder (IJ/ETH)
Cc: Nsis (E-mail)
Subject: RE: [NSIS] QSPEC - admission priority parameter

The critical point to note is this. 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. The same is true for ETS
services. The rationale is that the total volume of High priority traffic
(whether it is ETS or WPS or DRSN) is dwarfed by the rest of the traffic
over public IP networks, especially Best Effort traffic.

Percy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nguyen, An P CIV NCS NC2
Sent: Tuesday, January 31, 2006 9:11 AM
To: 'Georgios Karagiannis'; Ash, Gerald R (Jerry), ALABS;
[email-masked]; Attila Báder (IJ/ETH)
Cc: Nsis (E-mail)
Subject: RE: [NSIS] QSPEC - admission priority parameter

Georgeois,

I think you are talking about three levels of admission priority in the
public networks with ETS being the highest.

And DRSN is a private network. Six levels of admission control for DRSN
should be allowed.

Regards,

An

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Georgios Karagiannis
Sent: Tuesday, January 31, 2006 5:21 AM
To: Ash, Gerald R (Jerry), ALABS; [email-masked]; Attila
Báder (IJ/ETH)
Cc: Nsis (E-mail)
Subject: [NSIS] QSPEC - admission priority parameter

Hello Jerry, Attila and Cornelia

In section 7.2.7.2 of the QSPEC template
draft you mention that the Admission Priority parameter
should have only three priorities, see below:

Admission Priority:

   0 - high priority flow
   1 - normal priority flow

Why is that?

Three admission priorities are not enough!
 Suppose that we would like to map the
6 priorities required by Defense Red Switched Network (DRSN)
([SIP-PRIORITY]) into
the admission priority parameter.
Then this will not be possible!
My proposal will be to allow the specification of a higher
 number of admission priorities!

Best Regards,
Georgios

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sat, 11 Feb 2006 16:10:17 -0500

It is understood.
 
NSIS is dealing with QoS "signaling." The question that remains is as
follows: What kinds QoS they in NSIS? 
 
Is it about the handling of a call admission with different "priority
levels" of applications, and is NOT about the QoS of media that is being
handled by the calls?
 
If it is so, what does it mean by "Priority" in SIP signaling in the context
of "Priority" in NSIS QoS signaling protocol ?
 
Can anyone help us here?
 
Best regards,
Radhika

  _____  

From: Janet P Gunn [mailto:[email-masked]]
Sent: Thu 2/9/2006 10:30 AM
To: Roy, Radhika R.
Cc: Nguyen, An P CIV NCS NC2; Attila Báder; [email-masked];
Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis; Nsis (E-mail);
[email-masked]; Tarapore, Percy S, ALABS
Subject: RE: [NSIS] QSPEC - admission priority parameter

Janet

             "Roy, Radhika R."                                            
             <[email-masked]                                            
             m>                                                         To

                                                                          

Folks:

Cheers,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of
Tarapore, Percy S, ALABS
Sent: Tuesday, January 31, 2006 9:29 AM
To: Nguyen, An P CIV NCS NC2; Georgios Karagiannis; Ash, Gerald R (Jerry),
ALABS; [email-masked]; Attila Báder (IJ/ETH)
Cc: Nsis (E-mail)
Subject: RE: [NSIS] QSPEC - admission priority parameter

Percy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of
Nguyen, An P CIV NCS NC2
Sent: Tuesday, January 31, 2006 9:11 AM
To: 'Georgios Karagiannis'; Ash, Gerald R (Jerry), ALABS;
[email-masked]; Attila Báder (IJ/ETH)
Cc: Nsis (E-mail)
Subject: RE: [NSIS] QSPEC - admission priority parameter

Georgeois,

Regards,

An

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of
Georgios Karagiannis
Sent: Tuesday, January 31, 2006 5:21 AM
To: Ash, Gerald R (Jerry), ALABS; [email-masked]; Attila
Báder (IJ/ETH)
Cc: Nsis (E-mail)
Subject: [NSIS] QSPEC - admission priority parameter

Admission Priority:

   0 - high priority flow
   1 - normal priority flow

Why is that?

Best Regards,
Georgios

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

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

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

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