Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instancesofdefined parameters

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Tue, 9 Aug 2005 08:59:17 -0400

Tseno:
 
The fundamental problems are as follows:
 
1. QoS models defined so far in all cases of all standards are NOT unique because they consider as a set of performance parameters arbitrarily depending on which standard fora/bodies they belong to.
 
2. If you ask what is the define of QoS model, you will get different answers because it is a matter of grouping some performance parameters here and there. For example, some has delay parameters, some has delay and delay jitter, some has delay, jitter, and packet losses, etc. So, why do you run after those QoS models in the first place while you are doing standardization works for "QoS signaling" works in the IETF when you cannot generalize the QoS model?
 
3. It is "funny" to see that draft does NOT define what a QoS model is. As if, anything ever defined on the earth in the name of QoS model can be included in QSPEC because the draft itself does NOT know what is meant by QoS model. As a result, the draft has created a funny situations that contradict itself for the "same" performance parameter: i. Use values with no Restrictions and ii. Use values with Restrictions.
 
4. Again, QoS classes of a given QoS model are defined based on some "specific values" for which there is no technical context in terms of wireless LANs, cellular, satellite, ad hoc, and/or wired line networks. Here lies another set of contradictions because "values" cannot be used by users as they may contradict. 
 
For example, in related threads I explained (John L. also agreed that users will do so if values for the inter-domains communications are not carefully constructed) why there should be restrictions in use of those values in the first place. 
 
6. To remove this, I have proposed to split the draft into two parts: a. Where values do not contradict following the "generalized" principles of NSIS QoS signaling charter as all of us including yourself want, and b. Where values can be restricted in funny ways and let the users restrict themselves as they suppose to do for inter-domain QoS signaling where nothing can be "generalized" as you have observed (Or, remove this part from the draft altogether).
 
Hope this clarifies the things.
 
Best regards,
Radhika

________________________________

From: [email-masked] on behalf of Kappler, Cornelia
Sent: Tue 8/9/2005 4:17 AM
To: Ash, Gerald R (Jerry), ALABS; Tseno Tsenov; [email-masked]
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instancesofdefined parameters

Hi Tseno,

if we expect multiple instances of the same parameter are something that
is frequent in QOSMs I think we should go for your proposal which is a
rather efficient way of coding it. On the other hand, I am not sure how
likely it is that a QoS Model needs e.g. multiple values of QoS Classes?
Isnt the token bucket quite a special case? All QOSMs we looked at so
far, except DiffServ, dont need this feature.

In any event we probably should make (if at all) mandatory only the
first instance (i.e. a QNE implementing a QoS Model that doesnt need any
(or multiple) instances of this parameter should only be forced to
interpret the first occurrance.)

A related question:
What if a QNI wishes to code e.g. QoS Class, and has a very good idea
that it wants a specific PHB from QNEs implementing the DiffServ QOSM, a
specific Y.1541 QoS Class from QNEs implementing the Y.1441 QOSM etc. Is
it allowed to include values for each type of QoS class it knows about?
This is another usage of "multiple instances" (in fact it is more like
"multiple values". Note this means a QNE would have to parse all these
values to find out whether one specific to its QOSM is included. May be
too much feature creep.

Cornelia

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ash, Gerald R (Jerry), ALABS
> Sent: Sonntag, 7. August 2005 00:44
> To: Tseno Tsenov; [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: RE: [NSIS] QSPEC extensibility and re-use of
> multiple instances ofdefined parameters
>
>
> Tseno,
>
> I like your suggestion.  I think it both simplifies and
> generalizes the
> QSPEC to handle multiple instances of the same parameter.  The second
> and higher instances of any parameter could be defined as optional.
> Procedures for multiple uses of a QSPEC parameter would have to be
> defined by a given QOSM.
>
> What do others think?
>
> Thanks,
> Jerry
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> Tseno Tsenov
> Sent: Friday, August 05, 2005 6:03 AM
> To: [email-masked]
> Subject: [NSIS] QSPEC extensibility and re-use of multiple
> instances of
> defined parameters
>
> Hi,
>
> In my opinion, the current QSPEC draft miss flexibility for multiple
> usage of QSPEC parameters of one type.  Currently, for usage of two
> token bucket in DiffServ EF PH QoS model, two separate mandatory token
> buckets are defined (ID=5 and 6). And for example, if a new QoS model
> requires 3 token buckets at some later point, it must define an
> additional optional token bucket parameter.
> Why don't the QSPEC template provide a method for multiple
> usage of one
> already defined parameter, if a QoS model needs it. This could be done
> in the following way:
>   1. According to the QSPEC draft, each defined QSPEC parameter has a
> specified fixed value length - bandwidth - 4bytes, token bucket -20
> bytes, etc.
>   2. The structure of a QSPEC parameter may carry multiple values of a
> QSPEC parameter. Different values will be parsed based on the known
> fixed length of the parameter value.
>   3. Length field of the parameter structure will carry total
> length of
> the parameters values.
>
> The format for bandwidth would be this:
> | Object ID | Parameter ID = 3 | Length = 8 bytes | Bandwidth
> value 1 |
> Bandwidth value 2 |
>
> For interoperability, if a mandatory parameter with such
> multiple-value
> structure is used, all nodes must interpret the first value. If a node
> supports the QoS model that uses such multiple-value
> parameter it makes
> use of all values.
>
> I hope I don't misunderstand the QSPEC usage.
>
> Greetings,
>
> tseno_
>
>
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

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

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

---

From: Tseno Tsenov <[email-masked]>
Date: Wed, 10 Aug 2005 15:16:04 +0200

Hi Roy,

How I understand the idea of QSPEC and QoS model:

QSPEC template defines a number of QoS parameters that describe certain QoS/resources, priority,.../.
A QoS Model, use these parameters as well as define its own QoS parameters in order to signal/achieve QoS in its domain using its QoS methods. It must define how to import from the received QSPEC template parameters the QoS description and how to map it to its QoS parameters in the ingress node. Then in the egress node it must define how to export the QoS description resulting from its intra domain QoS signaling method to the QSPEC template parameters. As such, I see the mandatory QoS parameters defined in the QSPEC template as anchor parameters from which any QoS model can derive the required/available/reserved QoS description.  And even if a given QoS model can't re-use any of the present QSPEC parameters but have to define its own optional set, it should map properly its parameters to the mandatory ones in the egress node of its domain.

For such mandatory QSPEC parameters are used QoS parameters of well-known QoS models such as Intserv or Diffserv. And therefore there is overlapping between the QSPEC template and these QoS models. 

I hope, there is something correct in this.

Greetings,
Tseno

Original Message:

Tseno:
<br /> 
<br />The fundamental problems are as follows:
<br /> 
<br />1. QoS models defined so far in all cases of all standards are NOT unique because they consider as a set of performance parameters arbitrarily depending on which standard fora/bodies they belong to.
<br /> 
<br />2. If you ask what is the define of QoS model, you will get different answers because it is a matter of grouping some performance parameters here and there. For example, some has delay parameters, some has delay and delay jitter, some has delay, jitter, and packet losses, etc. So, why do you run after those QoS models in the first place while you are doing standardization works for "QoS signaling" works in the IETF when you cannot generalize the QoS model?
<br /> 
<br />3. It is "funny" to see that draft does NOT define what a QoS model is. As if, anything ever defined on the earth in the name of QoS model can be included in QSPEC because the draft itself does NOT know what is meant by QoS model. As a result, the draft has created a funny situations that contradict itself for the "same" performance parameter: i. Use values with no Restrictions and ii. Use values with Restrictions.
<br /> 
<br />4. Again, QoS classes of a given QoS model are defined based on some "specific values" for which there is no technical context in terms of wireless LANs, cellular, satellite, ad hoc, and/or wired line networks. Here lies another set of contradictions because "values" cannot be used by users as they may contradict. 
<br /> 
<br />For example, in related threads I explained (John L. also agreed that users will do so if values for the inter-domains communications are not carefully constructed) why there should be restrictions in use of those values in the first place. 
<br /> 
<br />6. To remove this, I have proposed to split the draft into two parts: a. Where values do not contradict following the "generalized" principles of NSIS QoS signaling charter as all of us including yourself want, and b. Where values can be restricted in funny ways and let the users restrict themselves as they suppose to do for inter-domain QoS signaling where nothing can be "generalized" as you have observed (Or, remove this part from the draft altogether).
<br /> 
<br />Hope this clarifies the things.
<br /> 
<br />Best regards,
<br />Radhika
<br />
<br />________________________________
<br />
<br />From: [email-masked] on behalf of Kappler, Cornelia
<br />Sent: Tue 8/9/2005 4:17 AM
<br />To: Ash, Gerald R (Jerry), ALABS; Tseno Tsenov; [email-masked]
<br />Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instancesofdefined parameters
<br />
<br />
<br />
<br />Hi Tseno,
<br />
<br />if we expect multiple instances of the same parameter are something that
<br />is frequent in QOSMs I think we should go for your proposal which is a
<br />rather efficient way of coding it. On the other hand, I am not sure how
<br />likely it is that a QoS Model needs e.g. multiple values of QoS Classes?
<br />Isnt the token bucket quite a special case? All QOSMs we looked at so
<br />far, except DiffServ, dont need this feature.
<br />
<br />In any event we probably should make (if at all) mandatory only the
<br />first instance (i.e. a QNE implementing a QoS Model that doesnt need any
<br />(or multiple) instances of this parameter should only be forced to
<br />interpret the first occurrance.)
<br />
<br />A related question:
<br />What if a QNI wishes to code e.g. QoS Class, and has a very good idea
<br />that it wants a specific PHB from QNEs implementing the DiffServ QOSM, a
<br />specific Y.1541 QoS Class from QNEs implementing the Y.1441 QOSM etc. Is
<br />it allowed to include values for each type of QoS class it knows about?
<br />This is another usage of "multiple instances" (in fact it is more like
<br />"multiple values". Note this means a QNE would have to parse all these
<br />values to find out whether one specific to its QOSM is included. May be
<br />too much feature creep.
<br />
<br />Cornelia
<br />
<br />> -----Original Message-----
<br />> From: [email-masked] [mailto:[email-masked]] On
<br />> Behalf Of Ash, Gerald R (Jerry), ALABS
<br />> Sent: Sonntag, 7. August 2005 00:44
<br />> To: Tseno Tsenov; [email-masked]
<br />> Cc: Ash, Gerald R (Jerry), ALABS
<br />> Subject: RE: [NSIS] QSPEC extensibility and re-use of
<br />> multiple instances ofdefined parameters
<br />>
<br />>
<br />> Tseno,
<br />>
<br />> I like your suggestion.  I think it both simplifies and
<br />> generalizes the
<br />> QSPEC to handle multiple instances of the same parameter.  The second
<br />> and higher instances of any parameter could be defined as optional.
<br />> Procedures for multiple uses of a QSPEC parameter would have to be
<br />> defined by a given QOSM.
<br />>
<br />> What do others think?
<br />>
<br />> Thanks,
<br />> Jerry
<br />>
<br />> -----Original Message-----
<br />> From: [email-masked] [mailto:[email-masked]] On
<br />> Behalf Of
<br />> Tseno Tsenov
<br />> Sent: Friday, August 05, 2005 6:03 AM
<br />> To: [email-masked]
<br />> Subject: [NSIS] QSPEC extensibility and re-use of multiple
<br />> instances of
<br />> defined parameters
<br />>
<br />> Hi,
<br />>
<br />> In my opinion, the current QSPEC draft miss flexibility for multiple
<br />> usage of QSPEC parameters of one type.  Currently, for usage of two
<br />> token bucket in DiffServ EF PH QoS model, two separate mandatory token
<br />> buckets are defined (ID=5 and 6). And for example, if a new QoS model
<br />> requires 3 token buckets at some later point, it must define an
<br />> additional optional token bucket parameter.
<br />> Why don't the QSPEC template provide a method for multiple
<br />> usage of one
<br />> already defined parameter, if a QoS model needs it. This could be done
<br />> in the following way:
<br />>   1. According to the QSPEC draft, each defined QSPEC parameter has a
<br />> specified fixed value length - bandwidth - 4bytes, token bucket -20
<br />> bytes, etc.
<br />>   2. The structure of a QSPEC parameter may carry multiple values of a
<br />> QSPEC parameter. Different values will be parsed based on the known
<br />> fixed length of the parameter value.
<br />>   3. Length field of the parameter structure will carry total
<br />> length of
<br />> the parameters values.
<br />>
<br />> The format for bandwidth would be this:
<br />> | Object ID | Parameter ID = 3 | Length = 8 bytes | Bandwidth
<br />> value 1 |
<br />> Bandwidth value 2 |
<br />>
<br />> For interoperability, if a mandatory parameter with such
<br />> multiple-value
<br />> structure is used, all nodes must interpret the first value. If a node
<br />> supports the QoS model that uses such multiple-value
<br />> parameter it makes
<br />> use of all values.
<br />>
<br />> I hope I don't misunderstand the QSPEC usage.
<br />>
<br />> Greetings,
<br />>
<br />> tseno_
<br />>
<br />>
<br />>
<br />> _______________________________________________
<br />> nsis mailing list
<br />> [email-masked]
<br />> https://www1.ietf.org/mailman/listinfo/nsis
<br />>
<br />
<br />_______________________________________________
<br />nsis mailing list
<br />[email-masked]
<br />https://www1.ietf.org/mailman/listinfo/nsis
<br />
<br />
<br />

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Sun, 21 Aug 2005 15:58:51 -0400

Tseno and all:
 
We all support John's view as we described before as explained before as follows:

1.	
	Present QSPEC draft needs to delete those QOS model-specific specific parts of draft as John L. has also admitted that it will create problems if domains are NOT constructed carefully.
2.	
	Tseno has suggested to generalize the extensions related QOS models for making draft consistent as the draft itself is NOT specific for extensions of any specific QOS models. Jerry suggested to use multiple instances to take care of this problem. John L. has gone further in explaining why Jerry's suggestions for multiple instances of the same parameter is NOT acceptable.
3.	
	The present QSPEC draft, for example, has extended the QSPEC for Y1541 which itself is incomplete. Because the another draft  http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt- shows many more QSPEC extensions specific to Y1541 QOS model is needed to support the Y1541 QOS model. So, this Y1541-QOSM draft is the right place for dealing with all QSPEC extensions-specific to Y1541 QOS model. This draft (y1541-qosm) must also explain how this Y1541 QOS model-specific "DOMAIN" needs to created without contradicting in "values" of end-to-end QOS parameters used in the templates as expressed by applications.

So, the QSPEC draft is the generalized QOS templates that can be used by NSIS QOS signaling messages, and MUST delete all technically inconsistent QOS model-specific (e.g., Y1541) extensions.

Best regards,
Radhika

From: [email-masked] on behalf of Ash, Gerald R (Jerry), ALABS
Sent: Sat 8/20/2005 10:44 PM
To: Kappler, Cornelia; Tseno Tsenov; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instancesofdefined parameters

Hi Cornelia,

> Hi Tseno - and John and Jerry,
>
> so there doesnt seem to be much concrete use for this
> additional kind of extensibility. Therefore my suggestion
> is to not support it.

I agree, and support John's view that QSPEC functionality not be so
extended unless there is a clear need.

Thanks,
Regards,
Jerry