Subject: [Dime] draft-ietf-dime-qos-parameters-01

From: ken carlberg <[email-masked]>
Date: Sat, 13 Oct 2007 11:34:26 -0400

Hi Hannes,

(brought to the list as requested, with slight modifications)

Sections 4.9, 4.10, and 4.11 as written reflect the references  
attributed to each section.  What I would like to suggest is to add  
some text that would reflect the objectives and priority related  
parameters of <draft-ietf-tsvwg-emergency-rsvp-03.txt> (soon to be  
version 4 with minor edits).

Concerning 4.9, leave it as is.  As I mentioned privately, our  
emergency-rsvp draft has no concept of defending or preemption  
priority.  Rather, we wanted to define a new RSVP policy element that  
only conveyed an admission priority along with another element that  
carried numeric-only representations of the alpha-numeric RPH  
Namespace and RPH Value.

Section 4.10 defines the semantics for the Admission Priority.  In  
addition, you follow Y.1571 and define four pre-existing values: 0  
(best effort), 1 (normal), 2 (high), and 255 (not used).  Our   
emergency-rsvp draft also has an Admission Priority field (of the  
same size of Section 4.10), but with no pre-established values.

Here we have a conundrum.  Do we overload the parameter of 4.10 and  
use it for both Y.1571 and emergency-rsvp, or do we define a new  
parameter and have it dedicated to our draft.  I would have a  
preference for the former.  And if we do go with the overloading  
option, I would assume that we may want to define a bit flag so that  
it identifies the parameter as applying to Y.1571 or the emergency- 
rsvp draft.

The structure and first part of Section 4.11 seems fine.  Our  
emergency-rsvp draft has the same Namespace & Priority fields along  
with the same size for each field.  The area of concern though is the  
latter part of the section where you state which permutations/cases  
are permissible.  I'm sorry if I missed earlier discussions on the  
DIME list, but I don't understand why one must have <Admission  
Priority> whenever <RPH Priority> is used.  Is this because this  
document relates to QoS and thus there must be some notion of desired  
service level as stated in Y.1571?  And perhaps a more general  
questions is: if I wanted to use Diameter to provide AAA only for RPH  
headers of SIP messages (with no conveyance of desired QoS), do I  
need to define a new AVP?

thoughts?

-ken

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 13 Oct 2007 19:09:24 +0300

Hi Ken,

thank you for the good feedback. Please find my comments below:

ken carlberg wrote:
> emergency-rsvp draft also has an Admission Priority field (of the same 
> size of Section 4.10), but with no pre-established values.
>
> it identifies the parameter as applying to Y.1571 or the 
> emergency-rsvp draft.
>
The term "overlapping" is not correct here. In some sense you are asking 
to generalize the attribute a bit by adding a "namespace" field.
Obviously, the definition in Section 4.10 had it's origin in Y.1571 and 
I am sure that other groups/SDO will define their own values (in the 
same fashion as you did).

Another question of interest with respect to this parameter is the 
following: In Section 3.1 of 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt 
you define more than just the Adm. Priority field. You also have the 
merge strategy defined. Do you believe that it would be important to add 
this field as well to the attribute? Is this something that could be 
treated as in independent attribute?

> headers of SIP messages (with no conveyance of desired QoS), do I need 
> to define a new AVP?
>
> thoughts?
>
We inherited the description from NSIS. I personally don't see why it is 
necessary to restrict the occurrence of these attributes in such a way. 
I will bring this to the NSIS mailing list for discussion.

I also got the impression that there is a little bit of mismatch in the 
registries created by IANA. Also a discussion between NSIS and TSVWG. In 
fact, the IANA consideration section of 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt 
reads like a snippet from a conversation between TSVWG and NSIS members....

Ciao
Hannes

---

From: ken carlberg <[email-masked]>
Date: Mon, 15 Oct 2007 09:37:22 -0400

Hannes,

>> Here we have a conundrum.  Do we overload the parameter of 4.10  
>> and use it for both Y.1571 and emergency-rsvp, or do we define a  
>> new parameter and have it dedicated to our draft.  I would have a  
>> option, I would assume that we may want to define a bit flag so  
>> that it identifies the parameter as applying to Y.1571 or the  
>> emergency-rsvp draft.
>>
> The term "overlapping" is not correct here. In some sense you are  
> asking to generalize the attribute a bit by adding a "namespace"  
> field.

ok, I wrote something and just deleted it because the term  
"namespace" can cause some confusion.  what I'm suggesting is perhaps  
an "SDO-space" field because the output of one SDO has pre-defined  
values.

my concern is that if we apply the admission priority field of 4.10  
to both Y.1571 and the tsvwg-emergency-rsvp draft, then we burden the  
latter with predefined non-opaque values that are tagged with a  
perceived level of QoS.  For example, given that a value of "0" ==  
"best effort" for Y.1571, what if I choose a value corresponding to  
"scavenger service", which is considered less that best effort?  My  
point being that I don't want to burden our tsvwg-emergency-rsvp  
draft with values set for Y.1571.

One way out of this is to distinguish the association of the  
admission priority of 4.10 by a bit field.  Another approach to the  
problem is to remove the pre-defined values from 4.10 and add some  
text stating that related work from other SDOs may have pre-defined  
values.  I'm open to either, or some other idea to address my concerns.

> Obviously, the definition in Section 4.10 had it's origin in Y.1571  
> and I am sure that other groups/SDO will define their own values  
> (in the same fashion as you did).

just to recap, tsvwg-emergency-rsvp hasn't defined any values for the  
field.

> following: In Section 3.1 of http://www.ietf.org/internet-drafts/ 
> draft-ietf-tsvwg-emergency-rsvp-03.txt you define more than just  
> the Adm. Priority field. You also have the merge strategy defined.  
> Do you believe that it would be important to add this field as well  
> to the attribute? Is this something that could be treated as in  
> independent attribute?

that's a tough question.  we have the merge field in cases where the  
rsvp policy attribute is used for multicast.  however, I don't see  
any text describing the application of Diameter to multicast in  
rfc-3588, the current diameter base draft, nor the QoS related  
diameter drafts.  without that text or further guidance from the  
Diameter group, I would be reluctant to add a merge field onto the  
attribute of 4.10.

>> emergency-rsvp draft has the same Namespace & Priority fields  
>> along with the same size for each field.  The area of concern  
>> though is the latter part of the section where you state which  
>> permutations/cases are permissible.  I'm sorry if I missed earlier  
>> discussions on the DIME list, but I don't understand why one must  
>> have <Admission Priority> whenever <RPH Priority> is used.  Is  
>> this because this document relates to QoS and thus there must be  
>> some notion of desired service level as stated in Y.1571?  And  
>> perhaps a more general questions is: if I wanted to use Diameter  
>> to provide AAA only for RPH headers of SIP messages (with no  
>> conveyance of desired QoS), do I need to define a new AVP?
>>
>> thoughts?
>>
> We inherited the description from NSIS. I personally don't see why  
> it is necessary to restrict the occurrence of these attributes in  
> such a way. I will bring this to the NSIS mailing list for discussion.
>
> I also got the impression that there is a little bit of mismatch in  
> the registries created by IANA. Also a discussion between NSIS and  
> TSVWG. In fact, the IANA consideration section of http:// 
> www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt  

some of us have had early discussions a while back with the authors  
of the Qspec draft http://www.ietf.org/internet-drafts/draft-ietf- 
nsis-qspec-17.txt, but that draft seemed to stall and had been on  
last call for quite a long time.  we've had discussions about IANA  
considerations within TSVWG (I think mostly at the meetings, with  
recaps on the list) along with tapping our own experiences on the  
IANA considerations work done on the SIP Resource Priority header.

cheers,

-ken

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 15 Oct 2007 16:45:17 +0200

Hello,

>> conveyance of desired QoS), do I need to define a new AVP?

So we now have many protocols (rsvp-emergency, nsis-qspec, radius,  
diameter) that need to encode :
	(i) the RPH namespace as a numerical value
	(ii) the RPH priority as a numerical value.

Do we agree (as suggested in emergency-rsvp (*) ) that we would be  
better off with an IANA registry specifying these values (once for  
all protocols to use) instead of each protocol document re-specifying  
the encoding itself?

> such a way. I will bring this to the NSIS mailing list for discussion.

I also don't see reasons to restrict the combinations.

Thanks

Francois

PS: (*) emergency-rsvp-03 only discussed the RPH Namespace (but next  
version is intended to also discuss RPH Priority and propose that  
these values be also defined in an IANA registry)

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 15 Oct 2007 17:02:10 +0200

Ken and all,

> priority.  Rather, we wanted to define a new RSVP policy element  
> that only conveyed an admission priority along with another element  
> that carried numeric-only representations of the alpha-numeric RPH  
> Namespace and RPH Value.
>

I think section 4.9 is fine as it is.
The emergency-rsvp draft acknowledges the fact that the RSVP  
signaling messages may also contain an RFC3181 policy element  
(containing both a preemption priority and a defending priority). So  
this is all fine and consistent, I believe.

An alternative approach, for section 4.9, could have been to purely  
point to RFC3181 for the semantics and encodings of the preemption  
and defending priority field (without reproducing text). The  
objectives being to avoid duplication of text which can potentially  
lead to inconsistencies (e.g. if RFC3181 was to be updated one day).  
But the text as is will make the document much easier to read.

Francois

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Oct 2007 18:10:43 +0300

Hi Ken,

thanks for your quick response. Please find a few comments below:

ken carlberg wrote:
>> asking to generalize the attribute a bit by adding a "namespace" field.
>
> ok, I wrote something and just deleted it because the term "namespace" 
> can cause some confusion.  what I'm suggesting is perhaps an 
> "SDO-space" field because the output of one SDO has pre-defined values.
It seems that you are really looking at a vendor-specific registry that 
happens to include SDOs as well.
See http://www.iana.org/assignments/enterprise-numbers

>
> my concern is that if we apply the admission priority field of 4.10 to 
> both Y.1571 and the tsvwg-emergency-rsvp draft, then we burden the 
> point being that I don't want to burden our tsvwg-emergency-rsvp draft 
> with values set for Y.1571.
Right. Overloading values with a different semantic is not that great.

>
> One way out of this is to distinguish the association of the admission 
> priority of 4.10 by a bit field.  Another approach to the problem is 
> to remove the pre-defined values from 4.10 and add some text stating 
> that related work from other SDOs may have pre-defined values.  I'm 
> open to either, or some other idea to address my concerns.
The flag just provides you a way to differentiate between Y.1571 and the 
tsvwg-emergency-rsvp.
I am sure if we look at the work of some other SDOs then we will realize 
that they again have other values defined.

The question therefore really is (from a Diameter/RADIUS perspective):  
Do we want to have an attribute that has a generic name instead of 
creating specific variants of it.

The generic name would be "Admission Priority Parameter". When we have a 
generic attribute then we need to differentiate the semantic again by 
introducing a vendor-/SDO specific field.
Alternatively, one could create one attribute called "Admission Priority 
Parameter for Y.1541" and other one "Admission Priority Parameter for 
RFC TBD"
 From a 
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt 
point of view both approaches are fine.

So, do you envision that there are many other SDOs defining their own 
admission priorities?
Do you expect that additional information would be added to the 
admission priority field itself? I mentioned the "merge strategy" field 
in Section 3.1 of 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt. 
For further comments on it, see below.

>> and I am sure that other groups/SDO will define their own values (in 
>> the same fashion as you did).
>
>> merge strategy defined. Do you believe that it would be important to 
>> add this field as well to the attribute? Is this something that could 
>> be treated as in independent attribute?
>
> rsvp policy attribute is used for multicast.  however, I don't see any 
> text describing the application of Diameter to multicast in rfc-3588, 
> the current diameter base draft, nor the QoS related diameter drafts.  
> without that text or further guidance from the Diameter group, I would 
> be reluctant to add a merge field onto the attribute of 4.10.
Diameter does not really care too much about the type of traffic. 
Diameter is only providing the authorization and accounting 
functionality. I cannot tell whether it would make sense to allow the 
Diameter client to tell the Diameter server something about QoS 
reservation for the multicast traffic by indicating the merge strategy. 
Would this be useful for the Diameter server to know about? Would it 
make sense for the Diameter server to tell the Diameter client which 
type of merge strategy to use?

>>> with the same size for each field.  The area of concern though is 
>>> the latter part of the section where you state which 
>>> have <Admission Priority> whenever <RPH Priority> is used.  Is this 
>>> because this document relates to QoS and thus there must be some 
>>> notion of desired service level as stated in Y.1571?  And perhaps a 
>>> more general questions is: if I wanted to use Diameter to provide 
>>> AAA only for RPH headers of SIP messages (with no conveyance of 
>>> desired QoS), do I need to define a new AVP?
>>>
>>> thoughts?
>>>
>> We inherited the description from NSIS. I personally don't see why it 
>> is necessary to restrict the occurrence of these attributes in such a 
>> way. I will bring this to the NSIS mailing list for discussion.
>>
>> TSVWG. In fact, the IANA consideration section of 
> some of us have had early discussions a while back with the authors of 
> the Qspec draft 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-17.txt, but 
> that draft seemed to stall and had been on last call for quite a long 
> time.  we've had discussions about IANA considerations within TSVWG (I 
> think mostly at the meetings, with recaps on the list) along with 
> tapping our own experiences on the IANA considerations work done on 
> the SIP Resource Priority header.
>
Since I am not an author of draft-ietf-nsis-qspec-17.txt I cannot really 
comment. In fact I don't really care too much about these details as 
long as the Diameter work is able to move forward as planned.

Ciao
Hannes

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 15 Oct 2007 17:18:13 +0200

Ken and all,

> that it identifies the parameter as applying to Y.1571 or the  

It is not clear to me why we would need to signal anything different  
in terms of Admission Priority in NSIS, RSVP or DIAMETER/RADIUS. Is  
there any reason for this?

Assuming there is not, then I would say:
	* _if_ it is absolutely clear to everyone that the 4 values defined  
in Y.1571 are the only values that will be applicable to all networks  
ever, then all protocols could probably settle on those Y.1571 values.
	* _if_ it is not clear that these 4 values are the only ones that  
will ever be applicable to any network, then I would suggest that we  
take the same approach as for Preemption priority: ie just define the  
relative semantics ("Higher values represent higher Priority"). This  
would be equally applicable to NSIS, RSVP and DIAMETER/RADIUS.
And then it is up to the network operator to decide what values they  
actually use. One network administrator may decide to use the values  
recommended by Y.1571. Another operator may decide to use different  
values. This should not be hard-coded in any protocol spec. Again,  
this is the approach taken for the Preemption priority.

Does this make sense?

Thanks

Francois

---

From: <[email-masked]>
Date: Mon, 15 Oct 2007 10:37:09 -0500

>> the SIP Resource Priority header.

This is about to be sent to the IESG, the reason it has been 'stuck' is
based
upon the fact that the GIST document has been under IESG re-review. As
soon as
that is through, this document will be submitted to the IESG	.

John

---

From: <[email-masked]>
Date: Mon, 15 Oct 2007 10:38:48 -0500

Hi,

> "SDO-space" field because the output of one SDO has pre-defined
values.

The IETF has no formal definition on what constitutes an SDO.  You
either
have vendor extentions or formal IETF extensions.  I don't think we can
do 
anything about this in the WG. I think using the Enterprise Numbers in
IANA is the way to specify extensions outside of the IETF.

John

---

From: ken carlberg <[email-masked]>
Date: Mon, 15 Oct 2007 11:58:54 -0400

Hannes,

>> "namespace" can cause some confusion.  what I'm suggesting is  
>> perhaps an "SDO-space" field because the output of one SDO has pre- 
>> defined values.
> It seems that you are really looking at a vendor-specific registry  
> that happens to include SDOs as well.

ouch, no.  i think the thread is leading to a level of granular  
information that was not my intention.  At the worst, I would have  
just wanted to distinguish SDOs (and in particular, their priority  
related standards) *if* the need exists to do so within the parameter  
of 4.10.  (more below)

> The question therefore really is (from a Diameter/RADIUS  
> perspective):  Do we want to have an attribute that has a generic  
> name instead of creating specific variants of it.

brief answer, yes.

> The generic name would be "Admission Priority Parameter". When we  
> have a generic attribute then we need to differentiate the semantic  
> again by introducing a vendor-/SDO specific field.

only if we have pre-defined values as 4.10 as written now.  if we  
take out these values and perhaps follow the more general approach  
just described by Francois, then most likely no.

<snip>

> So, do you envision that there are many other SDOs defining their  
> own admission priorities?

yes. we have them in APCO, ITU, and others.

> admission priority field itself?

yes.  as we see in Y.1571 (and H.460.4), other SDOs have priority  
fields defined along with pre-defined values.  but again, I'm leaning  
to follow Francois's suggestion for 4.10 to "just define the relative  
semantics ("Higher values represent higher Priority")".

<snip>

>> that's a tough question.  we have the merge field in cases where  
>> the rsvp policy attribute is used for multicast.  however, I don't  
>> see any text describing the application of Diameter to multicast  
>> in rfc-3588, the current diameter base draft, nor the QoS related  
> functionality. I cannot tell whether it would make sense to allow  
> the Diameter client to tell the Diameter server something about QoS  
> reservation for the multicast traffic by indicating the merge  
> strategy. Would this be useful for the Diameter server to know  
> about? Would it make sense for the Diameter server to tell the  
> Diameter client which type of merge strategy to use?

well, we are speaking of receiver driven merges, so the server would  
be informing a merge point that is acting on behalf of an aggregate  
of receivers.  Perhaps its better to punt on this topic and rely on a  
separate Diameter draft to deal with multicast flows.

-ken

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Oct 2007 23:52:20 +0300

Hi Francois,

Francois Le Faucheur IMAP wrote:
> The emergency-rsvp draft acknowledges the fact that the RSVP signaling 
> messages may also contain an RFC3181 policy element (containing both a 
> preemption priority and a defending priority). So this is all fine and 
> consistent, I believe.
>
> point to RFC3181 for the semantics and encodings of the preemption and 
> defending priority field (without reproducing text). The objectives 
> being to avoid duplication of text which can potentially lead to 
> inconsistencies (e.g. if RFC3181 was to be updated one day). But the 
> text as is will make the document much easier to read.

I wonder whether this is more a comment towards 
draft-ietf-dime-qos-parameters-01 or draft-ietf-nsis-qspec-17.txt?
I understand that the merging strategy only comes from the multicast use 
case and hence it would be outside the scope of NSIS and hence it would 
not be useful to have just a reference from draft-ietf-nsis-qspec-17.txt 
to emergency-rsvp.

The most important question for me is whether the merging strategy would 
have to be included into the parameter of Section 4.9 and Section 4.10 
of draft-ietf-dime-qos-parameters-01.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Oct 2007 00:06:28 +0300

Here is a proposal:

In Section 4.11 of 
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt 
we currently have the following RPH Priority parameter:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           10          |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         RPH Namespace         | RPH Priority  |   (Reserved)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If we define a namespace for this parameter then we should define a 
namespace field for the Admission Priority parameter defined in Section 
4.10 as well. Currently, the parameter has the following structure:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           9           |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Admis.Priority|                  (Reserved)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We would change it to:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           9           |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Namespace             | Admis.Priority|  (Reserved)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The "Namespace" field would indicate the context of the subsequent 
Admission Priority values.

What do you think about the proposal?

Would it make sense to make this change in draft-ietf-nsis-qspec-17.txt 
and in draft-ietf-tsvwg-emergency-rsvp-03.txt as well?

Ciao
Hannes

ken carlberg wrote:
>>> perhaps an "SDO-space" field because the output of one SDO has 
>>> pre-defined values.
> only if we have pre-defined values as 4.10 as written now.  if we take 
> out these values and perhaps follow the more general approach just 
> described by Francois, then most likely no.
>
> <snip>
>
>> strategy. Would this be useful for the Diameter server to know about? 
>> Would it make sense for the Diameter server to tell the Diameter 
>> client which type of merge strategy to use?
>
> be informing a merge point that is acting on behalf of an aggregate of 
> receivers.  Perhaps its better to punt on this topic and rely on a

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 16 Oct 2007 13:49:39 +0200

Hello Hannes,

On 15 Oct 2007, at 23:06, Hannes Tschofenig wrote:

> Here is a proposal:
>
> In Section 4.11 of http://www.ietf.org/internet-drafts/draft-ietf- 
> dime-qos-parameters-01.txt we currently have the following RPH  
> Priority parameter:
>
>       0                   1                   2                   3
> namespace field for the Admission Priority parameter defined in  
> Section 4.10 as well.

Not with the QoS signaling model I was picturing.

In my mind, we do not want each and every router to have to  
understand "application level" priority requirements, nor be aware of  
every SDO's latest decision on whether 3, 4 or 10 levels of  
priorities is the way to go. To that end, the approach we have been  
following for rsvp-emergency (and I think is in line with RFC2753  
defining "A Framework for Policy-based Admission Control") is the  
following:
	* there are a number of fundamental network mechanisms that every  
router involved in QoS signaling need to understand (i.e. preemption  
priority, admission priority). To allow routers to enforce those  
mechanisms, the corresponding information element needs to be  
included in the QoS signaling. Those contain semantics that are  
directly understandable by routers (e.g. Preemption Priority 10 is  
allowed to bump Defending Priority 5).
	* routers involved in QoS signaling need not understand application  
level requirements (ie routers do not necessarily know what is DSN's  
"flash-override-override", or the counterpart in other countries)
	* Policy Decision Points (typically at the edge of the network as  
well as at administrative boundaries) understand "application level  
requirements" and are responsible for mapping those into network  
mechanisms (i.e. preemption priority, admission priority).
	* To facilitate the mapping of "application-level" requirements into  
network mechanisms by PDPs, the application-level requirements (as  
specified for SIP usage) can be conveyed inside the QoS signaling  
protocol. However, they are intended to be relayed to PDPs and are  
not intended to be understood by each and every QoS signaling router.

With such a model in mind, the proposal would be:

	* dime-qos-parameters, nsis-qspec and rsvp-emergency all define an  
information element containing an "RPH namespace" field and an "RPH  
priority" field. These fields contain numerical values that are  
specified in an IANA registry.

	* dime-qos-parameters, nsis-qspec both define an information element  
containing a "Admission Priority" field and a "Defending Priority"  
field. These field contain numerical values whose semantics is in  
line with RFC3181 (ie "higher values represent higher priority").

	* dime-qos-parameters, nsis-qspec and rsvp-emergency all define an  
information element containing an "RPH namespace" field. This field  
contains a numerical value whose semantic is "higher values represent  
higher priority".

Does the QoS model described above make sense to you too?
What about the corresponding proposal?

Cheers

Francois

PS: I'm keeping the "Merging" question out for now. I think it is  
worth converging on the high level model first, and I'd like to think  
more about the Merging.

> Currently, the parameter has the following structure:
>
>       0                   1                   2                   3
> Would it make sense to make this change in draft-ietf-nsis- 
> qspec-17.txt and in draft-ietf-tsvwg-emergency-rsvp-03.txt as well?
>
> Ciao
> Hannes
>
>
>
> ken carlberg wrote:
>> Hannes,
>>
>>> It seems that you are really looking at a vendor-specific  
>>> registry that happens to include SDOs as well.
>> related standards) *if* the need exists to do so within the  
>> parameter of 4.10.  (more below)
>>
>>> have a generic attribute then we need to differentiate the  
>>> semantic again by introducing a vendor-/SDO specific field.
>>
>> fields defined along with pre-defined values.  but again, I'm  
>> leaning to follow Francois's suggestion for 4.10 to "just define  
>> the relative semantics ("Higher values represent higher Priority")".
>>
>> <snip>
>>
>>>> the rsvp policy attribute is used for multicast.  however, I  
>>>> don't see any text describing the application of Diameter to  
>>>> multicast in rfc-3588, the current diameter base draft, nor the  
>>>> QoS related diameter drafts.  without that text or further  
>>>> guidance from the Diameter group, I would be reluctant to add a  
>>>> merge field onto the attribute of 4.10.
>>> the Diameter client to tell the Diameter server something about  
>>> QoS reservation for the multicast traffic by indicating the merge  
>> well, we are speaking of receiver driven merges, so the server  
>> would be informing a merge point that is acting on behalf of an  
>> aggregate of receivers.  Perhaps its better to punt on this topic  
>> and rely on a separate Diameter draft to deal with multicast flows.
>>
>> -ken
>>
>>
>>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Oct 2007 16:44:06 +0300

Hi Francois,

thanks for your response. Please find my comment below:

Francois Le Faucheur IMAP wrote:
> In my mind, we do not want each and every router to have to understand 
> "application level" priority requirements, nor be aware of every SDO's 
> latest decision on whether 3, 4 or 10 levels of priorities is the way 
> to go. To that end, the approach we have been following for 
> rsvp-emergency (and I think is in line with RFC2753 defining "A 
> Framework for Policy-based Admission Control") is the following:
> mechanisms, the corresponding information element needs to be included 
> in the QoS signaling. Those contain semantics that are directly 
> understandable by routers (e.g. Preemption Priority 10 is allowed to 
> bump Defending Priority 5).
>     * routers involved in QoS signaling need not understand 
> application level requirements (ie routers do not necessarily know 
> what is DSN's "flash-override-override", or the counterpart in other 
> countries)
>     * To facilitate the mapping of "application-level" requirements 
> into network mechanisms by PDPs, the application-level requirements 
> (as specified for SIP usage) can be conveyed inside the QoS signaling 
> protocol. However, they are intended to be relayed to PDPs and are not 
> intended to be understood by each and every QoS signaling router.
>

I think the usage of the term "application-level" requirements and 
non-application level requirements is quite confusing unless you speak 
about codecs in the context of the application layer (which nobody does 
so far).

Hence, the entire question finally comes down to the issue of what do 
you assume a router to understand and what would other entities (such as 
Diameter proxies and Diameter servers) understand.

You are essentially saying that the router should only support the 
functionality described in
* RFC 3181, and
* Section 3.1 of 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt

If I understand you correctly then the text in Section 3.2 that lists 
the functionality of RFC 4412 (e.g., "dsn.flash-override") is just 
passed inside RSVP to be then forwarded towards the backend 
infrastructure. Then, it is interpreted there and translated to 
something the router understands (namely the functionality listed in the 
bullet list above). Finally, it is sent back to the router in a 
different form, namely the values of dsn.flash-override, etc. (which are 
just constants for priority values) are mapped into the priority values 
described in Section 3.1 of 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt.

> specified in an IANA registry.
That's fine. The parameter is there already but there is just the 
mismatch between draft-ietf-tsvwg-emergency-rsvp and draft-ietf-nsis-qspec.

>
>     * dime-qos-parameters, nsis-qspec both define an information 
> element containing a "Admission Priority" field and a "Defending 
> Priority" field. These field contain numerical values whose semantics 
> is in line with RFC3181 (ie "higher values represent higher priority").
Draft-ietf-nsis-qspec and draft-ietf-dime-qos-parameters-01 have a field 
for Admission Priority but it is focused on the Y.1571 defined values only.
draft-ietf-tsvwg-emergency-rsvp does not define a stand-alone "Defending 
Priority" field either.

The "Defending  Priority" field is only defined  via Herzog, S., 
"Signaled Preemption Priority Policy Element", RFC 3181, October 2001.

I think this requirement calls only for 
http://gim.org.pl/rfcs/rfc3181.html functionality. With this document, 
however, the "Definding Priority" is only used in context of the 
Preemption Priority.

> contains a numerical value whose semantic is "higher values represent 
I believe that this is incorrect. There is no order imposed on the 
namespace field.

> Does the QoS model described above make sense to you too?
I still have to understand a few things better....
> What about the corresponding proposal?
Seen from a higher layer we are essentially dealing with an issue of 
extensibility here. In your model you assume that the router only 
understands a certain set of QoS profiles (namely one where the 
parameters of RFC X and Y) are understood. That's fine. You would like 
to foward parameters that aren't understood to the backend 
infrastructure in order to get them translated to something you 
understand. That's fine. Within the Diameter QoS attribute document we 
allow the Diameter client to tell the Diameter server what it 
understands. The level of understanding may, however, vary. I believe 
that there are two cases:
* The Diameter client receives a request from a QoS signaling protocol, 
such as RSVP. A message may contain objects where the Diameter client 
knows how todo the encapsulation but it realizes that the Resource 
Management function cannot deal with them. To have a specific example: 
Let's assume some SDO defines new priority elements and registers them. 
The Diameter QoS client (or the RMF) does not know how to interpret the 
specific priority values but it understands the object as such -- it 
understands that this is a priority parameter.
* The second case is where the Diameter client obtains something from 
the QoS signaling protocol that it does not understand at all. This case 
is not covered and if we would like to support your model (in case I 
understood it correctly) then this means that we have to dump the 
received information into a container and forward it along with the 
other information to the Diameter server. The Diameter server would then 
try to understand it.

Do I correctly capture the problem?

Ciao
Hannes
>> Would it make sense to make this change in 
>> draft-ietf-nsis-qspec-17.txt and in 
>> draft-ietf-tsvwg-emergency-rsvp-03.txt as well?
>>
>> Ciao
>> Hannes
>>
>>
>>
>> ken carlberg wrote:
>>> Hannes,
>>>
>>> leaning to follow Francois's suggestion for 4.10 to "just define the 
>>> relative semantics ("Higher values represent higher Priority")".
>>>
>>> <snip>
>>>
>>> of receivers.  Perhaps its better to punt on this topic and rely on 
>>> a separate Diameter draft to deal with multicast flows.
>>>
>>> -ken
>>>
>>>
>>>
>>
>>

---

From: ken carlberg <[email-masked]>
Date: Tue, 16 Oct 2007 10:45:24 -0400

Hannes,

>>     * dime-qos-parameters, nsis-qspec and rsvp-emergency all  
>> define an information element containing an "RPH namespace" field.  
>> This field contains a numerical value whose semantic is "higher  
>> values represent higher priority".
>>

correct.  Unless I misunderstood the point Francois was trying to  
make, the values in the RPH Namespace field only act as registered  
identifiers and have no sense of priority associated with them.  Its  
the corresponding RPH Priority field associated with the RPH  
Namespace field that contains ordered values and that would be of the  
semantic "higher values represent higher priority".

> Seen from a higher layer we are essentially dealing with an issue  
> of extensibility here. In your model you assume that the router  
> only understands a certain set of QoS profiles (namely one where  
> the parameters of RFC X and Y) are understood. That's fine. You  
> would like to foward parameters that aren't understood to the  
> backend infrastructure in order to get them translated to something  
> you understand. That's fine. Within the Diameter QoS attribute  
> document we allow the Diameter client to tell the Diameter server  
> what it understands. The level of understanding may, however, vary.  
> I believe that there are two cases:
> * The Diameter client receives a request from a QoS signaling  
> protocol, such as RSVP. A message may contain objects where the  
> Diameter client knows how todo the encapsulation but it realizes  
> that the Resource Management function cannot deal with them. To  
> have a specific example: Let's assume some SDO defines new priority  
> elements and registers them. The Diameter QoS client (or the RMF)  
> does not know how to interpret the specific priority values but it  
> understands the object as such -- it understands that this is a  
> priority parameter.
> * The second case is where the Diameter client obtains something  
> from the QoS signaling protocol that it does not understand at all.  
> This case is not covered and if we would like to support your model  
> (in case I understood it correctly) then this means that we have to  
> dump the received information into a container and forward it along  
> with the other information to the Diameter server. The Diameter  
> server would then try to understand it.
>

At first glance, the above examples seem reasonable, although I  
personally wouldn't view them as the baseline reason (ie, not  
understanding certain parameters) for having network layer Admission  
Priority and upper layer RPH Namespace and RPH Priority values (but  
I'll let Francois give a more definitive response).

A third scenario that I think is more likely to occur is that a PDP  
receives two ingress signaled messages with Admission Priority values  
(ie, policy elements), and each having been derived from different  
RPH Namespace.Priority tuples.  The PDP would have a local policy  
that *may* rank one RPH Namespace.Priority tuple higher than  
another.  By including the upper layer information in the RSVP  
message as another policy element, the PDP can then make a more  
informed decision about the network layer Admission Priority values.

Now if this triggers the question of why don't we go back to your  
original suggestion of embedding the RPH info into the Admission  
Priority policy elements, then I would add to what Francois said  
earlier and say that we don't do this in order to maintain  
flexibility.  At this point in time, we recognize the RPH values as  
*one* candidate for upper layer information.  Later on, there may be  
others, at which point we simply define a new policy element to  
convey that information with no change made to the Admission Priority  
element.

-ken

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 16 Oct 2007 16:54:37 +0200

Hi,

On 16 Oct 2007, at 15:44, Hannes Tschofenig wrote:

>>> If we define a namespace for this parameter then we should define  
>>> a namespace field for the Admission Priority parameter defined in  
>>> Section 4.10 as well.
>>
>> understand "application level" priority requirements, nor be aware  
>> of every SDO's latest decision on whether 3, 4 or 10 levels of  
>> priorities is the way to go. To that end, the approach we have  
>> been following for rsvp-emergency (and I think is in line with  
>> RFC2753 defining "A Framework for Policy-based Admission Control")  
>> is the following:
>>     * there are a number of fundamental network mechanisms that  
>> every router involved in QoS signaling need to understand (i.e.  
>> preemption priority, admission priority). To allow routers to  
>> enforce those mechanisms, the corresponding information element  
>> needs to be included in the QoS signaling. Those contain semantics  
>> that are directly understandable by routers (e.g. Preemption  
>> Priority 10 is allowed to bump Defending Priority 5).
>> what is DSN's "flash-override-override", or the counterpart in  
>> other countries)
>>     * Policy Decision Points (typically at the edge of the network  
>> as well as at administrative boundaries) understand "application  
>> level requirements" and are responsible for mapping those into  
>> network mechanisms (i.e. preemption priority, admission priority).
>>     * To facilitate the mapping of "application-level"  
>> requirements into network mechanisms by PDPs, the application- 
>> level requirements (as specified for SIP usage) can be conveyed  
>> inside the QoS signaling protocol. However, they are intended to  
>> be relayed to PDPs and are not intended to be understood by each  
>> and every QoS signaling router.
>>
>
> non-application level requirements is quite confusing unless you  
> speak about codecs in the context of the application layer (which  
> nobody does so far).

By "application-level" requirements I mean something along the lines  
of the "Resource Priority" discussed in RFC4412. Something along the  
lines of:
	* "this call is being established by a Senior Vice President and is  
therefore more important than mine" or
	* "this call is being established by a 4-star general and is  
therefore more important than Hannes's call'" or
	* "this call is being established by a Fire Brigade captain"

The point is we probably don't want routers to have to be aware of  
how to handle a call form a VP, a 4-star general or a Fire-Brigade  
captain.

>
> Hence, the entire question finally comes down to the issue of what  
> do you assume a router to understand and what would other entities  
> (such as Diameter proxies and Diameter servers) understand.
>
> * Section 3.1 of http://www.ietf.org/internet-drafts/draft-ietf- 
> tsvwg-emergency-rsvp-03.txt

Right.

>
> If I understand you correctly then the text in Section 3.2 that  
> lists the functionality of RFC 4412 (e.g., "dsn.flash-override") is  
> just passed inside RSVP to be then forwarded towards the backend  
> something the router understands (namely the functionality listed  
> in the bullet list above).

Right.

> Finally, it is sent back to the router in a different form, namely  
> the values of dsn.flash-override, etc. (which are just constants  
> for priority values) are mapped into the priority values described  
> in Section 3.1 of http://www.ietf.org/internet-drafts/draft-ietf- 
> tsvwg-emergency-rsvp-03.txt.

... and or into RFC3181.

For example:
	* RPHnamespace1/RPHpriority1 may get mapped into RFC3181 mechanism  
(ie a Preemption priority + Defending priority)
	* RPHnamespace2/RPHpriority2 may get mapped into rsvp-emergency  
section 3.1 mechanism (ie an Admission priority)
	* RPHnamespace3/RPHpriority3 may get mapped into RFC3181 mechanism  
(ie a Preemption priority + Defending priority) and an rsvp-emergency  
section 3.1 mechanism (ie an Admission priority).

>> define an information element containing an "RPH namespace" field  
>> and an "RPH priority" field. These fields contain numerical values  
>> that are specified in an IANA registry.
>> Priority" field. These field contain numerical values whose  
>> semantics is in line with RFC3181 (ie "higher values represent  
>> higher priority").
> Draft-ietf-nsis-qspec and draft-ietf-dime-qos-parameters-01 have a  
> field for Admission Priority but it is focused on the Y.1571  
> defined values only.
> draft-ietf-tsvwg-emergency-rsvp does not define a stand-alone  
> "Defending Priority" field either.

My text above contained a very unfortunate typo (Sorry!). It was  
meant to read :
	* dime-qos-parameters, nsis-qspec both define an information element  
containing a "Preemption Priority" field and a "Defending Priority"  
field. These field contain numerical values whose semantics is in  
line with RFC3181 (ie "higher values represent higher priority").

>> values represent higher priority".

My text above contained a another very unfortunate typo (I can't  
believe this. Sorry!). It was meant to read :
	* dime-qos-parameters, nsis-qspec and rsvp-emergency all define an  
information element containing an "Admission Priority" field. This  
field contains a numerical value whose semantic is "higher values  
represent higher priority".

Does this make sense now?

> I still have to understand a few things better...

Hope the proposal without typos makes more sense.

> the parameters of RFC X and Y) are understood.

right.

> That's fine. You would like to foward parameters that aren't  
> understood to the backend infrastructure in order to get them  
> translated to something you understand.

right.

> That's fine. Within the Diameter QoS attribute document we allow  
> the Diameter client to tell the Diameter server what it understands.
> The level of understanding may, however, vary. I believe that there  
> are two cases:

We want to consider two cases:

	-A- the SDO defines some network CAC handling that cannot be  
supported using the existing NSIS/RSVP mechanisms (ie Preemption  
Priority & Defending Priority, Admission Priority). Then IETF would  
have to specify a new additional mechanism and NSIS/RSVP signaling  
extensions for the corresponding new network mechanism. So far, all  
discussions about emergency and military handling concluded that we  
can support all the identified requirements with the above mechanisms.

	-B- the SDO defines a particular mapping like "in my environments I  
need 3 levels of preemption priorities and 2 levels of admission  
priority and here's how my calls get mapped on those...". Then I  
would hope that this has no impact on NSIS, RSVP or Diameter. The  
case brought up by An is interesting. the fact that ITU changed from  
Y.1571 to Y.2171 (or something else tomorrow) should not affect  
Diameter, NSIS or RSVP, should it?

Cheers

Francois

PS: apologies again for the confusion created by the earlier typos.

>> worth converging on the high level model first, and I'd like to  
>> think more about the Merging.
>>
>>
>>
>>
>>>      |M|r|r|r|           9           |r|r|r|r|           
>>> 1            |
>>>      |M|r|r|r|           9           |r|r|r|r|           
>>> 1            |
>>> The "Namespace" field would indicate the context of the  
>>> subsequent Admission Priority values.
>>>
>>>> information that was not my intention.  At the worst, I would  
>>>> have just wanted to distinguish SDOs (and in particular, their  
>>>> priority related standards) *if* the need exists to do so within  
>>>> the parameter of 4.10.  (more below)
>>>>
>>>>> perspective):  Do we want to have an attribute that has a  
>>>>> generic name instead of creating specific variants of it.
>>>>
>>>> brief answer, yes.
>>>>
>>>>> The generic name would be "Admission Priority Parameter". When  
>>>>> we have a generic attribute then we need to differentiate the  
>>>> only if we have pre-defined values as 4.10 as written now.  if  
>>>> we take out these values and perhaps follow the more general  
>>>> approach just described by Francois, then most likely no.
>>>>
>>>> <snip>
>>>>
>>>>> So, do you envision that there are many other SDOs defining  
>>>>> their own admission priorities?
>>>>
>>>> yes.  as we see in Y.1571 (and H.460.4), other SDOs have  
>>>> priority fields defined along with pre-defined values.  but  
>>>> again, I'm leaning to follow Francois's suggestion for 4.10 to  
>>>> "just define the relative semantics ("Higher values represent  
>>>> higher Priority")".
>>>>
>>>> <snip>
>>>>
>>>>>> that's a tough question.  we have the merge field in cases  
>>>>>> where the rsvp policy attribute is used for multicast.   
>>>>>> however, I don't see any text describing the application of  
>>>>>> Diameter to multicast in rfc-3588, the current diameter base  
>>>>>> draft, nor the QoS related diameter drafts.  without that text  
>>>>>> or further guidance from the Diameter group, I would be  
>>>>>> reluctant to add a merge field onto the attribute of 4.10.
>>>>> Diameter does not really care too much about the type of  
>>>>> traffic. Diameter is only providing the authorization and  
>>>>> accounting functionality. I cannot tell whether it would make  
>>>>> sense to allow the Diameter client to tell the Diameter server  
>>>>> something about QoS reservation for the multicast traffic by  
>>>>> indicating the merge strategy. Would this be useful for the  
>>>>> Diameter server to know about? Would it make sense for the  
>>>>> Diameter server to tell the Diameter client which type of merge  
>>>>> strategy to use?
>>>>
>>>> aggregate of receivers.  Perhaps its better to punt on this  
>>>> topic and rely on a separate Diameter draft to deal with  
>>>> multicast flows.
>>>>
>>>> -ken
>>>>
>>>>
>>>>
>>>
>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Oct 2007 10:58:11 +0200

Hi Francois,

thanks for your mail. Please find a few comments below:

Francois Le Faucheur IMAP wrote:
>>> (as specified for SIP usage) can be conveyed inside the QoS 
>>> signaling protocol. However, they are intended to be relayed to PDPs 
>>> and are not intended to be understood by each and every QoS 
>>> signaling router.
>>>
>>
>     * "this call is being established by a Senior Vice President and 
> is therefore more important than mine" or
The interesting thing with the resource priority work is that you cannot 
express these type of things.
Additionally, the resource priority header claims to be conveying the 
priority information for evaluation at the other communication end point.

>
> The point is we probably don't want routers to have to be aware of how 
> to handle a call form a VP, a 4-star general or a Fire-Brigade captain.
Well. In some sense that's what Diameter would do for you. The Diameter 
server does the authentication step, then when the Diameter client asks 
for a particular authorization decision information stored at the 
Diameter server (e.g., roles associated with a specific user) is used to 
make a decision.

I believe that the current resource priority work just does not talk 
about how to make this authorization step....

I agree with you that the router should not need to worry about the 
roles of users in a phone call.

>> you assume a router to understand and what would other entities (such 
>> as Diameter proxies and Diameter servers) understand.
>>
>> something the router understands (namely the functionality listed in 
>> the bullet list above).
>
> Right.
>
>> the values of dsn.flash-override, etc. (which are just constants for 
>> priority values) are mapped into the priority values described in 
>> Section 3.1 of 
Correct.

> section 3.1 mechanism (ie an Admission priority).
Ok.

>>>     * dime-qos-parameters, nsis-qspec and rsvp-emergency all define 
>>> an information element containing an "RPH namespace" field and an 
>>> "RPH priority" field. These fields contain numerical values that are 
>> field for Admission Priority but it is focused on the Y.1571 defined 
>> values only.
> My text above contained a very unfortunate typo (Sorry!). It was meant 
> to read :
> element containing a "Preemption Priority" field and a "Defending 
Correct.

>
>
>>
>>>
>>>     * dime-qos-parameters, nsis-qspec and rsvp-emergency all define 
>>> an information element containing an "RPH namespace" field. This 
Yep; That makes sense.

> Hope the proposal without typos makes more sense.
Yep.

>> parameters of RFC X and Y) are understood.
>
> right.
>
>> That's fine. Within the Diameter QoS attribute document we allow the 
>> Diameter client to tell the Diameter server what it understands.
>> Diameter client knows how todo the encapsulation but it realizes that 
>> the Resource Management function cannot deal with them. To have a 
>> specific example: Let's assume some SDO defines new priority elements 
>> and registers them. The Diameter QoS client (or the RMF) does not 
>> know how to interpret the specific priority values but it understands 
>> the object as such -- it understands that this is a priority parameter.
>
Correct.

>
>     -B- the SDO defines a particular mapping like "in my environments 
> I need 3 levels of preemption priorities and 2 levels of admission 
> priority and here's how my calls get mapped on those...". Then I would 
> hope that this has no impact on NSIS, RSVP or Diameter. The case 
> brought up by An is interesting. the fact that ITU changed from Y.1571 
> to Y.2171 (or something else tomorrow) should not affect Diameter, 
> NSIS or RSVP, should it?
The problem is that I don't really know the details of the Y.1571 to 
Y.2171 change. I would have to read through the documents.

Ideally, if you have a different "profile" then you might want to define 
this somewhere. For example, consider the priority values specified by 
the IEEE for some of their link layers. When you want to use Diameter 
todo the authorization then it would be good to know what the allowed 
value range is.

While we have a way to express the namespace for RPH Priority parameter 
we don't have it for the Admission Priority parameter. That was one of 
the open issues I saw.

Based on the discussion we had I do believe that there is a need to 
document the basic model described earlier in this mail in some 
document. This is more or less a framework aspect that might be good to 
capture. I don't think it is a protocol aspect or something that causes 
interoperability issues but still good to highlight.

Ciao
Hannes

>> the QoS signaling protocol that it does not understand at all. This 
>> case is not covered and if we would like to support your model (in 
>> case I understood it correctly) then this means that we have to dump 
>> the received information into a container and forward it along with 
>> the other information to the Diameter server. The Diameter server 
>> would then try to understand it.
>>