Subject: [NSIS] Recommendation on QSpec-1 parameters

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 22 Sep 2006 11:25:17 +0200

Hi Jerry, Cornelia and Attila

I have made an exercise and tried to apply and use the  
QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the 
RMD-QOSM. Please note that in my opinion one might get the same conclusions
if
another edge-to-edge QOSM will be used, e.g., the future PCN QOSM.

My conclusions are as follows:

1) <Token Bucket> and <Bandidth> parameters should be QSPEC-1 paramteres,
but then 
a QNI MUST include both. A QNE that receives both these parameters must:

   * either strictly interpret at least one of the parameters. In this case
the "R" 
     flag and "Q" flags MUST not be set.

   * or remap one of the parameters into another parameter (e.g. <Token
Bucket> into <Bandwidh>
     In this case the remapped parameter (e.g., <Token Bucket>
     has to set the <R> flag. The <Q> flag should also be set.

2) The <Excess treatment> parameter influences the way of how the 
data packets should be treated within an edge-to-edge domain.
In this way the solutions that can be provided by RMD-QOSM in situations of 
e.g., severe congestion are limited. Note that this also will influence a
solution 
such as PCN in case of solving the preemption issue.
My recommendation is to ignore this parameter when it has to be used in
such edge-to-edge domains. This means that this parameter should be 
  * either a QSPEC-2 parameter 
  * or a QSPEC-1 parameter that is able to be ignored 
    in edge-to-edge domains, without that the flags "R" and "Q" flags are
set. 
    In the last case the QOSM description should emphasize that
    this parameter is ignored. 

3) <priority>: as already mentioned in the last version of the QSPEC
template draft
  such a parameter cannot be mandatory, because in several countries
preemption of
  sessions in favour of others is not allowed. Thus this parameter, should
either be 
  a QSPEC-2 parameter or a QSPEC-1 that could be in some cases ignored.
  Further, I would again recommend that all the <priority> parameters, MUST
be included 
  by a QNI, then a QNE that receives these parameters could:
   * either strictly interpret at least one of the parameters. In this case
the "R" 
     flag and "Q" flags MUST not be set.

   * or remap one of the parameters into another parameter 
     In this case the remapped parameter
     has to set the <R> flag. The <Q> flag should also be set.
  
4) <QoS Class>: this parameter can be a QSPEC-1 parameter, but a QNI MUST
include 
   all <QoS class> parameters, i.e., <PHB class>, <DSTE Class Type> and 
   <Y.1541 QoS Class>. Then a QNE that receives these parameters could:
   * either strictly interpret at least one of the parameters. In this case
the "R" 
     flag and "Q" flags MUST not be set.

   * or remap one of the parameters into another parameter, e.g., "DSCP" =>
"PHB ID code"
     In this case the remapped parameter, e.g., <PHB class>
     has to set the <R> flag. The <Q> flag should also be set.

Best Regards,
Georgios

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sat, 23 Sep 2006 07:33:12 -0500

Georgios,

See below. 

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Friday, September 22, 2006 5:25 AM
> To: Ash, Gerald R (Jerry), ALABS; 'Kappler, Cornelia'; 
> 'Attila Báder (IJ/ETH)'
> Cc: [email-masked]
> Subject: Recommendation on QSpec-1 parameters
> 
> QSPEC-1 (mandatory) and QSPEC-2 (optional) parameters into the 
> RMD-QOSM. Please note that in my opinion one might get the 
> same conclusions if
> 1) <Token Bucket> and <Bandwidth> parameters should be QSPEC-1 
> parameters, but then 
>      the "R" flag and "Q" flags MUST not be set.
> 
>      (e.g. <Token Bucket> into <Bandwidth>

Always sending both <token bucket> and <bandwidth> makes no sense to me.  The QNI sends either/or based on its QOSM.  A QNE can either strictly interpret or remap whichever parameter is sent.

> e.g., severe congestion are limited. Note that this also will 
> influence a solution 
>     in edge-to-edge domains, without that the flags "R" and 
>     "Q" flags are set. 

You haven't explained why the QSPEC-1 parameters cannot be strictly interpreted or remapped.  Anyway, there is essentially no support to ignore QSPEC-1 parameters.

>   sessions in favour of others is not allowed. Thus this 
> parameter, should either be 

Preemption is used with RSVP without problem, NSIS introduces nothing new in that regard.  However, if such an issue of 'illegality' arises for use of preemption, perhaps a specific error code could be introduced to address that specific issue, but I see no need for that at this point.

>   Further, I would again recommend that all the <priority> 
> parameters, MUST be included 
>      the "R" flag and "Q" flags MUST not be set.
> 

The various cases of sending <priority> parameters are described in Section 7.2.4 of the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt.  There are some instances where all or some of the parameters are sent, but it makes no sense to always send all parameters.  The QNI sends <priority> parameters based on its QOSM.  A QNE can either strictly interpret or remap whichever parameter(s) are sent.
   
> 4) <QoS Class>: this parameter can be a QSPEC-1 parameter, 
> but a QNI MUST include 
>    * either strictly interpret at least one of the 
>      parameters. In this case the "R" 
>    * or remap one of the parameters into another parameter, 
>      e.g., "DSCP" => "PHB ID code"

As stated in Section 7.2.3 of the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt:
"  <QoS Class> = <PHB Class> <DSTE Class Type> <Y.1541 QoS Class>
   The above notation means that either <PHB Class>, <DSTE Class Type>,
   or <Y.1541 QoS Class> sub-parameters MAY be populated in the <QoS
   Class> parameter.  Normally only one of these sub-parameters is
   populated in <QoS Class>.  If more than one sub-parameter is
   populated, the QOSM specification document MUST give procedures for
   processing multiple sub-parameters."

IMO this is the correct approach, it makes no sense to always send all parameters.  The QNI sends <QoS class> parameters based on its QOSM.  A QNE can either strictly interpret or remap whichever parameter(s) are sent.

Thanks,
Jerry

---

From: <[email-masked]>
Date: Sun, 24 Sep 2006 09:45:31 +0300

Hi all,

It might be good to get some other people to comment on this mailing list,
to get some others' opinions on this thread.

John 

>From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>Sent: 23 September, 2006 15:33
>To: Georgios Karagiannis
>Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
>Subject: [NSIS] RE: Recommendation on QSpec-1 parameters
>
>Georgios,
>
>See below. 
>
>> To: Ash, Gerald R (Jerry), ALABS; 'Kappler, Cornelia'; 'Attila Báder 
>> (IJ/ETH)'
>> Cc: [email-masked]
>> RMD-QOSM. Please note that in my opinion one might get the same 
>> conclusions if another edge-to-edge QOSM will be used, e.g., the 
>> future PCN QOSM.
>> 
>> parameters, but then a QNI MUST include both. A QNE that 
>receives both 
>> these parameters must:
>> 
>>      parameters. In this case
>Always sending both <token bucket> and <bandwidth> makes no 
>sense to me.  The QNI sends either/or based on its QOSM.  A 
>QNE can either strictly interpret or remap whichever parameter is sent.
>
>> 2) The <Excess treatment> parameter influences the way of 
>how the data 
>> packets should be treated within an edge-to-edge domain.
>> In this way the solutions that can be provided by RMD-QOSM in 
>> situations of e.g., severe congestion are limited. Note that 
>this also 
>> will influence a solution such as PCN in case of solving the 
>> preemption issue.
>> My recommendation is to ignore this parameter when it has to be used 
>> in such edge-to-edge domains. This means that this parameter 
>should be
>You haven't explained why the QSPEC-1 parameters cannot be 
>strictly interpreted or remapped.  Anyway, there is 
>essentially no support to ignore QSPEC-1 parameters.
>
>>   sessions in favour of others is not allowed. Thus this parameter, 
>> should either be
>Preemption is used with RSVP without problem, NSIS introduces 
>nothing new in that regard.  However, if such an issue of 
>'illegality' arises for use of preemption, perhaps a specific 
>error code could be introduced to address that specific issue, 
>but I see no need for that at this point.
>
>>      parameters. In this case
>The various cases of sending <priority> parameters are 
>described in Section 7.2.4 of the QSPEC draft 
>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt.  
>There are some instances where all or some of the parameters 
>are sent, but it makes no sense to always send all parameters. 
> The QNI sends <priority> parameters based on its QOSM.  A QNE 
>can either strictly interpret or remap whichever parameter(s) are sent.
>   
>> 4) <QoS Class>: this parameter can be a QSPEC-1 parameter, but a QNI 
>> MUST include
>As stated in Section 7.2.3 of the QSPEC draft 
>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt:
>IMO this is the correct approach, it makes no sense to always 
>send all parameters.  The QNI sends <QoS class> parameters 
>based on its QOSM.  A QNE can either strictly interpret or 
>remap whichever parameter(s) are sent.
>
>Thanks,
>Jerry
>
>> 
>> Best Regards,
>> Georgios
>> 
>> 
>> 
>

---

From: Bernd Schloer <[email-masked]>
Date: Sun, 24 Sep 2006 14:36:39 +0200

Hi Georgios and all,

what are the solutions for RMD-QOSM for <Excess Treatment>?
For the behaviour of the Traffic Conditioner for out-of-profile
traffic for the CLS-QOSM I thought of:

  0: drop, some or all packets are discarded
  1: shape, some or all packets are delayed
  2: remark, reclassification to BE
  3: no metering or policing, ...

In countries where preemption is not allowed, high priority
could be degraded to normal priority. This still allows
to differentiate between best effort traffic and normal priority.

When a QNI must include <PHB class>, <DSTE Class Type> and 
<Y.1541 QoS Class>, which values should be taken, when the QNI
can't provide them? As Jerry pointed out some days ago, there's
no fixed mapping for <PHB class>, <DSTE Class Type>.

If both, <Token Bucket> and <Bandwidth> have to be included by
a QNI then one parameter is enough: <Token Bucket>. A QOSM
which needs <Bandwidth>, can interpret it as bandwidth. Is there
a need to define this mapping or can this be up to the implementation?

Bernd

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 25 Sep 2006 12:33:52 +0200

Hi Bernd

* Regarding the <Excess Treatment>, the RMD QNEs should be able to 
choose the most efficient way for excess treatment in order to 
for example, solve severe congestion situations.
If this parameter is mandatory, this will mean that the 
end QNI will dictate what kind of excess treatment should be used 
by each QNE in the RMD domain. This will limit the way of how the 
severe congestion is solved.

Note that in a severe congestion situation, typically most packets 
will be dropped! However, if the <Excess treatment> is mandatory 
and the end QNI dictates that the packets should be remarked 
and not dropped, then all the nodes that are under severe congestion 
will keep the congestion and the network will very quickly collapse.

* Regarding <Token Bucket> and <Bandwidth>, if both are included in the 
<QoS desired> or <QoS available> then a QNE can choose the one of the two
parameters.

A problem may arise from the fact that the QNI will not know which of the
one is 
used by the QNEs.
One solution of this problem can be solved in the following way:
If a QNI is willing to use the <Token Bucket> parameter as mandatory, then 
the QNI must include the <Token Bucket> parameter as QSPEC-1 parameter and 
it must also inlcude the <Bandwidth> parameter as QSPEC-2 parameter.
If a QNE cannot use the <Token Bucket>, then it will use the optional 
<Bandwidth> parameter and will set the "R" and "Q" flags associated with the

<Token Bucket> parameter.
When <Bandwidth> is chosen as QSPEC-1 parameter, then <Token Bucket> is
chosen as 
QSPEC-2 parameter. A similar method of remapping as described above can be
followed.
Note that in this case the way of how the remapping of one QSPEC-1 parameter
value into another 
value is specified by the QNI. 

* Regarding <priority>, the mentioned solution regarding the 
remapping from high to normal by appling a degradation of high priority 
to normal priority, maybe can help, but the main problem that I have is 
the fact that all four <priority> parameters are mandatory and for 
a QOSM that uses one of the four <priority> parameters, it is difficult 
to remap one of the <priority> parameters into another one.

If a QNI includes all 4 <priority> parameters, then a QNE 
can choose the one that it needs! Note that a QNI should be able 
to fill all 4 QSPEC-1 <priority> parameters. This is the same situation as
the situation 
that a QNE should be able to process all QSPEC-1 parameters.
A problem may arise from the fact that the QNI will not know which of the
one is 
used by the QNEs.
One solution of this problem can be solved in the following way:
Make only one of the four <priority> parameters QSPEC-1 parameter. 
The QNI must include all the other three <priority> parameters as 
QSPEC-2 parameters.
The way of how the remapping is done is similar to the explanation that I
give above
 regarding <Token Bucket> and <Bandwidth> parameters.

* The problem with the QoS class parameters is that it is very difficult to
remap
One of the QoS class parameters into another parameter. In my previous
e-mails 
I emphasized that each of the QoS class parameters are usefull in some
setting and useless 
in other settings. In order to make the <QoS class> parameter always usefull

We can do that by requiring that the QNI must include all three QoS class
parameters,
then a QNE can choose the one that it needs. Note that a QNI should be able 
to fill all 3 QSPEC-1 <QoS class> parameters. This is the same situation as
the situation 
that a QNE should be able to process all QSPEC-1 <QoS class> parameters.

Best regards,
Georgios

-----Original Message-----
From: Bernd Schloer [mailto:[email-masked]] 
Sent: zondag 24 september 2006 14:37
To: Georgios Karagiannis
Cc: 'Ash, Gerald R (Jerry), ALABS'; "'Attila Báder (IJ/ETH)'";
[email-masked]; 'Kappler,Cornelia'
Subject: Re: [NSIS] Recommendation on QSpec-1 parameters

Hi Georgios and all,

what are the solutions for RMD-QOSM for <Excess Treatment>?
For the behaviour of the Traffic Conditioner for out-of-profile traffic for
the CLS-QOSM I thought of:

In countries where preemption is not allowed, high priority could be
degraded to normal priority. This still allows to differentiate between best
effort traffic and normal priority.

When a QNI must include <PHB class>, <DSTE Class Type> and
<Y.1541 QoS Class>, which values should be taken, when the QNI can't provide
them? As Jerry pointed out some days ago, there's no fixed mapping for <PHB
class>, <DSTE Class Type>.

If both, <Token Bucket> and <Bandwidth> have to be included by a QNI then
one parameter is enough: <Token Bucket>. A QOSM which needs <Bandwidth>, can
interpret it as bandwidth. Is there a need to define this mapping or can
this be up to the implementation?

Bernd

Georgios Karagiannis wrote:
> 1) <Token Bucket> and <Bandidth> parameters should be QSPEC-1 
> paramteres, but then a QNI MUST include both. A QNE that receives both 
> these parameters must:
> 
>    * either strictly interpret at least one of the parameters. In this 
> case the "R"
> 2) The <Excess treatment> parameter influences the way of how the data 
> situations of e.g., severe congestion are limited. Note that this also 
> in such edge-to-edge domains. This means that this parameter should be
>     in edge-to-edge domains, without that the flags "R" and "Q" flags 
> are set.
>   Further, I would again recommend that all the <priority> parameters, 
> MUST be included
>    * either strictly interpret at least one of the parameters. In this 
> case the "R"
>    * either strictly interpret at least one of the parameters. In this 
> case the "R"
>    * or remap one of the parameters into another parameter, e.g., 
> "DSCP" => "PHB ID code"

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Mon, 25 Sep 2006 13:52:41 +0200

Hi Georgios, 

essentially you would include always all parameters into the QSPEC. The goal of the QSPEC exercise was however right the contrary: gain interoperability by allowing (may be unprecise) "x-interpretation" of parameters. So I think your proposal is - while entirely possible - not in the spirit of the draft. There are other possibilities if you make slight compromises (regarding (i) the exact interpretation of QNI parameters and (ii) what a QNE must be able to do (note in the RMD case these are just the stateful edge QNEs!)) 

Cornelia 

> -----Ursprüngliche Nachricht-----
> Von: Georgios Karagiannis [mailto:[email-masked]] 
> Gesendet: Freitag, 22. September 2006 11:25
> An: 'Ash, Gerald R (Jerry), ALABS'; Kappler, Cornelia; 
> 'Attila Báder (IJ/ETH)'
> Cc: [email-masked]
> Betreff: Recommendation on QSpec-1 parameters
> 
> same conclusions
> paramteres,
> (e.g. <Token
> situations of 
> influence a
> "Q" flags are
> but a QNI MUST

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 25 Sep 2006 10:18:36 -0400

"Georgios Karagiannis" <[email-masked]> wrote on 09/25/2006

> Hi Bernd
...
>  regarding <Token Bucket> and <Bandwidth> parameters.
It is my understanding that the priority parameters should not by regarded
as 4 independent parameters, but rather as two parameter-pairs:
The <Preemption Priority> & <Defending Priority> Parameters must either
both be present, or neither.
You can have <Admission Priority> without <RPH Priority>, but you can only
have <RPH Priority> if you also have <Admission Priority>, with the value "
2 - high priority flow".

Janet

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 25 Sep 2006 16:59:07 +0200

Hi Janet

You are right, but my point was to emphasize that the 
QNI should include all 4 <priority> parameters, then a QNE can choose 
the one (or the ones) that it needs! Note that a QNI should be able to 
fill all 4 QSPEC-1 <priority> parameters. This is the same situation
as the situation that a QNE should be able to process all QSPEC-1
parameters.
 
Best regards,
Georgios

-----Original Message-----
From: Janet P Gunn [mailto:[email-masked]] 
Sent: maandag 25 september 2006 16:19
To: Georgios Karagiannis
Cc: 'Ash, Gerald R (Jerry), ALABS'; 'Kappler,Cornelia'; [email-masked];
"'"'Attila Báder (IJ/ETH)'"'"
Subject: RE: [NSIS] Recommendation on QSpec-1 parameters

...
>
>
> * Regarding <priority>, the mentioned solution regarding the remapping 
> from high to normal by appling a degradation of high priority to 
> normal priority, maybe can help, but the main problem that I have is 
> the fact that all four <priority> parameters are mandatory and for a 
> QOSM that uses one of the four <priority> parameters, it is difficult 
> If a QNI includes all 4 <priority> parameters, then a QNE can choose 
> the one that it needs! Note that a QNI should be able to fill all 4 
> QSPEC-1 <priority> parameters. This is the same situation
as
> A problem may arise from the fact that the QNI will not know which of 
> the one is used by the QNEs.
> The way of how the remapping is done is similar to the explanation 
> that I give above  regarding <Token Bucket> and <Bandwidth> 
> parameters.
>
>
The <Preemption Priority> & <Defending Priority> Parameters must either both
be present, or neither.

Janet

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 25 Sep 2006 17:22:27 +0200

Hi Cornelia

The problems that I have found with these parameters are:

1) Not all QSPEC-1 parameters are necessary to provide the interoperability.
   For example, the QNE must support each parameter even if that parameter
causes a collapse in
   the network performance, e.g., <Excess Treatment>. 

2) There are 4 sets of QSPEC-1 parameters: <QoS Class>, <priority>, <Excess
Treatment>
   <Traffic>. Each of these sets includes more than one parameter, e.g.,
<QoS Class>
   includes the <PHB class>, <DSTE class type> and <Y.1541 QoS class>
parameters. However, 
   in the current version of QSpec template, a QNI must include at least one

   of the parameters. Thus, for example, consider that a QNI includes either
a
   a <DSTE class type> or a <Y.1541 QoS class>. Based on the current QSpec
template specification 
   a diffserv based QNE must be able to interpret a <DSTE class type> and a
<Y.1541 QoS class> 
   even if it cannot do that! Please note that I do not think that it is
possible 
   to remap a <DSTE class type> or a <Y.1541 QoS class> parameter into a PHB
class 
parameter.

Below you can find a copy of the e-mail that I have sent this morning that
describes these issues 
in a more detailed way:

---------------------

* Regarding the <Excess Treatment>, the RMD QNEs should be able to choose
the most efficient way for excess treatment in order to for example, solve
severe congestion situations.
If this parameter is mandatory, this will mean that the end QNI will dictate
what kind of excess treatment should be used by each QNE in the RMD domain.
This will limit the way of how the severe congestion is solved.

Note that in a severe congestion situation, typically most packets will be
dropped! However, if the <Excess treatment> is mandatory and the end QNI
dictates that the packets should be remarked and not dropped, then all the
nodes that are under severe congestion will keep the congestion and the
network will very quickly collapse.

* Regarding <Token Bucket> and <Bandwidth>, if both are included in the <QoS
desired> or <QoS available> then a QNE can choose the one of the two
parameters.

one is used by the QNEs.
value into another value is specified by the QNI. 

* Regarding <priority>, the mentioned solution regarding the remapping from
high to normal by appling a degradation of high priority to normal priority,
maybe can help, but the main problem that I have is the fact that all four
<priority> parameters are mandatory and for a QOSM that uses one of the four
<priority> parameters, it is difficult to remap one of the <priority>
parameters into another one.

If a QNI includes all 4 <priority> parameters, then a QNE can choose the one
that it needs! Note that a QNI should be able to fill all 4 QSPEC-1
<priority> parameters. This is the same situation as the situation that a
QNE should be able to process all QSPEC-1 parameters.
A problem may arise from the fact that the QNI will not know which of the
one is used by the QNEs.
One solution of this problem can be solved in the following way:
Make only one of the four <priority> parameters QSPEC-1 parameter. 
The QNI must include all the other three <priority> parameters as
QSPEC-2 parameters.
The way of how the remapping is done is similar to the explanation that I
give above  regarding <Token Bucket> and <Bandwidth> parameters.

* The problem with the QoS class parameters is that it is very difficult to
remap One of the QoS class parameters into another parameter. In my previous
e-mails I emphasized that each of the QoS class parameters are usefull in
some setting and useless in other settings. In order to make the <QoS class>
parameter always usefull We can do that by requiring that the QNI must
include all three QoS class parameters, then a QNE can choose the one that
it needs. Note that a QNI should be able to fill all 3 QSPEC-1 <QoS class>
parameters. This is the same situation as the situation that a QNE should be
able to process all QSPEC-1 <QoS class> parameters.

----------------------------------

Best Regards,
Georgios

-----Original Message-----
From: Kappler, Cornelia [mailto:[email-masked]] 
Sent: maandag 25 september 2006 13:53
To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila Báder
(IJ/ETH)
Cc: [email-masked]
Subject: [NSIS] AW: Recommendation on QSpec-1 parameters

Hi Georgios, 

essentially you would include always all parameters into the QSPEC. The goal
of the QSPEC exercise was however right the contrary: gain interoperability
by allowing (may be unprecise) "x-interpretation" of parameters. So I think
your proposal is - while entirely possible - not in the spirit of the draft.
There are other possibilities if you make slight compromises (regarding (i)
the exact interpretation of QNI parameters and (ii) what a QNE must be able
to do (note in the RMD case these are just the stateful edge QNEs!)) 

Cornelia 

> An: 'Ash, Gerald R (Jerry), ALABS'; Kappler, Cornelia; 'Attila Báder 
> (IJ/ETH)'
> Cc: [email-masked]

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 26 Sep 2006 14:10:26 +0200

Hi Georgios

Re (1):
"cause collapse in network performance": I assume this is something you think might happen rather than the result of a measurement? For sure the inclusion of every mandatory parameter is a trade off between performance and interoperabilty. And my impression is "rough consensus" in the WG is including Excess Treatment (since we dont have any measurements)
[reading your more detailed email attached my impression is you worry particularly about a QNE being forced to remark rather than drop. So may be this is a problem with this particular value of Excess Treatment?]

Re (2):
a) As you know, the QNI does NOT need to include every parameter (ceterum censeo...!?!?!?!) (Nor a QNI must be able to fill all three priority parameters. A QNI only fills those parameters it cares about)
b) Doubtlessly there is no perfect mapping between the individual parameters. But then the goal of QoS NSLP is interoperability. And this is only possible when allowing an (imperfect) mapping.

Cornelia

> Gesendet: Montag, 25. September 2006 17:22
> An: Kappler, Cornelia; 'Ash, Gerald R (Jerry), ALABS'; 
> 'Attila Báder (IJ/ETH)'
> Cc: [email-masked]
> Betreff: RE: [NSIS] AW: Recommendation on QSpec-1 parameters
> 
> Hi Cornelia
> 
> remapping from
> 'Attila Báder

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Sep 2006 17:30:39 +0200

Hi Cornelia

Please see in line!

-----Original Message-----
From: Kappler, Cornelia [mailto:[email-masked]] 
Sent: dinsdag 26 september 2006 14:10
To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila Báder
(IJ/ETH)
Cc: [email-masked]
Subject: AW: [NSIS] AW: Recommendation on QSpec-1 parameters

Hi Georgios

> Re (1):
"cause collapse in network performance": I assume this is something 
> you think might happen rather than the result of a measurement? 
> For sure the inclusion of every mandatory parameter is a 
> trade off between performance and interoperabilty. And my 
> impression is "rough consensus" in the WG is including 
> Excess Treatment (since we dont have any measurements) 
> [reading your more detailed email attached my impression 
> is you worry particularly about a QNE being forced to remark rather than
drop. 
> So may be this is a problem with this particular value of Excess
Treatment?]

Georgios: Please note that the main problem with this relates to the <Excess
Treatment> parameter.
   The problem does impact not only the network performance, but also the
operation of the network.
   If a node strictly follows the mandated requirement, then in case of
e.g., a severe congestion, then
   the network might completely collapse, i.e., a total network failure
could occur.
   Regarding the Excess Treatment value, the current specification mentions
that 
   the QNI will specify the value!

> Re (2):
a) As you know, the QNI does NOT need to include every 
> parameter (ceterum censeo...!?!?!?!) (Nor a QNI must 
> be able to fill all three priority parameters. 
> A QNI only fills those parameters it cares about)

Georgios: regarding a) 
Yes, I know that the current version specifies that the QNI does NOT need to
include every parameter.
And that is exactly what creates the problems mentioned by me. If the QNI
will be required to
include these parameters, then most of the remapping problems within the
network are solved.
This is because the QNI will actually do the remapping by itself and it will
have a better knowledge 
on accepting or rejecting a requested reservation. 
For example, if we look to the QoS Class parameters, 
each of the QoS class parameters are usefull in
some setting and impossible in other settings. In order to make the <QoS
class>
parameter always possible we can do that by requiring that the QNI must
include all three QoS class parameters, then a QNE can choose 
the one that it needs. Note that if a QNI is interested only in one of them,
say <Y.1541 QoS class>, then the QNI
Could set this parameter as QSPEC-1 parameter. However, in this case the QNI
MUST also fill in the other two parameters, i.e., <PHB class> and <DSTE
class type>, which can be set as QSPEC-2 parameters.
In this way it will be possible for any QNE to remap the value of the
QSPEC-1 <QOS class> parameter, e.g., 
<Y.1541 class> into either <DSTE class type> or <PHB class>. Furthermore,
the QNI will have all the knowledge 
On which method has been used for the remapping of the <QoS class>
parameter.

> b) Doubtlessly there is no perfect mapping between 
> the individual parameters. But then the goal of 
> QoS NSLP is interoperability. And this is only 
> possible when allowing an (imperfect) mapping.

Georgios: regarding b) 
I am not talking about imperfect mapping, but I am referring to an
impossible mapping.
Could you please provide me with two examples:
1) Please provide an example of remapping of 
the <DSTE class type> parameter into <PHB class> parameter
2) Please provide an example of remapping of 
the <Y.1541 QopS class> parameter into <PHB class> parameter

Many thanks in adavance!
Best Regards,
Georgios

> An: Kappler, Cornelia; 'Ash, Gerald R (Jerry), ALABS'; 'Attila Báder 
> (IJ/ETH)'
> Cc: [email-masked]
>    For example, the QNE must support each parameter even if that 
> parameter causes a collapse in
>    <Traffic>. Each of these sets includes more than one parameter, 
> e.g., <QoS Class>
>    of the parameters. Thus, for example, consider that a QNI includes 
> either a
>    a <DSTE class type> or a <Y.1541 QoS class>. Based on the current 
> QSpec template specification
>    even if it cannot do that! Please note that I do not think that it 
> is possible
>    to remap a <DSTE class type> or a <Y.1541 QoS class> parameter into 
> a PHB class parameter.
> 
> 
> Below you can find a copy of the e-mail that I have sent this morning 
> that describes these issues in a more detailed way:
> 
> ---------------------
> 
> 
> choose the most efficient way for excess treatment in order to for 
> example, solve severe congestion situations.
> If this parameter is mandatory, this will mean that the end QNI will 
> dictate what kind of excess treatment should be used by each QNE in 
> the RMD domain.
> will be dropped! However, if the <Excess treatment> is mandatory and 
> the end QNI dictates that the packets should be remarked and not 
> dropped, then all the nodes that are under severe congestion will keep 
> the congestion and the network will very quickly collapse.
> 
> 
> If a QNI is willing to use the <Token Bucket> parameter as mandatory, 
> then the QNI must include the <Token Bucket> parameter as QSPEC-1 
> parameter and it must also inlcude the <Bandwidth> parameter as 
> QSPEC-2 parameter.
> <Bandwidth> parameter and will set the "R" and "Q" flags associated 
> with the <Token Bucket> parameter.
> QSPEC-2 parameter. A similar method of remapping as described above 
> can be followed.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 26 Sep 2006 11:54:52 -0400

Georgios and all:

Is it not wise to drop the QOS classes like Y.1541 and DSTE from the
QSPEC draft in the first place as we mentioned over the years?

Can anyone make any sense when they want to "map" between Y.1541 and
DSTE QOS classes? 

Moreover, are those "values" not chosen those independent from one
another to sever different purposes decoupling "arbitrarily" from the
needs of the upper layer applications just to have the network-centric
view?

Even from the network-centric view, will anyone be able to "map" between
Y.1541 and DSTE QOS classes that make technical sense to sever the
purpose of the network QOS, if not application QOS?

Best regards,
Radhika

Georgios: regarding b) 

Many thanks in adavance!
Best Regards,
Georgios

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 26 Sep 2006 10:57:40 -0500

Georgios,

In the spirit of John's post
http://www1.ietf.org/mail-archive/web/nsis/current/msg06726.html can we
please hear from other people on this topic, and not have so many
repetitions of RMD-QOSM specific concerns.

E.g., we have seen many times:

> The <Excess treatment> parameter influences the way of how the 
> this also will influence a solution such as PCN in case of
> solving the preemption issue.

A QNE supporting a different Local QOSM than the Initiator QOSM has 3
options
1. strictly interpret QSPEC-1 parameters populated in the Initiator
QSPEC
2. remap QSPEC-1 parameters populated in the Initiator QSPEC (as
specified in the Local-QOSM specification document)
3. reject the reservation

In the instance you cite, #3 may be the appropriate response.  Even if a
QSPEC-1 parameter could be ignored the QNI would probably reject the
reservation anyway.

Thanks,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Sep 2006 18:01:10 +0200

Hi Jerry

I think that you are right, we should hear the opinion of other people on
the topic!

Best Regards,
Georgios

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 27 Sep 2006 08:45:41 +0200

Jerry,

didn't read the draft in detail. As far as I understood, 
it provides a toolbox supporting mappings between 
different QoS definitions. A set of parameters has 
been defined for mandatory support. The 
discussion going on here seems to be, whether 
that's a perfect set or not.

If that describes the situation, my suggestion 
would be to add a statement saying 
that due to a lack of sufficient deployment the 
contents of the document are a kind of best guess, 
which should be reviewed once operational 
experience requires or allows such a review. 

Regards,

Rudiger

|-----Original Message-----
|From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
|Sent: Tuesday, September 26, 2006 5:58 PM
|To: Georgios Karagiannis
|Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
|Subject: [NSIS] RE: Recommendation on QSpec-1 parameters
|
|
|Georgios,
|
|In the spirit of John's post
|http://www1.ietf.org/mail-archive/web/nsis/current/msg06726.html can we
|please hear from other people on this topic, and not have so many
|repetitions of RMD-QOSM specific concerns.
|
|E.g., we have seen many times:
|
|> The <Excess treatment> parameter influences the way of how the 
|> data packets should be treated within an edge-to-edge domain.
|> In this way the solutions that can be provided by RMD-QOSM in
|> situations of e.g., severe congestion are limited. Note that
|> this also will influence a solution such as PCN in case of
|> solving the preemption issue.
|
|A QNE supporting a different Local QOSM than the Initiator QOSM has 3
|options
|1. strictly interpret QSPEC-1 parameters populated in the Initiator
|QSPEC
|2. remap QSPEC-1 parameters populated in the Initiator QSPEC (as
|specified in the Local-QOSM specification document)
|3. reject the reservation
|
|In the instance you cite, #3 may be the appropriate response.  
|Even if a
|QSPEC-1 parameter could be ignored the QNI would probably reject the
|reservation anyway.
|
|Thanks,
|Jerry
|
|_______________________________________________
|nsis mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/nsis
|

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Thu, 28 Sep 2006 09:51:39 +0200

Hi Ruediger, 

I think this is an excellent idea. 

Cornelia 

> Von: Geib, Ruediger [mailto:[email-masked]] 
> Gesendet: Mittwoch, 27. September 2006 08:46
> An: [email-masked]
> Cc: [email-masked]
> Betreff: RE: [NSIS] RE: Recommendation on QSpec-1 parameters
> 
> Jerry,
>

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Thu, 28 Sep 2006 12:43:03 +0200

Hi Georgios, 

I think it is very hard to determine what is the right set of parameters without any actual deployment. 

A QNI can always include values for all QSPEC-1 parameters if it thinks this is useful. But I see no point in mandating this. 

If Excess Treatment is set to remark, but a particular QOSM only has one queue, then the remarking may just mean "drop". So I dont see a problem here, either. 

I havent thought about mappings between different QoS Classes, and may be it is difficult to do. But why would the QNI be in a better position to map (because it would essentially do that when including values for all parameters) than a QNE? And if the QNI thinks it knows better then it can include the values.

Cornelia

> Gesendet: Dienstag, 26. September 2006 17:31
> >    a diffserv based QNE must be able to interpret a <DSTE 
> class type> 
> > and a
> > <Y.1541 QoS class> 
> > the one that

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 29 Sep 2006 12:09:17 +0200

Hi Cornelia

But the main problem I have is that due to some QSPEC-1 constraints, 
the edge-to-edge concept of NSIS will not be able to be deployed at all. 
Therefore, it is important to solve these problems now!

Best regards,
Georgios 

-----Original Message-----
From: Kappler, Cornelia [mailto:[email-masked]] 
Sent: donderdag 28 september 2006 12:43
To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila Báder
(IJ/ETH)
Cc: [email-masked]

Hi Georgios, 

I think it is very hard to determine what is the right set of parameters
without any actual deployment. 

A QNI can always include values for all QSPEC-1 parameters if it thinks this
is useful. But I see no point in mandating this. 

If Excess Treatment is set to remark, but a particular QOSM only has one
queue, then the remarking may just mean "drop". So I dont see a problem
here, either. 

I havent thought about mappings between different QoS Classes, and may be it
is difficult to do. But why would the QNI be in a better position to map
(because it would essentially do that when including values for all
parameters) than a QNE? And if the QNI thinks it knows better then it can
include the values.

Cornelia

> > For sure the inclusion of every mandatory parameter is a trade off 
> > between performance and interoperabilty. And my impression is "rough 
> > consensus" in the WG is including Excess Treatment (since we dont 
> > have any measurements) [reading your more detailed email attached my 
> > impression is you worry particularly about a QNE being forced to
> remark rather than
> drop. 
>    The problem does impact not only the network performance, but also 
> the operation of the network.
>    If a node strictly follows the mandated requirement, then in case 
> of e.g., a severe congestion, then
>    the network might completely collapse, i.e., a total network 
> failure could occur.
>    Regarding the Excess Treatment value, the current specification 
> mentions that
> > parameter (ceterum censeo...!?!?!?!) (Nor a QNI must be able to fill 
> > all three priority parameters.
> Yes, I know that the current version specifies that the QNI does NOT 
> need to include every parameter.
> And that is exactly what creates the problems mentioned by me. If the 
> QNI will be required to include these parameters, then most of the 
> remapping problems within the network are solved.
> This is because the QNI will actually do the remapping by itself and 
> it will have a better knowledge on accepting or rejecting a requested 
> reservation.
> For example, if we look to the QoS Class parameters, each of the QoS 
> class parameters are usefull in some setting and impossible in other 
> settings. In order to make the <QoS
> class>
> parameter always possible we can do that by requiring that the QNI 
> must include all three QoS class parameters, then a QNE can choose the 
> one that it needs. Note that if a QNI is interested only in one of 
> them, say <Y.1541 QoS class>, then the QNI Could set this parameter as 
> QSPEC-1 parameter. However, in this case the QNI MUST also fill in the 
> other two parameters, i.e., <PHB class> and <DSTE class type>, which 
> can be set as QSPEC-2 parameters.
> > b) Doubtlessly there is no perfect mapping between the individual 
> > parameters. But then the goal of QoS NSLP is interoperability. And 
> > this is only possible when allowing an (imperfect) mapping.
> 
> Georgios: regarding b)
> 1) Please provide an example of remapping of the <DSTE class type> 
> parameter into <PHB class> parameter
> 2) Please provide an example of remapping of the <Y.1541 QopS class> 
> parameter into <PHB class> parameter
> 
> 
> Many thanks in adavance!
> Best Regards,
> Georgios
> 
> 
> 
> > remapping from high to normal by appling a degradation of high 
> > priority to normal priority, maybe can help, but the main problem 
> > that I have is the fact that all four <priority> parameters are 
> > mandatory and for a QOSM that uses one of the four <priority> 
> > parameters, it is difficult to remap one of the
> <priority>
> > QSPEC-1 <priority> parameters. This is the same situation as the 
> > situation that a QNE should be able to process all QSPEC-1 
> > parameters.
> > A problem may arise from the fact that the QNI will not know which 
> > of the one is used by the QNEs.