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

From: [email-masked]
Date: Wed, 17 Aug 2005 09:40:55 +0300

Jerry,

>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?

I think it's a trade-off.  I am worried about making things too complex.
Are multiple instances really useful or needed?  The risk of supplying
too many options and too much extensibility is that managing the
QoS parameters in a network & inter-working between different networks
will be quite complex.  I think we should only support this if there is
a real need. 

John

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

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Wed, 17 Aug 2005 10:22:20 +0200

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. 

Regarding your (Tseno) 2nd paragraph: 
In the QSPEC we tried to balance two mutually exclusive requirements
- accomodate as many QoS Models as possible
- make the QSPEC as widely understood as possible without defining too
many parameters. 
We solved this problem by defining mandatory parameters which we expect
to be used in most QOSMs (e.g. bandwidth); and by requesting all QNEs to
_understand_ the mandatory parameters. That is, for a QOSM that has no
use of the mandatory parameters (which is quite unlikely by the way)
these parameters _dont need to be included_ in the QSPEC. However this
makes it unlikely that this QSPEC will be understood outside the domain
of this QOSM. 

I guess we have to explain this better in our document as this is not
the first time somebody (particularly someone really familiar with NSIS)
didnt really get the idea.

Cornelia

> -----Original Message-----
> From: Tseno Tsenov [mailto:[email-masked]] 
> Sent: Mittwoch, 10. August 2005 20:30
> To: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: [NSIS] QSPEC extensibility and re-use of 
> multiple instances ofdefined parameters
> 
> 
> 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,
> 
> 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,
> >
> > 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_
> >
> >
> >

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sat, 20 Aug 2005 21:44:11 -0500

Hi Cornelia,

> 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