Subject: [NSIS] QSPEC - admission priority parameter

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 31 Jan 2006 11:21:26 +0100

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
   2 - best-effort 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 

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 31 Jan 2006 06:04:41 -0600

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

---

From: "Nguyen, An P CIV NCS NC2" <[email-masked]>
Date: Tue, 31 Jan 2006 09:11:23 -0500

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

Admission Priority:

   0 - high priority flow
   1 - normal priority flow

Why is that?

Best Regards,
Georgios

---

From: "Tarapore, Percy S, ALABS" <[email-masked]>
Date: Tue, 31 Jan 2006 08:29:25 -0600

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,

Regards,

An

-----Original Message-----

Admission Priority:

   0 - high priority flow
   1 - normal priority flow

Why is that?

Best Regards,
Georgios

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 31 Jan 2006 17:56:54 +0100

-- OFFLIST. 

hi jerry, 
hi georgios, 

i agree with georgios that we should align our work with the most recent enhancements to rsvp. 
as such, we should consider drafts like the one listed below. 

ciao
hannes 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Georgios Karagiannis
> Gesendet: Dienstag, 31. Januar 2006 12:07
> An: Ash, Gerald R (Jerry), ALABS
> Cc: Ash, Gerald R (Jerry), ALABS; Kappler, Cornelia; Nsis 
> (E-mail); Attila Báder (IJ/ETH)
> Betreff: Re: [NSIS] RE: QSPEC - admission priority parameter
> 
> Hi Jerry
> 
> 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.
> Best regards,
> ----- Original Message ----- 
> From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
> To: "Georgios Karagiannis" <[email-masked]>
> Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>; "Attila 
> Báder (IJ/ETH)" 
> <[email-masked]>; "Nsis (E-mail)" <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, January 31, 2006 11:38 AM
> Subject: [NSIS] RE: QSPEC - admission priority parameter
> 
> 
> > Hi Georgios,
> >
> > Note that Section 7.2.7.3 "<RPH Priority> Parameter" maps 
> all of the 
> > [SIP-PRIORITY] values into the QSPEC, including the DRSN values.
> >
> > Thanks,
> > Jerry
> >

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 31 Jan 2006 17:56:54 +0100

hi jerry, 

is is actually correct to carry the parameters carried in sip (as listed in draft-ietf-sip-resource-priority-10.txt)
in the qos signaling protocol? based on a previous mailing list discussion (a year ago) i got the impression that this is not correct.

instead the sip priority/preemption parameters are different to the one used in sip. rsvp, for example, provides only support for [RFC 3181] alike parameters (defined in section 7.2.7.1 of draft-ietf-nsis-qspec-08.txt). i don't recall that the parameters defined in draft-ietf-sip-resource-priority-10.txt are carried in rsvp. am i wrong? 

ciao
hannes

> Auftrag von Ash, Gerald R (Jerry), ALABS
> Gesendet: Dienstag, 31. Januar 2006 11:38
> An: Georgios Karagiannis
> Cc: Ash, Gerald R (Jerry), ALABS; Attila Báder (IJ/ETH); Nsis 
> (E-mail); Kappler, Cornelia
> Betreff: [NSIS] RE: QSPEC - admission priority parameter
> 
> Hi Georgios,
> 
> Note that Section 7.2.7.3 "<RPH Priority> Parameter" maps all 
> of the [SIP-PRIORITY] values into the QSPEC, including the 
> DRSN values.
> 
> Thanks,
> Jerry
>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 31 Jan 2006 10:04:08 -0500

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,

Regards,

An

-----Original Message-----

Admission Priority:

   0 - high priority flow
   1 - normal priority flow

Why is that?

Best Regards,
Georgios

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 31 Jan 2006 12:16:38 -0500

Hannes:

Let us make clear further before make a mess out of it as explained in my
earlier email.

RSVP deals with QoS properties of media payload, not of the call (object)
itself.

SIP call provides the indication of the call itself how a given call to be
admitted in the network from different priority category point of view. For
example, a high priority call can preempt a low priority call or a high
priority call will be handled first while a low priority call will be served
later. 

SIP level priority does NOT tell anything how each media of a given call
needs to be dealt with from priority point of view.

So, how do you expect that RSVP needs to carry the priority indication that
has been provided in the SIP call signaling messages whose only concern is
to deal with the call itself, not media?

Cheers,
Radhika

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

hi jerry, 

is is actually correct to carry the parameters carried in sip (as listed in
draft-ietf-sip-resource-priority-10.txt)
in the qos signaling protocol? based on a previous mailing list discussion
(a year ago) i got the impression that this is not correct.

instead the sip priority/preemption parameters are different to the one used
in sip. rsvp, for example, provides only support for [RFC 3181] alike
parameters (defined in section 7.2.7.1 of draft-ietf-nsis-qspec-08.txt). i
don't recall that the parameters defined in
draft-ietf-sip-resource-priority-10.txt are carried in rsvp. am i wrong? 

ciao
hannes

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 31 Jan 2006 19:17:51 +0100

hi radhika, 

i guess we are on the same page with our thoughts. 
in the past a bit confusion was caused by the fact that the same term (priority and preemption) is used in two different contexts. 

ciao
hannes

> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Dienstag, 31. Januar 2006 18:17
> An: Tschofenig, Hannes; Ash, Gerald R (Jerry), ALABS; 
> Georgios Karagiannis
> Betreff: RE: [NSIS] RE: QSPEC - admission priority parameter
> 
> Hannes:
>

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 31 Jan 2006 15:00:51 -0600

Hi Hannes,

> is actually correct to carry the parameters carried in sip 
> (as listed in draft-ietf-sip-resource-priority-10.txt)
> in the qos signaling protocol? based on a previous mailing 
> list discussion (a year ago) i got the impression that this 
> is not correct.

It is correct... I'm not sure what 'discussion' you're referring to a year ago.  There was an exchange with Ken Carlberg regarding the format, but that's it.  I believe the RSVP draft http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.txt was inspired by suggestions from An Nguyen of NCS (see acknowledgements), to align RSVP priority capabilities with NSIS capabilities in the 'priority signaling' area.  IMO there is no functionality proposed in the RSVP document not already possible in the NSIS/QSPEC.
 
> instead the sip priority/preemption parameters are different 
> to the one used in sip. rsvp, for example, provides only 
> support for [RFC 3181] alike parameters (defined in section 
> 7.2.7.1 of draft-ietf-nsis-qspec-08.txt). i don't recall that 
> the parameters defined in 

I agree, I'm not aware that sip-resource-priority parameters are carried (or proposed) as yet in RSVP.

Thanks,
Jerry