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

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 9 Aug 2005 10:17:02 +0200

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

---

From: "Tseno Tsenov" <[email-masked]>
Date: Wed, 10 Aug 2005 20:30:06 +0200

Hi Cornelia,

I agree that currently there might be no QoS model that uses multiple values
of one QoS parameter (except the DiffServ case). However the current
encoding approach restricts the extensibility of the QSPEC.

Your example with usage of two different QoS classes which are mandatory
parameters (and are redundant in some sense) raises other question for me:
Again, we have a new QoS model does not use any of the mandatory QSPEC
parameters and defines its own set of optional QSPEC parameters. Then, is it
expected that some mandatory QSPEC parameters will be "artificially"
included which will provide interoperability with other QoS models?

greetings,
Tseno_

----- Original Message ----- 
From: "Kappler, Cornelia" <[email-masked]>
To: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>; "Tseno Tsenov"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, August 09, 2005 10:17 AM
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances
ofdefined parameters

Hi Tseno,

A related question:

Cornelia