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

From: Tseno Tsenov <[email-masked]>
Date: Fri, 05 Aug 2005 12:03:23 +0200

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sat, 6 Aug 2005 17:43:43 -0500

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.

Greetings,

tseno_

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 17 Aug 2005 14:16:37 -0400

Cornelia:

In response to one of Tseno's questions, you have mentioned as follows:

".. accommodate as many QoS Models as possible .."

In fact, it is NOT true. Even the QOS model like Y.1541 that has been
trying to be accommodated fully in the draft has been failed. Please see
the following draft: 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt

The above draft shows that more extensions in QSPEC template are needed.

The basic question is this: Why do you want to include the QOS
model-specific extensions in the "generalized" QSPEC template draft?

What you have done is this: Included Y1541 QOS model (which is also
incomplete) and DSTE QOS model (a cheap shot - basically only one
parameter). 

Tseno has mentioned the most fundamental QOS models of the IETF: IntServ
and DiffServ. You have failed to explain why you have not included those
in the draft.

What do you mean that you have accommodated as many QOS models as
possible?

Why do you NOT "delete" all so-called QOS model-specific extensions from
this draft?

The way you should proceed is as follows:

1.	Make the draft-ietf-nsis-y1541-qosm-00.txt complete including
"all" extensions QSPEC specific to y1541using all "specific values."
Also, show how to create y1541 domains using specific values without
contradicting the end-to-end values from end users' and/or applications'
point of view so that people can implement without creating any
confusions or contradictions.

2.	Do the same writing another draft for DSTE model as explained in
item 1.

3.	Delete all QOS model-specific extensions in the generalized
QSPEC draft.

In this way, all drafts will be clean.

If you have any questions, please let us know.

Best regards,
Radhika

PS: I also explained in earlier emails (John L. also agreed) that the
use of both generalized QSPEC template and QOS model-specific QSPEC
template will create contradictions if domains are not created
carefully. The present QSPEC draft does not explain how to create
respective QOS domains using specific values in the first place.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kappler, Cornelia
Sent: Wednesday, August 17, 2005 4:22 AM
To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances
of defined parameters

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
- accommodate 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)
didn't really get the idea.

Cornelia

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

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 17 Aug 2005 14:46:52 -0400

John:

You are right.

The multiple instances of the same parameter will create a nightmare all
by itself even we do not need interoperability.

The reasons are simple (because what will be the criteria for using
multiple instances of the same parameter?): 

1.	Is it due to time dependence?
2.	Is it due to time dependence where no QOS domains like IntServ
and DiffServ or QOS model-specific domains like y1541 are used?
3.	Is it due to different kinds of QOS domains like IntServ and
DiffSeve? 
4.	Is it due to different kinds of QOS model-specific domains like
y1541 that are based on some values?
5.	Is it due to combination of items 1 and 2?
6.	Others?

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, August 17, 2005 2:41 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances
of defined parameters

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

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 17 Aug 2005 15:08:45 -0400

Hi, Tseno:

QSPEC and QoS Model are two different things.

1.	QSPEC Template and NSIS QOS Signaling Messages

QSPEC defines the templates for carrying QOS parameters, and each QOS
parameter will have its "specific" value to meet the needs of the
application (e.g., SIP/SDP).

SIP/SDP defines the codecs that need to be supported on end-to-end basis
(e.g., codec-to-codec). Each codec type has its own performance (e.g.,
delay, jitter, losses) requirements on end-to-end basis (codec-to-codec)
as can be seen in each codec spec.

In addition, if specific QOS cannot be met per pre-specified codec
standards, end users will be able to negotiate the QOS requirements. 

SIP/SDP allows to negotiate codecs, but the specific QOS parameters of
each codec either as pre-specified or through negotiation. So, NSIS QOS
signaling including QSPEC templates will be used to do so.

Per NSIS charter, QSPEC needs to have signaling template messages to
satisfy the above because NSIS QOS signaling is to meet application's
needs.

You can observe two things as follows:

*	No restrictions in putting the "values" in signaling messages.
*	QOS models do NOT come into the picture of the NSIS QOS
signaling messages.

2.	QOS Models

QOS models developed so far are usually are "network centric." That is,
they usually deal with networks and are decouples from the applications.
They do not deal with applications directly.

However, IETF's IntServ and DiffServ QOS models are "perfect" because
they define the signaling messages without providing any restrictions in
"values" of any performance parameters.

So, if you want to use QSPEC "generic" templates in conjunction with the
IETF's IntServ and DiffServ QOS models, it is OK.

However, it is NOT the case with non-IETF QOS models like Y.1541, and
the earlier threads of mine explain clearly how contradictions come into
play. So, models like Y.1541 must NOT be a part of the QSPEC template
draft that is generic.

You are right that each QOS model needs to describe how it will import
all the QSPEC templates in "network centric environments" that are not
end-to-end and decoupled from the applications. 

That is why, each QOS model needs to create a "separate" draft known as
"use case" of QSPEC and NSIS signaling messages (not to "dump" as it is
done now in the present QSPEC draft).

Hope this clarifies the things once more.

Best regards,
Radhika

-----Original Message-----
From: Tseno Tsenov [mailto:[email-masked]] 
Sent: Wednesday, August 10, 2005 9:16 AM
To: Roy, Radhika (AEAD); [email-masked]
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances
of defined parameters

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

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Thu, 18 Aug 2005 10:14:13 +0200

Hi Radhika, 
 
frankly, I dont see the point of your questions, and my impression is
nor does anybody else. Rather than taking a lot of time trying to
explain (again) everything I'd like to quote rough working group
consensus that the QSPEC is ok the way it is. 
 
Cornelia

	-----Original Message-----
	From: Roy, Radhika (AEAD) [mailto:[email-masked]] 
	Sent: Mittwoch, 17. August 2005 20:17
	To: Kappler, Cornelia
	Cc: Tseno Tsenov; [email-masked]
	Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple
instances of defined parameters

	Cornelia:

	In response to one of Tseno's questions, you have mentioned as
follows:

	In fact, it is NOT true. Even the QOS model like Y.1541 that has
been trying to be accommodated fully in the draft has been failed.
Please see the following draft: 

http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt
<http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt> 

	The above draft shows that more extensions in QSPEC template are
needed.

	What you have done is this: Included Y1541 QOS model (which is
also incomplete) and DSTE QOS model (a cheap shot - basically only one
parameter). 

	Tseno has mentioned the most fundamental QOS models of the IETF:
IntServ and DiffServ. You have failed to explain why you have not
included those in the draft.

	What do you mean that you have accommodated as many QOS models
as possible?

	Why do you NOT "delete" all so-called QOS model-specific
extensions from this draft?

	1.      Make the draft-ietf-nsis-y1541-qosm-00.txt complete
including "all" extensions QSPEC specific to y1541using all "specific
values." Also, show how to create y1541 domains using specific values
without contradicting the end-to-end values from end users' and/or
applications' point of view so that people can implement without
creating any confusions or contradictions.

	2.      Do the same writing another draft for DSTE model as
explained in item 1. 

	3.      Delete all QOS model-specific extensions in the
generalized QSPEC draft. 

	Best regards,

	Radhika

	PS: I also explained in earlier emails (John L. also agreed)
that the use of both generalized QSPEC template and QOS model-specific
QSPEC template will create contradictions if domains are not created
carefully. The present QSPEC draft does not explain how to create
respective QOS domains using specific values in the first place.

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kappler, Cornelia
	Sent: Wednesday, August 17, 2005 4:22 AM
	To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; [email-masked]
	Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple
instances of defined parameters

	so there doesnt seem to be much concrete use for this additional
kind of

	In the QSPEC we tried to balance two mutually exclusive
requirements

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

	Cornelia

---

From: Radhika Roy <[email-masked]>
Date: Thu, 18 Aug 2005 14:10:10 -0400

Hi, Cornelia:

Whatever you may say, the draft is NOT technically consistent with respect
to QSPEC extensions specific to QOS models as you yourself has admitted
(e.g., you tried .. ".. accommodate as many QoS Models as possible .."

You will be better off 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.
 
Tseno has suggested to generalize the extensions related QOS models for
making draft consistent. 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.
 
So, where is the consensus unless you remove those technical inconsistencies
through deleting the QOS specific extension part of the draft?
 
Best regards,
Radhika
 
Title: Message

Hi Radhika, 

frankly, I dont see the point of your questions, and my impression is nor
does anybody else. Rather than taking a lot of time trying to explain
(again) everything I'd like to quote rough working group consensus that the
QSPEC is ok the way it is. 

Cornelia

-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:RoyR at saic-abingdon.com] 
Sent: Mittwoch, 17. August 2005 20:17
To: Kappler, Cornelia
Cc: Tseno Tsenov; nsis at ietf.org
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of
defined parameters

Cornelia:

In fact, it is NOT true. Even the QOS model like Y.1541 that has been trying
to be accommodated fully in the draft has been failed. Please see the
following draft: 

Tseno has mentioned the most fundamental QOS models of the IETF: IntServ and
DiffServ. You have failed to explain why you have not included those in the
draft.

What do you mean that you have accommodated as many QOS models as possible?

1.      Make the draft-ietf-nsis-y1541-qosm-00.txt complete including "all"
extensions QSPEC specific to y1541using all "specific values." Also, show
how to create y1541 domains using specific values without contradicting the
end-to-end values from end users' and/or applications' point of view so that
people can implement without creating any confusions or contradictions.

3.      Delete all QOS model-specific extensions in the generalized QSPEC
draft. 

Best regards,

Radhika

PS: I also explained in earlier emails (John L. also agreed) that the use of
both generalized QSPEC template and QOS model-specific QSPEC template will
create contradictions if domains are not created carefully. The present
QSPEC draft does not explain how to create respective QOS domains using
specific values in the first place.

-----Original Message-----
From: nsis-bounces at ietf.org [mailto:nsis-bounces
<mailto:nsis-bounces%20at%20ietf.org>  at ietf.org] On Behalf Of Kappler,
Cornelia
Sent: Wednesday, August 17, 2005 4:22 AM
To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; nsis at ietf.org
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of
defined parameters

many parameters. 

of this QOSM. 

Cornelia