Subject: [NSIS] QSPEC-issue (GK-2)

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 11 Oct 2006 13:04:34 +0200

Description of issue
Change <QoS Class> to QSPEC-2 parameter

Submitter name: Georgios Karagiannis
Submitter email address: [email-masked] Date first submitted:
11.10.2006
Reference:  
Comment type: T
Priority: 'S'
Section: Various
Rationale/Explanation of issue:

It is not realistic to assume that the QNI is able to know which 
network technologies (Diffserv, MPLS, Y.1541) are supported 
on the end-to-end path.
If the "QoS Class" parameter is considered to be a QSPEC-1 parameter
then it will mean that all QNEs located on the 
end-to-end path must support the Diffserv and MPLS and Y.1541 technologies. 
This is unrealistic.

Requested change:
The <QoS Class> parameter must be a QSPEC-2 parameter.

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 11 Oct 2006 12:51:55 -0400

Description of issue: Delete the value-based <QoS Class> to parameter of Y.1541 and DSTE  from QSPEC

Submitter name: Radhika R. Roy
Submitter email address: [email-masked] 
Date first submitted: 11.10.2006
Reference: 
Comment type: T
Priority: 'S'
Section: Various
Rationale/Explanation of issue:

The value-based QOS Classes of Y.1541 and DSTE are incompatible with non-value based QOS classes of DiffServ interoperability. Moreover, this spec deal with non-value-based generic parameters, not any implementation-specific value-base parameters. The implementation-specific values of any parameters that the users will use as they deem to be necessary are the not the objectives of this draft to start with.
 
Why does the draft will deal with implementation-specific value-based QOS classes in this generic QSPEC any implementation is not for standardization?
 
To deal with so-called value-based QOS class parameters, the stand-alone separate drafts need to be written as they are non-interoperable. 
 
The mixing of interoperable items with the non-interoperable items in the same draft is a serious problem of QSPEC, and it breaks all norms of standardization because interoperability the main purpose for all standards. If the standard itself creates non-interoperability problems unnecessarily, it is against the norms of IETF.
 
Requested change:

Any reference of the value-based <QoS Class> parameter of Y.1541 and DSTE must be removed from QSPEC.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Oct 2006 21:05:14 +0200

I support Georgios.

I think it is unrealistic to assume that Y.1541 and DSTE behavior (as 
required for strictly interpreting these parameters) is implemented in 
every QNE.

Ciao
Hannes

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Oct 2006 07:42:09 +0200 (MEST)

Description of issue
NOTIFY may carry a QSPEC object

12.10.2006
Section: 6.4.5

In Section 6.4.5 it is mentioned:
"No QSPEC is carried in the NOTIFY message. The NOTIFY message carries
only the Session ID and a INFO_SPEC with the error code as described in
[QOS-SIG]."

Note that a NOTIFY is allowed to carry a QSPEC, see QoS-NSLP draft.
Therefore, it should be allowed for QOSMs to specify, alo in the case of
preemption, to send a QSPEC together with the INFO_SPEC object.

Furthermore please note that a NOTIFY does not carry a Session ID.

Requested change:
Modify text in Section 6.4.5 (Preemption):
From:
"No QSPEC is carried in the NOTIFY message. The NOTIFY message carries
only the Session ID and a INFO_SPEC with the error code as described in
[QOS-SIG]."

INTO:
"The NOTIFY message carries an  INFO_SPEC with the error code as
described in [QOS-SIG]. A QOSM specification document may specify wheter
a NOTIFY also carries a QSPEC object."

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Oct 2006 08:54:34 +0200 (MEST)

Description of issue
Setting "R" and "Q" flags for  <Priority> during QSPEC Stacking &
Tunneling

Section: 6.2 & 6.3.2

In case of QSPEC tunneling & stacking there are situations where the
<Priority> parameter carried by an Initiator QSPEC is strictly
interpreted by the edges of a local QOSM domain. The local QSPEC
assoiated with this QOSM does not carry the <Priority> parameter, but
the local QOSM domain by using procedures specified in the QOSM can
solve the preemption issue by using the <priority> parameter stored at
the edges of the loal QOSM domain.
It is not lear if in this case the ""R"" and "Q" flags carried by
the <Priority> parameter have to be set. In my opinion, in this case the
R and Q fags should not be set.

Requested change:
Include in Section 6.2 the following paragraph.
"In the situation that a <Priority> parameter carried by an Initiator
QSPEC is strictly interpreted by the edges of a local QOSM aware domain
and the local QOSM defines how the preemption issue is solved within the
local QOSM aware domain, then the "R" and "Q" flags carried by the
<Priority> parameter in the Initiator QSPEC SHOULD NOT be set, even if
the <Priority> parameter is not carried by the stacked local QSPEC,
which is associated with the local QOSM."

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Oct 2006 09:16:09 +0200 (MEST)

Description of issue
Unclear how "R" and "Q" are set during QSPEC Stacking &
Tunneling

This issue is somehow also related to QSPEC issue (GK-4).
Section 6.3.2 is unclear on defining how the "R" flags and "Q" flags
of QSPEC-1 parameters carried by the Initiator QSPEC are set during
QSPEC Stacking &
Tunneling.
Section 6.2 includes some more information but it is still unclear. This
is also related to QSPEC issue (GK-4), see below:
In case of QSPEC tunneling & stacking there are situations where the
<Priority> parameter carried by an Initiator QSPEC is strictly
interpreted by the edges of a local QOSM domain. The local QSPEC
assoiated with this QOSM does not carry the <Priority> parameter, but
the local QOSM domain by using procedures specified in the QOSM can
solve the preemption issue by using the <priority> parameter stored at
the edges of the loal QOSM domain.
It is not lear if in this case the ""R"" and "Q" flags carried by
the <Priority> parameter have to be set. In my opinion, in this case the
R and Q fags should not be set.

Requested change:

Specify in Sections 6.2 and 6.3.2, in a more clear way, when and how the
"R" and "Q" flags are set when QSPEC Stacking & Tunneling is used.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Oct 2006 10:03:35 +0200 (MEST)

Description of issue
Possibilty for a QNI to include and send a QSPEC-1 parameter as an
optional parameter, i.e., with "M" and "N" flags unset.

Currently is specified that QSPEC-1 parameters are always initiated by
QNI as being mandatory parameters. In some situations this might not be
efficient and useful enough.
Suppose that a QNI can provide a remapping between QSPEC-1 parameter, say
Token Bucket to another QSPEC-1 parameter, say Bandwidth.
Then the QNI can for example include the Tocken Bucket parameter as
QSPEC-1 parameter and in addition it can inlcude the Bandwidth parameter
as QSPEC-2 parameter, the M flag is set to 0 and the N flag is not yet
set.
The on path QNEs could then, if possible use the Token Bucket parameter,
but if not then it can use the available Bandwidth parameter and set the
"R" and "Q" flags associated with the Tocken Bucket parameter.
In this way the remapping is actually done by the QNI, which is a cleaner
way to solve the remapping problem. However, if a QOSM defines to remap
the Token Bucket to another parameter, then the N flag in the available
Bandwidth parameter is set and also the "R" and "Q" flags associated
with the Tocken Bucket parameter are set.
In this way the QNI will have more information on how the remapping of
the parameter took place. If the N flag in the Bandwidth is not set and
the "R" and "Q" flags associated with the Tocken Bucket parameter
are set then the QNI knows that the remapping of the Tocken Bucket
parameter has been done by using the available Bandwidth value provided
by QNI. The QNI could then be more certain about what kind of Token
Bucket remapping took place.

Requested change:

This issue is related to various sections:
* Specify that QNI is allowed to use the "N" flag and to set the "M"
flag to "0" for QSPEC-1 parameters.
* A QNI may remap an initial QSPEC-1 parameter to another QSPEC-1
parameter, say remapped QSPEC-1 parameter. The remapped QSPEC-1
parameter carries the "M" flag set to "0" and the "N" flag is
unset. Both QSPEC-1 parameters may be included in the QSPEC. However,
the remapped QSPEC-1 parameter is included only when the initial QSPEC-1
parameter is available.
* A QNE that receives the QSPEC uses, if possible, the initial QSPEC-1
parameter, otherwise it can use the remapped QSPEC-1 parameter and set
the "R" and "Q" flags associated with the initial QSPEC-1  parameter.
In this way the remapping is actually done by the QNI. However, if a QOSM
defines to remap the initial QSPEC-1 parameter to another parameter,
then the "N" flag in the remapped QSPEC-1 parameter is set.
Furthermore,  also the "R" and "Q" flags associated with the initial
QSPEC-1 parameter are set.

In this way the QNI will receive more information on how the remapping of
the initial QSPEC-1 parameter took place. If the "N" flag in the
remapped QSPEC-1 parameter is not set and the "R" and "Q" flags
associated with the initial QSPEC-1 parameter are set then the QNI knows
that the remapping of the initial QSPEC-1 parameter has been done by
using the remapped QSPEC-1 parameter value provided by QNI. The QNI is
then more certain about the way of how the initial QSPEC-1 parameter is
remapped.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Oct 2006 10:42:15 +0200 (MEST)

Description of issue
Allow to set preemption priority to normal priority when preemption
parameter is illegal

Section: 6.1

In last paragraph of Section 6.1 is emphasized that:

"In some casee a ONE may need to reject a reservation because of
possible inompatibilities among QSPEC parameters. One example is that
some parameters may be illegal (e.g., preemption in the U.S.  PSTN). In
such a case a QNE must reject a reservation where preemption cannot be
accomodated."

Why should the QNE always reject the reservations in these cases. I think
that this should be decided by the QOSM specifications.

Requested change:

Please change the last paragraph in Section 6.1:

FROM:
"In some casee a ONE may need to reject a reservation because of
possible inompatibilities among QSPEC parameters. One example is that
some parameters may be illegal (e.g., preemption in the U.S.  PSTN). In
such a case a QNE must reject a reservation where preemption cannot be
accomodated."

INTO:
"In some cases a ONE may need to reject or remap a reservation request
because of possible incompatibilities among QSPEC parameters. One
example is that some parameters may be illegal (e.g., preemption in the
U.S.  PSTN). In such a case a QNE must either reject the reservation
request or consider that the reservation request does not carry a
preemption priority parameter, i.e., remap to normal priority, when the
requested preemption priority cannot be accomodated. This procedure must
be specified by the QOSM specification."

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 17 Oct 2006 10:51:49 +0200

Hi Georgios and Hannes, 

see my previous post regarding how to handle these parameters in CL. 

The proposal for CL is that a CL QNE has an algorithm that tells it which QoS Class parameters are "high class" and whcih are "low class". If they are high class, they will receive CL treatment. If they are low class, they receive best effort. 

This way QSPECs based on "QoS Class" QOSMs get as reasonable a treatment as one can expect, and at the same time I dont see a CL QNE being overburdened by this task.

Cornelia 

> -----Ursprüngliche Nachricht-----
> Von: Hannes Tschofenig [mailto:[email-masked]] 
> Gesendet: Mittwoch, 11. Oktober 2006 21:05
> An: Georgios Karagiannis
> Cc: [email-masked]
> Betreff: Re: [NSIS] QSPEC-issue (GK-2)
> 
> I support Georgios.
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 10:57:24 +0200

Hi Cornelia

This is not possible!
How a QNE will know how to map a PHB class into a Y.1541 class?
It is impossible to come up with a reasonable mapping.

The only solution on this is to mandate that all QNEs implement Diffserv and
MPLS and Y.1541.
In this way NSIS will never be used and deployed.

Best regards,
Georgios

> -----Original Message-----
> From: Kappler, Cornelia [mailto:[email-masked]] 
> Sent: dinsdag 17 oktober 2006 10:52
> To: Hannes Tschofenig; Georgios Karagiannis
> Cc: [email-masked]
> Subject: AW: [NSIS] QSPEC-issue (GK-2)
> 
> Hi Georgios and Hannes, 
> 
> The proposal for CL is that a CL QNE has an algorithm that 
> tells it which QoS Class parameters are "high class" and 
> whcih are "low class". If they are high class, they will 
> receive CL treatment. If they are low class, they receive 
> best effort. 
> 
> This way QSPECs based on "QoS Class" QOSMs get as reasonable 
> a treatment as one can expect, and at the same time I dont 
> see a CL QNE being overburdened by this task.
> 
> Cornelia 
> 
> > > Submitter name: Georgios Karagiannis Submitter email address: 
> > > [email-masked] Date first
> > submitted:
> > > 11.10.2006
> > > Reference:  
> > > Comment type: T
> > > Priority: 'S'
> > > Section: Various
> > > network technologies (Diffserv, MPLS, Y.1541) are 
> supported on the 
> > > end-to-end path.
> > > then it will mean that all QNEs located on the end-to-end 
> path must 
> > > support the Diffserv and MPLS and
> > Y.1541 technologies. 
> > > This is unrealistic.
> > > 
> > > Requested change:

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 17 Oct 2006 11:22:52 +0200

i share the same oppinion as georgios.
xiaoming

-- 
Cheers,

Xiaoming
--
http://user.informatik.uni-goettingen.de/~fu

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 17 Oct 2006 11:28:34 +0200

Hi Georgios, 

it is a matter of interpreting what "reasonable mapping" means. 

For me, reasonable means that (i) the original idea of the parameter value should be preserved as much as possible, but on (ii) a QNE implementing a different set of paraemeters (QOSM) should not be burdened with too much knowledge / processing that is outside its own QOSM.

Regarding CLS I gave a possible answer balancing (i) and (ii) which is deployable (in fact it is quite simple).

I cannot answer how to map PHB class into Y.1541 class since I am not an expert in this.  

Cornelia 

> Von: Georgios Karagiannis [mailto:[email-masked]] 
> Gesendet: Dienstag, 17. Oktober 2006 10:57
> An: Kappler, Cornelia; 'Hannes Tschofenig'
> Cc: [email-masked]
> Betreff: RE: [NSIS] QSPEC-issue (GK-2)
> 
> Hi Cornelia
> 
> This is not possible!

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 11:33:20 +0200

Hi Cornelia

The reasonable maping can only be accomplished between:
Token Bucket (peak rate) => Bandwidth
Higher (than normal) priority => Normal priority
Lower (than normal) priority => Normal priority

In my opinion other types of remappings (of other parameters) 
are either impossible or useless!

Best Regards,
Georgios

> Sent: dinsdag 17 oktober 2006 11:29
> To: Georgios Karagiannis; Hannes Tschofenig
> Cc: [email-masked]
> For me, reasonable means that (i) the original idea of the 
> parameter value should be preserved as much as possible, but 
> on (ii) a QNE implementing a different set of paraemeters 
> (QOSM) should not be burdened with too much knowledge / 
> processing that is outside its own QOSM.
> 
> Regarding CLS I gave a possible answer balancing (i) and (ii) 
> which is deployable (in fact it is quite simple).
> 
> > The only solution on this is to mandate that all QNEs implement 
> > Diffserv and MPLS and Y.1541.
> > > The proposal for CL is that a CL QNE has an algorithm 
> that tells it 
> > > which QoS Class parameters are "high class" and whcih are "low 
> > > class". If they are high class, they will receive CL 
> treatment. If 
> > > they are low class, they receive best effort.
> > > 
> > > This way QSPECs based on "QoS Class" QOSMs get as reasonable a 
> > > treatment as one can expect, and at the same time I dont see a CL 
> > > QNE being overburdened by this task.
> > > 
> > > Cornelia
> > >

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 17 Oct 2006 12:00:49 +0200

Hi Georgios, 

why do you think for example mapping Y.1541 Class 0 to PHB Expedited Service (I think this is how its called) is useless? This is better than having a Y.1541 Class 0 signaling arrive at a DiffSer domin and being ignored!?

Cornelia

> Gesendet: Dienstag, 17. Oktober 2006 11:33

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 14:27:47 +0200

Hi Cornelia

Sorry, but in this way you define two new parameters and that are
high class and low class!
In addition to the 13 mandatory parameters we will add other two. 
Thus the QNEs will have to support 15 mandatory parameters.
Sorry but it becomes more complicated, than when just 
having 13 mandatory parameters.

Best Regards,
Georgios

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 17 Oct 2006 09:02:57 -0400

Folks:

As we talked a million times before, so-called Y.1541 QOS classes are based "values" like 50-ms, 100-ms, etc. while DiffSeve PHBs are based on "characteristics" of services that are not dependent on any specific "values."

How can one map between "apples" and "oranges?"

We cannot "generalize" all those "arbitrary" things in one single draft as it stands on this QSPEC draft.

Kindly see the "QSPEC Issue RRR-1."

The only way to solve this problem is to write separate drafts for specific implementations for Y.1541 and DSTE QOS classes separately. Unlike RSVP QOS classes, these two QOS classes depend on some "arbitrarily" defined some specific "values" decoupling from the applications' needs with one-to-one mapping. Here the confusions some: Mixing between "apples" and "oranges."

As Georgios and others explained, there is no light at the end of this tunnel unless deals with the suggestion provided in "QSPEC Issue RRR-1."

Otherwise, as Georgios and others pointed out, more you dig-in technically for proper interworking for implementations, more mud will be split all around.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kappler, Cornelia
Sent: Tuesday, October 17, 2006 6:01 AM
To: Georgios Karagiannis; Hannes Tschofenig
Cc: [email-masked]
Subject: AW: [NSIS] QSPEC-issue (GK-2)

Hi Georgios, 

Cornelia

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 17 Oct 2006 16:00:44 +0200

Dear all,

Without wanting to get too hung up on exactly which parameters should be
'globally supported/mandatory/[insert your favourite terminology here]' and
which should not, I'd like to re-iterate what I believe is the benefit of
the Type-1 parameter concept in the first place.

In several external reviews of NSIS (within the IETF but partly outside the
working group), it's my impression that there was a real worry about how the
flexibility that the original QoS-NSLP/QSPEC concepts allowed would harm
interoperability - in other words, that it would be commonplace for people
to issue reservations which were completely not understood by downstream
domains. (Just look at the early review minutes from Korea, for example.) 

The Type-1 parameter concept is an attempt (IMHO a good one) to address that
problem, by providing a minimal parameter set which everyone understands. We
can argue about which parameters should be Type-1, but I think that if the
concept itself is dropped and we just allow a free-for-all in QSPEC
parameters, then it will be a major barrier to getting this work through the
forthcoming review stages.

For the sake of argument, I'd be interested to know if there are people who
really can argue that the token bucket (or bandwidth, which is just a
degenerate token bucket really) cannot be handled correctly as a Type-1
parameter. If they cannot, I think that this would at least validate the
conceptual structure of the QSPEC - we could still discuss the other
parameters.

Lars -

I'm a bit confused about your references to MEF7. MEF7 is about an
information model for network management; I wouldn't really expect the QSPEC
to be relevant here. Surely the appropriate comparison is with MEF10
("Ethernet Services Attributes"). Not entirely surprisingly, MEF10 expresses
its bandwidth profiles in terms of token bucket parameters. Doesn't that
rather prove the point?

cheers,

Robert H.

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 17 Oct 2006 16:00:44 +0200

Dear all,

Lars -

cheers,

Robert H.

---

From: <[email-masked]>
Date: Tue, 17 Oct 2006 17:02:47 +0300

Georgios,

Cornelia explained how she thought it would work with CL.  I agree
with her that I think that should be a sufficient solutions.

Is your objection based upon the total number of Mandatory Parameters?
Too many parameters in general?

John 

>From: ext Georgios Karagiannis [mailto:[email-masked]] 
>Sent: 17 October, 2006 05:28
>To: 'Kappler, Cornelia'; 'Hannes Tschofenig'
>Cc: [email-masked]
>Subject: RE: [NSIS] QSPEC-issue (GK-2)
>
>Hi Cornelia
>
>Sorry, but in this way you define two new parameters and that 
>are high class and low class!
>Sorry but it becomes more complicated, than when just having 
>13 mandatory parameters.
>
>
>Best Regards,
>Georgios
>
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 16:11:22 +0200

Hi John

I realy do not understand how this will solve the QoS class 
remapping problems.
What is "high class" for "DSTE QoS class" and for "PHB QoS class" and for
"Y.1541 class"
and the same for "low class"?

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: dinsdag 17 oktober 2006 16:03
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Cornelia explained how she thought it would work with CL.  I 
> agree with her that I think that should be a sufficient solutions.
> 
> >Sorry, but in this way you define two new parameters and 
> that are high 
> >class and low class!
> tells it 
> >> class". If they are high class, they will receive CL treatment. If 
> >> treatment as one can expect, and at the same time I dont 
> see a CL QNE

---

From: <[email-masked]>
Date: Tue, 17 Oct 2006 17:11:36 +0300

Robert,

I think this is a good summary. I agree with it.  I haven't
taken a strong stance on which are the mandatory, however
we need to resolve that issue as well.

John 

>From: ext Robert Hancock [mailto:[email-masked]] 
>Sent: 17 October, 2006 07:01
>To: [email-masked]
>Subject: [NSIS] a comment on type-1/type-2 QSPEC parameters
>
>Dear all,
>
>Without wanting to get too hung up on exactly which parameters 
>should be 'globally supported/mandatory/[insert your favourite 
>terminology here]' and which should not, I'd like to 
>re-iterate what I believe is the benefit of the Type-1 
>parameter concept in the first place.
>
>In several external reviews of NSIS (within the IETF but 
>partly outside the working group), it's my impression that 
>there was a real worry about how the flexibility that the 
>original QoS-NSLP/QSPEC concepts allowed would harm 
>interoperability - in other words, that it would be 
>commonplace for people to issue reservations which were 
>completely not understood by downstream domains. (Just look at 
>the early review minutes from Korea, for example.) 
>
>The Type-1 parameter concept is an attempt (IMHO a good one) 
>to address that problem, by providing a minimal parameter set 
>which everyone understands. We can argue about which 
>parameters should be Type-1, but I think that if the concept 
>itself is dropped and we just allow a free-for-all in QSPEC 
>parameters, then it will be a major barrier to getting this 
>work through the forthcoming review stages.
>
>For the sake of argument, I'd be interested to know if there 
>are people who really can argue that the token bucket (or 
>bandwidth, which is just a degenerate token bucket really) 
>cannot be handled correctly as a Type-1 parameter. If they 
>cannot, I think that this would at least validate the 
>conceptual structure of the QSPEC - we could still discuss the 
>other parameters.
>
>Lars -
>
>I'm a bit confused about your references to MEF7. MEF7 is 
>about an information model for network management; I wouldn't 
>really expect the QSPEC to be relevant here. Surely the 
>appropriate comparison is with MEF10 ("Ethernet Services 
>Attributes"). Not entirely surprisingly, MEF10 expresses its 
>bandwidth profiles in terms of token bucket parameters. 
>Doesn't that rather prove the point?
>
>cheers,
>
>Robert H.
>
>

---

From: <[email-masked]>
Date: Tue, 17 Oct 2006 17:17:33 +0300

OK, so I think your point on the manditory parameters could be classified
as something like this.  If we have manditory parameters, how to map
from one QoS model to another, especially when the QoS models are 
using relative values - meaning no absolute values.  If all QoS Models
had 3 traffic classes - roughly high, medium and low - then it would be
very simple to handle. However, different QoS models might have trouble
to map from one model to another.

Is that roughly want you are saying?

John

>Sent: 17 October, 2006 07:11
>To: Loughney John (Nokia-NRC/Helsinki); 
>[email-masked]; [email-masked]
>Cc: [email-masked]

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 16:33:17 +0200

Hi John 

Okay, but this is something different then what we are curreently discussing
in this thread!
Cornelia actually proposes two additional parameters that are different 
then the 3 mandatory QOS classes defined already.

Please consider the following:
According to the QSPEC template a QNI can include a Y.1541 class parameter. 
Now a QNE that receives this parameter MUST interpret it, since this
parameter is mandatory.
Consider now that the QNE can support only Diffserv. 
How this Diffserv QNE could interpret the Y.1541 class parameter?

Best Regards,
Georgios

> Sent: dinsdag 17 oktober 2006 16:18
> OK, so I think your point on the manditory parameters could 
> be classified as something like this.  If we have manditory 
> parameters, how to map from one QoS model to another, 
> especially when the QoS models are using relative values - 
> meaning no absolute values.  If all QoS Models had 3 traffic 
> classes - roughly high, medium and low - then it would be 
> very simple to handle. However, different QoS models might 
> have trouble to map from one model to another.
> 
> remapping 
> >problems.
> >What is "high class" for "DSTE QoS class" and for "PHB QoS 
> class" and 
> >for
> >"Y.1541 class"

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 17 Oct 2006 11:34:31 -0400

Even that is problematic.

I think that the mapping between "token bucket (peak rate)" and "bandwidth"
can generally be accomplished.

But a mapping to "Normal Priority" requires a definition of "Normal
Priority".

Is "Normal Priority" defined by
[<Preemption Priority>] [<Defending Priority>]
or by
[<Admission Priority>] [<RPH Priority>]?

There is a"Normal" value for [<Admission Priority>], but there is no
"Normal" for [<Preemption Priority>] [<Defending Priority>], nor for [<RPH
Priority>].

The most benign mapping you can make with Preemption/Defending is to set
the [<Preemption Priority>] to the lowest legal value (so it can't preempt
anything) and the [<Defending Priority>] to the highest legal value (so
nothing can preempt it).

But my understanding is that the organizations that USE preemption are more
likely to want to define "Normal" as [<Preemption Priority>] to the lowest
legal value (so it can't preempt anything) and the [<Defending Priority>]
to the lowest legal value (so EVERYTHING ELSE can preempt it).  But this is
equivalent to mapping it to "low priority" in most senses of the word.

Either way, I can see all sorts of unintended consequences for a call that
crosses multiple domains (and thus go through multiple mappings)  with
different (or no) priority schemes

What should happen in a domain which supports neither form of priority?

In most other protocols, the general rule for  dealing with unknown
priority structures is
"if you don't understand/support it, don't mess with it".  In other words,
"ignore it".

This is true for the Precedence parameter (as well as specialized use of
the CPC parameter) in SS7, and the RPH in SIP.

I still don't understand why "ignore it" is forbidden for Priority in
QSPEC.

Don't forget that unauthorized use of "Priority" has the potential for
abuse.

Janet

"Georgios Karagiannis" <[email-masked]> wrote on 10/17/2006

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 17:42:35 +0200

Hi Janet

I think that I agree with your observations.
Please also note that Jukka proposed a good solution to this problem!

Best regards,
Georgios

> From: Janet P Gunn [mailto:[email-masked]] 
> Sent: dinsdag 17 oktober 2006 17:35
> To: Georgios Karagiannis
> Cc: [email-masked]; 'Kappler, Cornelia'
> But a mapping to "Normal Priority" requires a definition of 
> "Normal Priority".
> 
> [<Preemption Priority>] [<Defending Priority>] or by 
> There is a"Normal" value for [<Admission Priority>], but 
> there is no "Normal" for [<Preemption Priority>] [<Defending 
> Priority>], nor for [<RPH
> Priority>].
> 
> The most benign mapping you can make with 
> Preemption/Defending is to set the [<Preemption Priority>] to 
> the lowest legal value (so it can't preempt
> anything) and the [<Defending Priority>] to the highest legal 
> value (so nothing can preempt it).
> 
> But my understanding is that the organizations that USE 
> preemption are more likely to want to define "Normal" as 
> [<Preemption Priority>] to the lowest legal value (so it 
> can't preempt anything) and the [<Defending Priority>] to the 
> lowest legal value (so EVERYTHING ELSE can preempt it).  But 
> this is equivalent to mapping it to "low priority" in most 
> senses of the word.
> 
> Either way, I can see all sorts of unintended consequences 
> for a call that crosses multiple domains (and thus go through 
> multiple mappings)  with different (or no) priority schemes
> 
> In most other protocols, the general rule for  dealing with 
> unknown priority structures is "if you don't 
> understand/support it, don't mess with it".  In other words, 
> "ignore it".
> 
> This is true for the Precedence parameter (as well as 
> specialized use of the CPC parameter) in SS7, and the RPH in SIP.
> 
> I still don't understand why "ignore it" is forbidden for 
> Priority in QSPEC.
> 
> Don't forget that unauthorized use of "Priority" has the 
> potential for abuse.
> 
> Janet
> 
> "Georgios Karagiannis" <[email-masked]> wrote on 
> 10/17/2006 05:33:20 AM:
> 
> > Hi Cornelia
> >
> > Higher (than normal) priority => Normal priority Lower 
> (than normal) 
> > priority => Normal priority
> >
> > In my opinion other types of remappings (of other parameters) are 
> > either impossible or useless!
> >
> > Best Regards,
> > Georgios
> >
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 17 Oct 2006 19:40:47 +0300

Janet,

>can generally be accomplished.

I agree, so I think we could carry this forward.
>There is a"Normal" value for [<Admission Priority>], but there 
>is no "Normal" for [<Preemption Priority>] [<Defending 
>The most benign mapping you can make with Preemption/Defending 
>is to set the [<Preemption Priority>] to the lowest legal 
>value (so it can't preempt
>[<Preemption Priority>] to the lowest legal value (so it can't 
>preempt anything) and the [<Defending Priority>] to the lowest 
>legal value (so EVERYTHING ELSE can preempt it).  But this is 
>Either way, I can see all sorts of unintended consequences for 
>a call that crosses multiple domains (and thus go through 

So, for the priority bit, should we have a general rule to silently
pass if not understood?  How do people feel about this?

John

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 17 Oct 2006 12:22:28 -0500

> >understand/support it, don't mess with it".  In other words, 

If a QNI populates priority (either preemption, admission, RPH, etc.)
for its QOSM then the QNI/QOSM requirement for the reservation is that
QNEs will implement priority as populated (i.e., 'strictly interpret'
the parameter as defined in the QSPEC draft).  All sorts of meaningless
'remappings' from one priority space to another is *not* the norm or the
intent, and are not allowed.  A meaningful remapping of a priority
parameter can be defined by a QOSM specification 

> pass if not understood?  How do people feel about this?

This would be equivalent to making priority a qspec-2 parameter.  Since
preemption and other priority parameters are specified by referenced
RFCs and standards documents (and supported in most cases already by
implementations), I don't see the problem with strictly interpreting
priority as the default, i.e., leaving it as a qspec-1 parameter.

Jerry

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 17 Oct 2006 15:29:32 -0400

I am clearly missing something, because I still don't get it.

"Ash, Gerald R \(Jerry\), ALABS" <[email-masked]> wrote on 10/17/2006

> parameter can be defined by a QOSM specification

Suppose a call originates in a US DoD network that supports preemption,
then crosses networks which do not support preemption, before terminating
in a British MoD network that also supports preemption.

(Hypothetically) The call path takes it
from the US DoD network
to a US based Telephony Service Provider (e.g., the IP core of an FCC
regulated "carrier")
to a UK based Telephony Service Provider (e.g., the IP core of a UK
government regulated "carrier")
to a UK MoD network which supports preemption

Suppose the US DoD network supports preemption using RFCs 4411, 4412, and
4542.  Then the QNI and "its" QOSM implement  priority "as populated" (aka
"strictly interpret"), using RPH with the dsn namespace.

Suppose the US based Telephony provider supports Admission Priority (as in
draft-lefaucheur-emergency-rsvp)and supports RFC 4412 (using RPH with the
ets namespace for authorized users) but does not support 4411, 4542, or the
dsn namespace in RPH?

Suppose the UK based Telephony provider supports neither 4411, 4412, 4542,
nor draft-lefaucheur-emergency-rsvp.

Suppose the UK MoD network also supports 4411, 4412, and 4542 (but it
supports preemption using the Q735 namespace, not the dsn namespace).

What is the meaningful mapping at each NNI?

I am NOT trying to be difficult, I am trying to understand.

> priority as the default, i.e., leaving it as a qspec-1 parameter.

I am not sure that I agree that RFCs 4411, 4412 and 4542  are already
implemented and commonly deployed.

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 17 Oct 2006 19:30:34 -0500

Janet,

> Suppose the UK based Telephony provider supports neither 

The premise of your example is that QNEs don't abide by the requirements
set down in the QSPEC draft.  That is, you seem to assume that certain
qspec-1 parameters are not 'supported'.

Since the QNI populates preemption priority (and RPH) parameters, the
QSPEC draft requires that all downstream QNEs must either a) strictly
interpret the parameters according to the reference RFCs/standards, or
b) remap the parameters as specified by the QNE's QOSM specification.  

There is *no* assumption that (b) can be done for any arbitrary
remappings between any set of qspec-1 parameters.  It has been often
stated in this lengthy discussion that it is difficult/impossible to
remap from qspec-1 parameter apple1 to qspec-1 parameter orange2 and
therefore 'qspec-1 rules don't work'.  In your example the QNEs do not
follow the rules.  You are right that it is not obvious that preemption
priority logically maps to admission priority nor is there any
implication in the qspec rules that this should be possible.  They have
different functions as stated in the reference RFCs/standards.  The
default assumption is that qspec-1 parameters will be strictly
interpreted or that a logical/meaningful remapping is defined in the
QOSM specification.

Thanks,
Jerry

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 18 Oct 2006 08:48:57 +0200

Jerry,

so your recommendation for providers not interested in priority 
or those in countries where it is prohibited by laws would be 
not deploy QoS NSLP or to prevent roaming support for visiting 
customers of any provider supporting priority?

Regards,

Rudiger

|> >In most other protocols, the general rule for  dealing with 
|> >unknown priority structures is "if you don't 
|> >understand/support it, don't mess with it".  In other words, 
|> >"ignore it".
|
|If a QNI populates priority (either preemption, admission, RPH, etc.)
|for its QOSM then the QNI/QOSM requirement for the reservation is that
|QNEs will implement priority as populated (i.e., 'strictly interpret'
|the parameter as defined in the QSPEC draft).  All sorts of meaningless
|'remappings' from one priority space to another is *not* the 
|norm or the
|intent, and are not allowed.  A meaningful remapping of a priority
|parameter can be defined by a QOSM specification 
|
|> >I still don't understand why "ignore it" is forbidden for 
|> >Priority in QSPEC.
|
|> So, for the priority bit, should we have a general rule to silently
|> pass if not understood?  How do people feel about this?
|
|This would be equivalent to making priority a qspec-2 parameter.  Since
|preemption and other priority parameters are specified by referenced
|RFCs and standards documents (and supported in most cases already by
|implementations), I don't see the problem with strictly interpreting
|priority as the default, i.e., leaving it as a qspec-1 parameter.
|
|Jerry
|
|_______________________________________________
|nsis mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/nsis
|

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Wed, 18 Oct 2006 14:39:23 +0200

Georgios, 

you are misinterpreting what I've been saying. It is incorrect that I introduce additional parameters.

For the _CL QOSM_ which, by its very nature, only can support two "QoS classes", the only meaningful way to deal with all the different QoS classes is to divide them in two (low / high). For another QOSM (Y.1548 say), this may be a completely different story.

In my view this is a very nice example of "providing both interoperability and flexibility". 

Cornelia

> Gesendet: Dienstag, 17. Oktober 2006 16:33
> An: [email-masked]; Kappler, Cornelia;

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 18 Oct 2006 14:58:02 +0200

Hi Cornelia

>From what you say, I can deduce that the CL QOSM will use two 
QoS classes that are different than the three ones (PHB Class, DSTE class,
Y.1548 Class)
that are already defined in the QSPEC template and are mandatory. 

My point is that even if the CL QOSM will not use the PHB Class, DSTE Class,
Y.1548 Class,
a QNE will have to support the three classes: PHB Class, DSTE Class, Y.1548
Class, anyway
since they are mandatory. Now if the QNE would want to also support 
the CL QOSM, in addition to the QSPEC template, then this QNE must also be
able to 
support the two new QoS classes that will be (I suppose) defined in the CL
QOSM draft.

Please inform me if my interpretation of the above is right?

Best Regards,
Georgios

> Sent: woensdag 18 oktober 2006 14:39
> To: Georgios Karagiannis; [email-masked]; 
> you are misinterpreting what I've been saying. It is 
> incorrect that I introduce additional parameters.
> 
> For the _CL QOSM_ which, by its very nature, only can support 
> two "QoS classes", the only meaningful way to deal with all 
> the different QoS classes is to divide them in two (low / 
> high). For another QOSM (Y.1548 say), this may be a 
> completely different story.
> 
> > Okay, but this is something different then what we are curreently 
> > discussing in this thread!
> > Cornelia actually proposes two additional parameters that are 
> > different then the 3 mandatory QOS classes defined already.
> > 
> > > OK, so I think your point on the manditory parameters could be 
> > > classified as something like this.  If we have manditory 
> parameters, 
> > > how to map from one QoS model to another, especially when the QoS 
> > > models are using relative values - meaning no absolute 
> values.  If 
> > > all QoS Models had 3 traffic classes - roughly high, 
> medium and low 
> > > - then it would be very simple to handle. However, different QoS 
> > > models might have trouble to map from one model to another.
> > > 
> end-to-end

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Wed, 18 Oct 2006 15:45:17 +0200

Hi Georgios, 

thanks a lot for your mail!

I would like to first step back and reconsider what we would like to achieve ideally. Ideally, each domain implements its QOSM and no additional mechanism beyond its QOSM (!). Also ideally, a domain receives a reservation expressed in terms of a different QOSM, and translates it into its own QOSM language. Now it is in a position to just perform its normal QOSM procedures. At the same time the QNI is happy because, while not getting exactly what it was requesting, it receives as adequate a treatment as possible. Would you agree to this goal?

I also think the key to the matter is what does it mean to "support". See inline.

> Gesendet: Mittwoch, 18. Oktober 2006 14:58
> An: Kappler, Cornelia; [email-masked]; 

I would formulate it differently:
The CL QOSM "by its nature" can only support two classes. Therefore it _remaps_ the many QoS classes into the two it can support. 

>From my explanation above did it become clear, that the "support" in the QNE for the three classes really consists in a remapping, and that the "two new classes" are just the natural two classes provided by the CL QOSM? So the overhead created for the QNE is minimal. 

At the same time, from a QNI perspective, this is better than no remapping.

What do you think about this?

Cornelia

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 18 Oct 2006 17:21:56 +0200

Hi Cornelia

Please consider the observation made by Lars. 
At the moment the QSPEC template, defines a bearer which requires
13 mandatory parameters. This is independently of the QOSMs that 
NSIS will have to support. This is much heavier than 
what RSVP requires from a router that supports RSVP.

Now coming back to your e-mail, I still do not understand what
these two additional parameters are used for. You mention that they are used

for remapping, but for remapping of what?
How a QNE can remap the <PHB class> to <Y.1541 class> 
by using these two CL-QOSM classes?

This thread explains that the 3 QOS class mandatory parameters cannot be 
implemented by all QNEs, because this will mean that all these QNEs 
must support Diffserv and MPLS and Y.1541.

What is your opinion on this?

Best Regards,
Georgios

> Sent: woensdag 18 oktober 2006 15:45
> I would like to first step back and reconsider what we would 
> like to achieve ideally. Ideally, each domain implements its 
> QOSM and no additional mechanism beyond its QOSM (!). Also 
> ideally, a domain receives a reservation expressed in terms 
> of a different QOSM, and translates it into its own QOSM 
> language. Now it is in a position to just perform its normal 
> QOSM procedures. At the same time the QNI is happy because, 
> while not getting exactly what it was requesting, it receives 
> as adequate a treatment as possible. Would you agree to this goal?
> 
> > From what you say, I can deduce that the CL QOSM will use two QoS 
> > classes that are different than the three ones (PHB Class, 
> DSTE class,
> > Y.1548 Class)
> The CL QOSM "by its nature" can only support two classes. 
> Therefore it _remaps_ the many QoS classes into the two it 
> can support. 
> 
> > 
> > My point is that even if the CL QOSM will not use the PHB 
> Class, DSTE 
> > Class,
> > Y.1548 Class,
> > a QNE will have to support the three classes: PHB Class, 
> DSTE Class, 
> > Y.1548 Class, anyway since they are mandatory. Now if the QNE would 
> > want to also support the CL QOSM, in addition to the QSPEC 
> template, 
> > then this QNE must also be able to support the two new QoS classes 
> > that will be (I suppose) defined in the CL QOSM draft.
> 
> >From my explanation above did it become clear, that the 
> "support" in the QNE for the three classes really consists in 
> a remapping, and that the "two new classes" are just the 
> natural two classes provided by the CL QOSM? So the overhead 
> created for the QNE is minimal. 
> 
> > > For the _CL QOSM_ which, by its very nature, only can support two 
> > > "QoS classes", the only meaningful way to deal with all the 
> > > different QoS classes is to divide them in two (low / high). For 
> > > another QOSM (Y.1548 say), this may be a completely 
> different story.
> > > 
> > > > According to the QSPEC template a QNI can include a 
> Y.1541 class 
> > > > parameter.
> > > > > >> >> > I think it is unrealistic to assume that 
> Y.1541 and DSTE
> > > > > >> >> behavior (as
> > > > > >> >> > required for strictly interpreting these 
> parameters) is
> > > > > >> >> implemented in
> > > > > >> >> > every QNE.
> > > > > >> >> > 
> > > > > >> >> > Ciao
> > > > > >> >> > Hannes
> > > > > >> >> > 
> > > > > >> >> > > It is not realistic to assume that the QNI 
> is able to
> > > > > >> know which