Subject: [NSIS] conensus of sundays meeting and rolands proposal

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 07 Nov 2006 16:21:27 +0000

Hi all

I thought that during the meeting of Sunday we reached the following
three points of consensus, on the following:

Consensus_1):
Use the QSpec template draft as is but change the following:

The QSPEC1/QSPEC2 sematincs are replaced by Daves proposal for traffic
source description, where a generic (end-to-end) QSPEC has to be
interpreted by QNEs.
However, the additions/modifcations to this proposal are related to the
fact that a consensus was reached where the local/private QOS models can
use stacking and that they can map/interpret the traffic source
description into their own local/private QSPEC and ignore the end-to-end
QSPEC.
The mapping/interpreatation procedure will be specified in each QoS model.
In this consnsus we also agreed that it should be possible that more than
two QSPECs should be able to be satcked, where at least one oif them is
the end-to-end QSPEC.

The way of how the stacked objects are processed should then be decribed
in the QOS-NSLP draft.

The consequence of the above on the QOS-NSLP, QSPEC tempalet draft and
QOS models is the following:

* The QSPEC template draft will not use anymore the notion of
QSPC1/QSPEc2 objects and instead use the traffic source description
proposed by Dave Oran.

* All the other QSPEC parameers  that currently are described in the
QSPEC template draft have to be considered as optional to implement by
the QNEs.

* The R and Q fags are eliminated since remapping is not allowed.

* The mapping/interpreattion of the traffic source description is
described in the QoS models and not in the QSPEC template draft.

* The QSPEC template draft has to decribe how a QOS model can stack the
QSPEC objects, which is a similar description that we have now in the
QSPEC templated draft. It has to empasize how the stacked QSPEc objest
are interpreted by the QOS models.

* Further the features/procedures/etc. described in the QSPEC template
draft remain the same.

Consensus_2)
The QoS-NSLP remains the same as is now with the difference that more
than two QSPEC objects can be stacked. Note that only one is a real
QSPEC object, i.e., end-to-end QSPEC and the rest are private/local
QSPEC objects meaning that the two types of QSPEc objects will have tio
use different object IDs.

Consensus_3)
The goal of the QOS model, from the point of view of what it can specify
remains the same as now, but the QOS model will not use remapping,
however the QoS model has to describe how the end-to-end QSPEC (traffic
source description) has to be interpreted/mapped by the QNEs that are
supporting the QOS model.

This means that the QoS model can specify how the traffic source
description can be mapped into a local/private QSPEC. By using e.g.,
stacaking the end-to-end QSPEC can be then ignored.

------------Rolands proposal:

Now Roland has sent a new proposal that mainly agrees with the three
points of reached consensus, but it has two differences:

Difference_1:
The stacking concept is supported but the implementation of how the
stacking is specified and implemented is different.
Only one QSPEc is used. Thus any QoS model interprets only one QSPEC
object, which it can be either the end-to-end QSPEC or a local/private
QSPEC.

The local/private QSPEC can provide the concept of stacking by e.g.,
encapsulating the end-to-end QSPEC and providing means/ways to ignore
the end-to-end QSPEC. I suppose that if multiple levels are stacking are
used then a QOS model could ignore all the paramteres that might be
stacked by another QoS model (which is not the end-to-end QoS model) but
which arer not relevant for the local/private QoS model.
Then method/way of how teh end-to-end QSPEC has to be interpreted/mapped
has to be described in the QOS model specification.
In this way stacking is supproted, but it will not be anymore specified
in the QOS-NSLP, but in the QSPEC template draft and the QoS models.
Note that Roland does not mention in his proposal that the stacking
procedure has to be specified in the QSPEC template draft, but in my
opinuion this is necessary.

Difference_2:
Roland proposes to remove the description of all QoS model related
parameters from the QSPEC templated  draft. QoS model specific
parameters care the Y.1541, DSTE, PHB classes, etc..

I have a question for Roland:
Is my explanation of the three points of consensus, i.e., Consensus_1,
Consensus_2 and Consensus_3 in agreement with wath we have decided on
Sunday?

Do you agree that my explantion related to your proposal and to the 2
differences between the three points of consensus and your proposal is
the right one?

If yes, I can agree with Difference_1 only if we make sure that the
implementation of the stacking concept keeps its semantics. This also
means that the specification of how stacking is accomplished can be
removed from the QOS-NSLP draft, but it has to be specified/explained in
the QSPEC template draft and in the QOS models.

Regarding Difference_2 I can only agree if the editors of the QSEPC
template draft agree with the removal of all QoS model specific QSPEC
parameter descriptions from the QSPEC template draft.

Best Regards,
Georgios

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 7 Nov 2006 12:27:15 -0500

Hi, Georgios and all:
 
It is MANDATORY, as Ronald and Jukka, "to remove all QoS model specific QSPEC parameter descriptions from the QSPEC template draft." There must NOT be any "if" and "when." 
 
Before going any step further in order to make progress related to this "generic" standard-track RFC draft, we have to take this first mandatory step. 
 
Otherwise, we go back to the circle of arguments and conter-arguments of interworking. 
 
Best regards,
Radhika
 
________________________________

From: [email-masked] on behalf of Georgios Karagiannis
Sent: Tue 11/7/2006 11:21 AM
To: [email-masked]
Subject: [NSIS] conensus of sundays meeting and rolands proposal

Hi all

Consensus_1):

Consensus_2)

Consensus_3)

Difference_1:

Difference_2:

Best Regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Wed, 08 Nov 2006 19:05:30 +0100

Hi Georgios,

> object, which it can be either the end-to-end QSPEC or a local/private

Not quite. QoS-NSLP carries only one QSPEC object. It doesn't
mean that only one QSPEC is used or only one QSPEC is interpreted.
So if the X-QoS Model wants to carry also the E2E-QSPEC in its
own X-QSPEC it may interpret or not interpret the included E2E-QSPEC.
That's defined in the X-QoS Model/X-QSPEC

> which arer not relevant for the local/private QoS model.

Yep.

> in the QOS-NSLP, but in the QSPEC template draft and the QoS models.

Yep.

> opinuion this is necessary.

That actually depends. The current QSPEC template draft actually
mixes the template and the interop/Generic QSPEC things. One could
split it into two documents:
- one describing common QSPEC definition aspects (template)
- one the E2E-QSPEC (as an application of the previous draft)

> parameters care the Y.1541, DSTE, PHB classes, etc..

Yep.

> Consensus_2 and Consensus_3 in agreement with wath we have decided on

I'm not really sure that we reached _clear_ consensus there.
I guess that I understood your problems with the new proposal better.

> the QSPEC template draft and in the QOS models.

As I said: whether a QoS model needs something like stacking or not is
up to its own decision.

> parameter descriptions from the QSPEC template draft.

My idea behind the proposal was to have a clearer separation between
different models. Otherwise if a QSPEC crosses several domains each
QoS model may attach its own parameters, maybe only optional. In this
case I would like to see a scope flag as Jukka suggested so that
QOSM-specific parameters should probably be removed before passing on
to the next domain. Otherwise I don't know what an RMD-domain would
gain from seeing any Y.1541-specific parameters.

Regards,
 Roland