Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 1 Mar 2007 17:10:36 +0100

Hi Jerry

The need for the QOSM ID can be seen probably seen in the below e-mail:

Suppose that:

 A QNE supports the following:

 * end-to-end QOS Models: 
    QOSMI-1, QOSMI-2, QOSMI-3 

* local QoS Models:
    QOSML-1, QOSML-2, QOSML-3

Suppose now that the operator of such a QNE wants to use the follwing
combinations:

* QOSMI-1 with QOSML-3.

Meaning that end-to-end sessions and QOS-NSLP messages that are carrying 
initial QSPEC of QOSM-I1 should be bound with local sessions and local
QOS-NSLP messages that 
are carying local QSPEC of QOSM-L3

* QOSMI-2 with QOSML-3

Meaning that end-to-end sessions and QOS-NSLP messages that are carrying 
initial QSPEC of QOSMI-2 should be bound with local sessions and local
QOS-NSLP messages that 
are carying local QSPEC of QOSML-3

* QOSMI-3 with QOSML-1

initial QSPEC of QOSMI-3 should be bound with local sessions and local
QOS-NSLP messages that 
are carying local QSPEC of QOSML-1

* QOSMI-3 with QOSML-2

initial QSPEC of QOSMI-3 should be bound with local sessions and local
QOS-NSLP messages that 
are carying local QSPEC of QOSML-2
--

If the QOSM ID will not be supported these combinations will not beable to
be made meaning that 
A QNE will be able to support only one initial (end-to-end) QOSM with only
one local QOSM at a time.

Best Regards,
Georgios

> -----Original Message-----
> From: ASH, GERALD R, ATTLABS [mailto:[email-masked]] 
> Sent: woensdag 28 februari 2007 14:43
> To: Georgios Karagiannis; Martin Stiemerling; nsis
> Cc: ASH, GERALD R, ATTLABS
> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in 
> qspec draft
> 
> Georgios, All,
> 
> > -----Original Message-----
> > From: Georgios Karagiannis [mailto:[email-masked]]
> > Sent: Wednesday, February 28, 2007 12:37 AM
> > To: Martin Stiemerling; nsis
> > Subject: [NSIS] comment on reintroduction of QOSM-ID in qspec draft
> > 
> > Hi
> > 
> > I was busy updating some of the QOSM drafts and I have seen that 
> > starting from version 13 of the QSPEC draft, the QOSM ID field  is 
> > removed form the common header of a QSPEC object and 
> instead of this, 
> > the field QSPEC type is used.
> 
> The QSPEC Type was introduced to support Roland's QSPEC 
> stacking/encapsulation method (see 
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht
> ml), it does not replace QOSM ID.
> 
> The QOSM ID was removed in the discussion around the QSPEC-13 
> draft update, see the post on 1 November 2006 
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht
> ml, where it says "A QOSM ID need not be defined or signaled 
> and a QNE need not support any particular QOSM".  Slide 3 of 
> the QSPEC presentation at IETF-67 makes the same point.  The 
> same point is made again in the announcement of the draft to 
> the NSIS list at 
> http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht
> ml and the point is also made in Appendix A of the QSPEC 
> draft itself.  There were no objections to this point.
> 
> > I agree that QSPEC type (shows if the QSPEC object is initial or a 
> > local) is useful and it should be used, but by removing the QOSM ID 
> > field it will mean that a QNE can always support only one type of 
> > initial
> > (end-to-end) QOSM and one type of local QOSM.
> > That is not reasonable. A QNE should be able to support 
> many QOSMs and 
> > it should be able to distinguish and associate a QSPEC 
> object with a 
> > certain QOSM.
> 
> There is no mention in any QSPEC draft as to how or why a 
> QOSM ID field is needed or used.  A QNE can support any QOSM 
> it wants, it does not depend on a QOSM ID field from the QNI 
> to determine which one.
> 
> At a minimum, we would need to have a bit-level example of 
> how/why such a field is needed to justify reintroducing the 
> QOSM ID field.
> 
> > Therefore, I think that it is required that the QOSM ID 
> field should 
> > be reintroduced in the QSPEC common header. The field QSPEC type is 
> > also useful ant it should be kept.
> 
> We need clear justification to reintroduce the complexity of 
> having the QOSM ID field and the IANA registry to maintain 
> the parameter.
> 
> Jerry
>  
> > 
> > Best regards,
> > Georgios
> > 
> > 
> > On 2/20/2007, "Martin Stiemerling" 
> <[email-masked]> wrote:
> > 
> > >Dear all,
> > >
> > >I would like to start the working group last call for the 
> QSPEC draft 
> > >(http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt).
> > >
> > >The WGLC is starting today and will run for two weeks 
> until Tuesday 
> > >Feb 6th.
> > >
> > >Please send your comments to the NSIS WG list.
> > >
> > >   Martin
> > >
> > >Anfang der weitergeleiteten E-Mail:
> > >
> > >> Von: <[email-masked]>
> > >> Datum: 16. Februar 2007 21:50:02 MEZ
> > >> An: <[email-masked]>
> > >> Kopie: <[email-masked]>
> > >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt
> > >>
> > >> A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > >> directories.
> > >> This draft is a work item of the Next Steps in Signaling Working 
> > >> Group of the IETF.
> > >>
> > >> 	Title		: QoS NSLP QSPEC Template
> > >> 	Author(s)	: J. Ash, et al.
> > >> 	Filename	: draft-ietf-nsis-qspec-15.txt
> > >> 	Pages		: 54
> > >> 	Date		: 2007-2-16
> > >>
> > >> The QoS NSLP protocol is used to signal QoS reservations and is
> > >>    independent of a specific QoS model (QOSM) such as IntServ or
> > >>    DiffServ.  Rather, all information specific to a QOSM is 
> > >> encapsulated
> > >>    in a separate object, the QSPEC.  This document defines
> > a template
> > >>    for the QSPEC including a number of QSPEC parameters. 
>  The QSPEC
> > >>    parameters provide a common language to be re-used in
> > several QOSMs
> > >>    and thereby aim to ensure the extensibility and
> > interoperability of
> > >>    QoS NSLP.  The node initiating the NSIS signaling adds
> > an initiator
> > >>    QSPEC, which indicates the QSPEC parameters that must be 
> > >> interpreted
> > >>    by the downstream nodes less the reservation fails, thereby 
> > >> ensuring
> > >>    the intention of the NSIS initiator is preserved along the 
> > >> signaling
> > >>    path.
> > >>
> > >> A URL for this Internet-Draft is:
> > >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt
> > >>
> > >> To remove yourself from the I-D Announcement list, send a
> > message to
> > >> [email-masked] with the word unsubscribe in
> > the body of
> > >> the message.
> > >> You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > >> to change your subscription settings.
> > >>
> > >> Internet-Drafts are also available by anonymous FTP. 
> Login with the 
> > >> username "anonymous" and a password of your e-mail 
> address. After 
> > >> logging in, type "cd internet-drafts" and then "get 
> > >> draft-ietf-nsis-qspec-15.txt".
> > >>
> > >> A list of Internet-Drafts directories can be found in 
> > >> http://www.ietf.org/shadow.html or 
> > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >>
> > >> Internet-Drafts can also be obtained by e-mail.
> > >>
> > >> Send a message to:
> > >> 	[email-masked].
> > >> In the body type:
> > >> 	"FILE /internet-drafts/draft-ietf-nsis-qspec-15.txt".
> > >>
> > >> NOTE:	The mail server at ietf.org can return the document in
> > >> 	MIME-encoded form by using the "mpack" utility.  To use this
> > >> 	feature, insert the command "ENCODING mime" before the "FILE"
> > >> 	command.  To decode the response(s), you will need "munpack" or
> > >> 	a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> > >> 	exhibit different behavior, especially when dealing with
> > >> 	"multipart" MIME messages (i.e. documents which have been split
> > >> 	up into multiple messages), so check your local documentation on
> > >> 	how to manipulate these messages.
> > >>
> > >> Below is the data which will enable a MIME compliant mail reader 
> > >> implementation to automatically retrieve the ASCII version of the
> > >> Internet-Draft.)
> 
> _______________________________________________
> 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: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Thu, 1 Mar 2007 16:48:52 -0600

Georgios,

Your examples don't illustrate how and why a QOSM ID field is needed and
used.  

Perhaps you are saying that QoS NSLP and RMF communicate with messages
and that the I-QOSM ID and L-QOSM ID need to be included in those
messages so that the QoS NSLP can react differently based on which
L-QOSM is being used by the RMF?

If so, then this interaction suffers from the problems identified in
Cornelia's slide (attached) discussed on our conference call on 31
January.

If not, please give a more detailed example of how and why a QOSM ID
field is needed and used.

Jerry 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 11:11 AM
To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis'
Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft

Hi Jerry

Suppose that:

 * end-to-end QOS Models: 

* local QoS Models:

* QOSMI-1 with QOSML-3.

* QOSMI-2 with QOSML-3

* QOSMI-3 with QOSML-1

* QOSMI-3 with QOSML-2

If the QOSM ID will not be supported these combinations will not beable
to
be made meaning that 
A QNE will be able to support only one initial (end-to-end) QOSM with
only
one local QOSM at a time.

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 2 Mar 2007 11:19:55 +0100

Hi Jerry

The main goal of using the QOS-NSLP messages is to 
carry a QSPEC object and deliver it to the right QOSM/RMF.

If a QNE will support simultaneously more than one QOS models, say QOSM-I1,
QOSM-I2, 
and a QoS-NSLP message, which carries a QSPEC that is say associated with
QOSM-I1,
arrives at a QNE, then the QNE must be able to deliver 
the received QSPEC to the right RMF/QOSM, i.e., QOSM-I1.

 How the QNE will know to which RMF it should deliver the received QSPEC?

Best regards,
Georgios

> Sent: donderdag 1 maart 2007 23:49
> Your examples don't illustrate how and why a QOSM ID field is 
> needed and used.  
> 
> Perhaps you are saying that QoS NSLP and RMF communicate with 
> messages and that the I-QOSM ID and L-QOSM ID need to be 
> included in those messages so that the QoS NSLP can react 
> differently based on which L-QOSM is being used by the RMF?
> 
> If so, then this interaction suffers from the problems 
> identified in Cornelia's slide (attached) discussed on our 
> conference call on 31 January.
> 
> If not, please give a more detailed example of how and why a 
> QOSM ID field is needed and used.
> 
> Jerry 
> 
> initial QSPEC of QOSM-I1 should be bound with local sessions 
> and local QOS-NSLP messages that are carying local QSPEC of QOSM-L3
> 
> * QOSMI-2 with QOSML-3
> 
> initial QSPEC of QOSMI-2 should be bound with local sessions 
> and local QOS-NSLP messages that are carying local QSPEC of QOSML-3
> 
> * QOSMI-3 with QOSML-1
> 
> initial QSPEC of QOSMI-3 should be bound with local sessions 
> and local QOS-NSLP messages that are carying local QSPEC of QOSML-1
> 
> * QOSMI-3 with QOSML-2
> 
> initial QSPEC of QOSMI-3 should be bound with local sessions 
> and local QOS-NSLP messages that are carying local QSPEC of QOSML-2
> --
> 
>

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Sun, 4 Mar 2007 22:41:59 -0600

Georgios, All, 

> Sent: Friday, March 02, 2007 5:20 AM

First, the notion of multiple RMF/QOSMs that a QNE might decide to
deliver a QSPEC to makes no sense to me.  Even so, if a QSPEC carries an
I-QOSM ID, how does a QNE decide which of the multiple RMF/L-QOSMs to
send it to based only on the I-QOSM ID?  Presumable it would have to
decide based on other content of the QSPEC in addition to the QOSM-ID.

We still haven't gotten a concrete bit-level example of how the QOSM ID
might be used.    Without such clear justification I don't think
reintroducing the QOSM ID field can be supported.

It would be good for others to comment on this.

Thanks,
Jerry

> > Suppose now that the operator of such a QNE wants to use 
> the following
> > combinations:
> > 
> > * QOSMI-1 with QOSML-3.
> > 
> > and local QOS-NSLP messages that are carrying local QSPEC of QOSM-L3
> > 
> > * QOSMI-2 with QOSML-3
> > 
> > and local QOS-NSLP messages that are carrying local QSPEC of QOSML-3
> > 
> > * QOSMI-3 with QOSML-1
> > 
> > and local QOS-NSLP messages that are carrying local QSPEC of QOSML-1
> > 
> > * QOSMI-3 with QOSML-2
> > 
> > and local QOS-NSLP messages that are carrying local QSPEC of QOSML-2
> > --
> > 
> >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 05 Mar 2007 07:34:09 +0000

Hi Jerry

You have not answered my question:
How the QNE (that supports simultaneously multiple RMF/QOSM) will know to
which RMF it should deliver the received QSPEC?

If your answer is yes the QNE should be able to do that then we will have
to include the QOSM ID, otherwise is there no other way to make this
distinction.
Please note that we need both the QSPEC Type and QOSM ID fields.
Regarding your new question please see in line:

On 3/5/2007, "ASH, GERALD R, ATTLABS" <[email-masked]> wrote:

>deliver a QSPEC to makes no sense to me.  

Georgios: What do you mean?
Suppose that a QNE needs to simultaneously support the Intserv like
controlled load, the intserv like guaranteed service and the Y.1541.
These QOSMs will use a different QSPEC.
When a QNE receives a message how the QNE will know by which RMF/QOSM
this QSPEC should be used.
If we use a QOSM ID, then the QNI (when QSPEC is initial) or QNI at
Ingress or Egress (when QSPEC is local) will include the QOSM ID into
the QSPEC. Any QNE downstream that receives the QSPEC will be able to
relate the QSPEC object to the right RMF/QOSM by looking to the QOSM ID.

> Even so, if a QSPEC carries an

Georgios:
As i mentioned above, the QNI (when QSPEC in initial) or the QNI at the
Ingress or Egress (when the QSPEC is Local) will include the QOSm ID
into the QSPEC. Any QNE downstream can decide, based only on the QOSM
ID, to which RMF/QOSM should be delivered.

>reintroducing the QOSM ID field can be supported.

Georgios: What about the one mentioned above!

Best regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Mon, 05 Mar 2007 10:37:18 +0100

Hi Jerry,

> http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.html), it
> does not replace QOSM ID.

My intention was to have an ID for a specific QSPEC type, because
the same QSPEC may be understood by several different QoS-Models.
In that sense it would be a replacement for the QoSM ID. If a QOSM
needs specific (local) parameters it can define its own QSPEC type.
This particular QSPEC definition, however, may be (re-)used/applicable
by other QoSMs, too. That's why I thought it may be better to signal
a QSPEC type instead of a QOSM ID.

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 05 Mar 2007 09:58:00 +0000

Hi Roland

By using only the QSPEC type, will work only when  a QNE simultaneously
supports only one end-to-end QOSM and one local QOSM.
When a QNE supports say more than one end-to-end QOSMs and it receives a
QSPEC it will not know how to associate this QSPEC or the (specific to
one QOSM)  parameters contained in the QSPEC with the right QOSM.

Actually we need both, the QSPEC type and the QOSM ID.

Note that a QNE, such as an Ingress backbone router needs to support more
than one end-to-end QOSMs and local QOSMs.

Best regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Mon, 05 Mar 2007 13:21:26 +0100

Hi Georgios,

> supports only one end-to-end QOSM and one local QOSM.

I don't know how you come to this conclusion, but I would
say that:
1) your domain is likely to use only one QOSM
   (using the definition from the QSPEC terminology draft),
   i.e. one specific set of mechanisms to support QoS, e.g.
   DiffServ with a specific number of different service classes.
2) your domain may understand different QSPECs, usually
   one end-to-end QSPEC and one or more local QSPECs as
   long as there your QOSM defines a mapping from these
   QSPEC parameters to your QOSM internal parameters for
   admission control.

> one QOSM)  parameters contained in the QSPEC with the right QOSM.

Why not? I thought it is no problem to have a local table in the RMF
containing the set of supported QSPEC types. The QOSM must know how
to interpret the parameters and must assure that the requested
constraints are actually met (in case of admission). From an interface
perspective I don't care about the particular type of QOSM that you are
running as long as you can correctly decide about the admission of my
QoS request (i.e. QSPEC).

> Actually we need both, the QSPEC type and the QOSM ID.

I don't see a reason to signal the QOSM. It's clear that
some QSPEC types may be specific to particular QOSMs.
For instance, QOSM A may use QSPEC A and QOSM B may use
QSPEC B locally. QOSM C may be a variant of QOSM A but
uses the same QSPEC A. It might be the case that QOSM B understands
QSPEC A _and_ QSPEC B (usually as well as the global E2E QSPEC),
so I don't see a good reason to signal the QOSM.

> than one end-to-end QOSMs and local QOSMs.

Probably, but I don't see any problem in doing so with only the QSPEC
type.

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Mar 2007 13:43:43 +0100

Hi Roland

 Please see in line!

> From: Roland Bless [mailto:[email-masked]] 
> Sent: maandag 5 maart 2007 13:21
> To: Georgios Karagiannis
> Cc: ASH, GERALD R, ATTLABS; Martin Stiemerling; nsis
> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in 
> qspec draft
> 
> Hi Georgios,
> 
> > By using only the QSPEC type, will work only when  a QNE 
> > simultaneously supports only one end-to-end QOSM and one local QOSM.
> 
> I don't know how you come to this conclusion, but I would say that:

Georgios: Why only one end-to-end QSPEC? 
A QNE might support more than one end-to-end QOSMs and more 
than one local (intra-domain) QOSMs.

Therefore, it will be very complex for the QNE, when it receives a QSPEC 
to know to which RMF/QOSM to send the received QSPEC. In particular, for the
situations that all QOSMs use the same types of QSPEC (private) parameters.

By including the QSPEC Type and QOSM ID a QNE will know exactly how and 
where (to which RMF/QOSM) to send the received QSPEC.

> 
> > When a QNE supports say more than one end-to-end QOSMs and 
> it receives 
> > a QSPEC it will not know how to associate this QSPEC or the 
> (specific 
> > to one QOSM)  parameters contained in the QSPEC with the right QOSM.
> 
> Why not? I thought it is no problem to have a local table in 
> the RMF containing the set of supported QSPEC types. The QOSM 
> must know how to interpret the parameters and must assure 
> that the requested constraints are actually met (in case of 
> admission). From an interface perspective I don't care about 
> the particular type of QOSM that you are running as long as 
> you can correctly decide about the admission of my QoS 
> request (i.e. QSPEC).
> 
> I don't see a reason to signal the QOSM. It's clear that some 
> QSPEC types may be specific to particular QOSMs.
> For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC 
> B locally. QOSM C may be a variant of QOSM A but uses the 
> same QSPEC A. It might be the case that QOSM B understands 
> QSPEC A _and_ QSPEC B (usually as well as the global E2E 
> QSPEC), so I don't see a good reason to signal the QOSM.
> 
> > Note that a QNE, such as an Ingress backbone router needs 
> to support 
> > more than one end-to-end QOSMs and local QOSMs.
> 
> Probably, but I don't see any problem in doing so with only 
> the QSPEC type.

Georgios: Please see above!

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Mar 2007 13:54:45 +0100

Hi Roland

Sorry, I meant:
Why only one end-to-end QSPEC? 
A QNE might support more than one end-to-end QOSMs and more 
than one local (intra-domain) QOSMs.
 
Therefore, it will be complex for the QNE, when it 
receives a QSPEC to know to which RMF/QOSM to send the 
received QSPEC. In particular, for the situations that all 
QOSMs use the same types of QSPEC (private) parameters, but use different
semantics and values for these QSPEC private parameters.
In the solution that you proposed it will mean that each QOSM will have to
check all
QSPEC parameters to find out if the sematics of some of them can be
understood etc...
And I am not sure if all situations can be covered. Are you?

By including the QSPEC Type and QOSM ID a QNE will know 
exactly how and where (to which RMF/QOSM) to send the received QSPEC.
Thius is a very clean solution that does not introduce any additional 
complexity, just some bits in the common header of the QSPEC object.

Best regards,
Georgios

> Sent: maandag 5 maart 2007 13:44
> To: 'Roland Bless'
> Cc: 'ASH, GERALD R, ATTLABS'; 'nsis'; 'Martin Stiemerling'
> > Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec 
> > draft
> > 
> > Hi Georgios,
> > 
> Therefore, it will be very complex for the QNE, when it 
> receives a QSPEC to know to which RMF/QOSM to send the 
> received QSPEC. In particular, for the situations that all 
> QOSMs use the same types of QSPEC (private) parameters.
> 
> By including the QSPEC Type and QOSM ID a QNE will know 
> exactly how and where (to which RMF/QOSM) to send the received QSPEC.
> 
> 
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 5 Mar 2007 13:21:21 -0000

hi, 

> Sent: 05 March 2007 04:42
> > The main goal of using the QOS-NSLP messages is to carry a QSPEC 
> > object and deliver it to the right QOSM/RMF.
> > 
> > If a QNE will support simultaneously more than one QOS models, say 
> > QOSM-I1, QOSM-I2, and a QoS-NSLP message, which carries a 
> QSPEC that 
> > is say associated with QOSM-I1, arrives at a QNE, then the 
> QNE must be 
> > able to deliver the received QSPEC to the right RMF/QOSM, i.e., 
> > QOSM-I1.
> > 
> First, the notion of multiple RMF/QOSMs that a QNE might 
> decide to deliver a QSPEC to makes no sense to me.  Even so, 
> if a QSPEC carries an I-QOSM ID, how does a QNE decide which 
> of the multiple RMF/L-QOSMs to send it to based only on the 
> I-QOSM ID?  Presumable it would have to decide based on other 
> content of the QSPEC in addition to the QOSM-ID.

i'm also confused by the concept of multiple RMFs at a node; at
least, not multiplexed on model identity. sure the role of an
RMF is to coordinate the management of the resources at a node.
if you have multiple RMFs all allocating from a common resource
then something at a higher level would have to coordinate 
contending requests for them (which seems to be leading towards 
infinite regress...).

to put it another way, i would expect the RMF to be identified 
based on what resources a request was going to draw on. so that
might be an outgoing interface, or a queue on an interface
(where the queue parameters are semi-statically configured).

robert h.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Mar 2007 14:25:57 +0100

Hi Robert

I agree that the (input/outgoing) interface is important, butb this is
An implementation issue.

The problem that I have is explained in detail in the e-mail sent to Roland:

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: maandag 5 maart 2007 14:21
> To: ASH, GERALD R, ATTLABS; Georgios Karagiannis; Martin 
> Stiemerling; nsis
> > deliver a QSPEC to makes no sense to me.  Even so, if a 
> QSPEC carries 
> > an I-QOSM ID, how does a QNE decide which of the multiple 
> RMF/L-QOSMs 
> > to send it to based only on the I-QOSM ID?  Presumable it 
> would have 
> > to decide based on other content of the QSPEC in addition to the 
> > QOSM-ID.
> 
> i'm also confused by the concept of multiple RMFs at a node; 
> at least, not multiplexed on model identity. sure the role of 
> an RMF is to coordinate the management of the resources at a node.
> if you have multiple RMFs all allocating from a common 
> resource then something at a higher level would have to 
> coordinate contending requests for them (which seems to be 
> leading towards infinite regress...).
> 
> to put it another way, i would expect the RMF to be 
> identified based on what resources a request was going to 
> draw on. so that might be an outgoing interface, or a queue 
> on an interface (where the queue parameters are 
> semi-statically configured).
> 
> robert h.
> 
> > 
> > We still haven't gotten a concrete bit-level example of how 
> the QOSM 
> > ID

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Mar 2007 14:28:29 +0100

Hi Robert

Sorry, but the previous e-mail went out too fast! :-)

I agree that the (input/outgoing) interface is important, but
 this is an implementation issue.

"A QNE might support more than one end-to-end QOSMs and more 
than one local (intra-domain) QOSMs.
 
Therefore, it will be complex for the QNE, when it receives a QSPEC 
to know to which RMF/QOSM to send the received QSPEC. In particular, 
for the situations that all QOSMs use the same types of QSPEC (private) 
parameters, but use different semantics and values for these QSPEC 
private parameters.
In the solution that you proposed it will mean that each QOSM will have 
to check all QSPEC parameters to find out if the sematics of some of 
them can be understood etc...
And I am not sure if all situations can be covered. Are you?

By including the QSPEC Type and QOSM ID a QNE will know exactly 
how and where (to which RMF/QOSM) to send the received QSPEC.
Thius is a very clean solution that does not introduce any 
additional complexity, just some bits in the common header of the QSPEC
object."

Best regards,
Georgios

---

From: David R Oran <[email-masked]>
Date: Mon, 5 Mar 2007 08:37:44 -0500

> situations that all QOSMs use the same types of QSPEC (private)  
And the upstream node putting in these QOSMids knows better?

---

From: David R Oran <[email-masked]>
Date: Mon, 5 Mar 2007 08:36:28 -0500

On Mar 5, 2007, at 7:21 AM, Roland Bless wrote:

>> simultaneously
I'll note that this is already on the edge of being too complicated,  
but having two degrees of freedom of mapping QSPEC parameters onto  
QoS resources and admission control through multiple QOSMs puts me  
definitively over the edge.

> I don't see a reason to signal the QOSM.
Me neither.

> It's clear that
Rereading this, I wonder if we're not already over the too- 
complicated threshold. QSPEC parameters get registered with IANA.  
QOSMs are documented in RFCs that explain how they use the QSPEC  
parameters to do resource allocation, admission control, and  
scheduling. I'm not sure we even heed QSPEC  id's to make this work...

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Mar 2007 14:53:20 +0100

Hi Dave

Regarding the following comment:

> Therefore, it will be very complex for the QNE, when it receives a 
> QSPEC to know to which RMF/QOSM to send the received QSPEC. In 
> particular, for the situations that all QOSMs use the same types of 
> QSPEC (private) parameters.
>
Dave: And the upstream node putting in these QOSMids knows better?

Georgios: Note that the QNI (for initial QSPEC) or QNI_Ingress (for local
QSPEC) 
 will include the QOSM-ID!

Best regards,
Georgios

> From: David R Oran [mailto:[email-masked]] 
> Sent: maandag 5 maart 2007 14:38
> To: Georgios Karagiannis
> Cc: 'ASH, GERALD R, ATTLABS'; 'Roland Bless'; 'nsis'; 'Martin 
> Stiemerling'
> > Therefore, it will be very complex for the QNE, when it receives a 
> > QSPEC to know to which RMF/QOSM to send the received QSPEC. In 
> > particular, for the situations that all QOSMs use the same types of 
> > QSPEC (private) parameters.
> >
> > By including the QSPEC Type and QOSM ID a QNE will know exactly how 
> > and where (to which RMF/QOSM) to send the received QSPEC.
> >
> >
> >>
> >> constraints are actually met (in case of admission). From an 
> >> interface perspective I don't care about the particular 
> type of QOSM 
> >> that you are running as long as you can correctly decide about the 
> >> admission of my QoS request (i.e. QSPEC).
> >>
> some QSPEC 
> >> types may be specific to particular QOSMs.
> >> For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC B 
> >> locally. QOSM C may be a variant of QOSM A but uses the 
> same QSPEC A. 
> >> It might be the case that QOSM B understands QSPEC A _and_ QSPEC B 
> >> (usually as well as the global E2E QSPEC), so I don't see a good 
> >> reason to signal the QOSM.
> >>

---

From: David R Oran <[email-masked]>
Date: Mon, 5 Mar 2007 09:25:05 -0500

>  will include the QOSM-ID!
That was my point. How does it know? Is there some kind of discovery  
through GIST?

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Mar 2007 15:31:23 +0100

Hi Dave

Consider that the reservation request is started by the QNI. 
The QOSM will then have to include an initial QSPEC with a QOSM-ID 
into the RESERVE. The QOSM-ID should be assigned by IANA, please 
see v.12 of the QSPEC template draft.

Best regards,
Georgios

> Sent: maandag 5 maart 2007 15:25
> To: Georgios Karagiannis
> That was my point. How does it know? Is there some kind of 
> discovery through GIST?
> 
> > Best regards,
> > Georgios
> >
> >
> >
> >
> receives a 
> exactly how

---

From: David R Oran <[email-masked]>
Date: Mon, 5 Mar 2007 09:39:43 -0500

On Mar 5, 2007, at 9:31 AM, Georgios Karagiannis wrote:

> into the RESERVE.
We're still talking past each other. Why should the QNI have to do  
this? It may have no clue what QOSMs are downstream.

One major reason we went for a registry of QSPEC parameters with IANA  
registration of everything and the requirement to write an RFC for a  
QOSM, was to avoid this kind of static binning of things. If you have  
a QOSM, you've documented it, and it uses QPSEC parameters that are  
registered with IANA, that's all you need to figure out what to do.

It's important to note that there's only one set of resources being  
allocated and managed, so at some point your implementation has to  
deal with the fact that if there are multiple QOSMs operating on the  
same resources they have to know about each other. This was the point  
Robert was making earlier in the thread.

> The QOSM-ID should be assigned by IANA, please
This is circular logic. If we don't need it, then we don't have to  
put it in, and hence you don't need an IANA registry.
Cheers, Dave.

---

From: Roland Bless <[email-masked]>
Date: Mon, 05 Mar 2007 16:00:17 +0100

Hi Georgios,

> Why only one end-to-end QSPEC? 

Actually these could be different QSPEC types,
but due to better interoperability it should be
only one QSPEC which is understood by every node
(which is the current QSPEC template). If your
QNE knows how to map the different QSPEC types
to its internal RMF parameters I see no problem.

> than one local (intra-domain) QOSMs.

Hmm, I see conceptually no problem in supporting more than one
end-to-end _QSPEC_, but more than one local intra-domain QOSM?
This sounds like a virtualization of resources...
However, I also see no problem as long as there is a unique
mapping from QSPEC type to QOSM/RMF (which could be set by local
policy).

> received QSPEC. In particular, for the situations that all 

Why complex? It should have a static mapping from QSPEC type to RMF
(if you support different RMFs).

> semantics and values for these QSPEC private parameters.

That sounds weird, but a cleaner approach would be to define
a different QSPEC type for each such case. If I understand you
correctly, you suggest to use the QOSM-ID as (semantic)
demultiplexer for that purpose.

> QSPEC parameters to find out if the sematics of some of them can be

No, you will have a demultiplexer that decides on the QSPEC type
(which wuold be different for different semantic interpretations
of the parameters).

> complexity, just some bits in the common header of the QSPEC object.

I see that the use of a QOSM and the RMF as a matter of local policy.
So usually, I don't want to use the value of the QOSM-ID of my preceding
QNE, but rather decide it locally (I guess that was Dave's point, too).

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Mar 2007 16:19:41 +0100

Hi Roland

Please see in line!

> Sent: maandag 5 maart 2007 16:00
> To: Georgios Karagiannis
> Actually these could be different QSPEC types, but due to 
> better interoperability it should be only one QSPEC which is 
> understood by every node (which is the current QSPEC 
> template). If your QNE knows how to map the different QSPEC 
> types to its internal RMF parameters I see no problem.

Georgios: Please note that any QOSM will have to understand the QSPEC
parameters 
defined in the QSPEC template draft. Thus I agree!

> Hmm, I see conceptually no problem in supporting more than 
> one end-to-end _QSPEC_, but more than one local intra-domain QOSM?
> mapping from QSPEC type to QOSM/RMF (which could be set by 
> local policy).

Georgios: But currently there are only tow QSPEC types defined:
"Initial" and "local"
> 
> > Therefore, it will be complex for the QNE, when it receives 
> a QSPEC to 
> > know to which RMF/QOSM to send the received QSPEC. In 
> particular, for 
> > the situations that all
> 
> Why complex? It should have a static mapping from QSPEC type 
> to RMF (if you support different RMFs).

Georgios: My explanation and questions was:
Therefore, it will be complex for the QNE, when it receives a QSPEC to know
to which RMF/QOSM to send the received QSPEC. In particular, for the
situations that all QOSMs use the same types of QSPEC (private) parameters,
but use different semantics and values for these QSPEC private parameters.
In the solution that you proposed it will mean that each QOSM will have to
check all QSPEC parameters to find out if the sematics of some of them can
be understood etc...
And I am not sure if all situations can be covered. Are you?

> 
> > QOSMs use the same types of QSPEC (private) parameters, but use 
> > different semantics and values for these QSPEC private parameters.
> 
> a different QSPEC type for each such case. If I understand 
> you correctly, you suggest to use the QOSM-ID as (semantic) 

Georgios: Currently only two types of QSPEC types are specified, see above.
I propose to use for demultiplexing both the QSPEC type and QOSM-ID.

> 
> > In the solution that you proposed it will mean that each QOSM will 
> > have to check all QSPEC parameters to find out if the 
> sematics of some 
> > of them can be understood etc...
> 
> No, you will have a demultiplexer that decides on the QSPEC 
> type (which wuold be different for different semantic 
> interpretations of the parameters).

Georgios: Currently only two QSPEC types are defined "initial" and "local"
I propose to use for demultiplexing both the QSPEC type and QOSM-ID.
> additional 
> So usually, I don't want to use the value of the QOSM-ID of 
> my preceding QNE, but rather decide it locally (I guess that 
> was Dave's point, too).

Georgios: But there are situations where you cannot decide that locally, see
above!
Best regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Mon, 05 Mar 2007 17:14:32 +0100

Hi Georgios,

> Georgios: But currently there are only tow QSPEC types defined:

You are right, I've not finished my review of the latest draft
and just checked section 8 (it's not that clear from the
definition in sec. 6.1.).
I thought that it's rather like: RMD-QSPEC, Y1541-QSPEC etc.
(at least that was the intention of my proposal).
However, the current QSPEC template concept is different, i.e.,
you can attach QOSM specific parameters to the QSPEC...
My fault.

Sorry for the confusion.

> I propose to use for demultiplexing both the QSPEC type and QOSM-ID.

If QSPEC type is defined differently, that wouldn't be necessary.

> I propose to use for demultiplexing both the QSPEC type and QOSM-ID.

Maybe I don't understand the exact purpose of the now defined QSPEC type
initial/local. My initial suggestion was replacement of the QOSM-ID
by the QSPEC-ID.

Regards,
 Roland

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Mon, 5 Mar 2007 11:58:39 -0600

Hi Roland,

> you can attach QOSM specific parameters to the QSPEC...
...
> My initial suggestion was replacement of the QOSM-ID
> by the QSPEC-ID.

It wasn't clear to me that your intent was to replace QOSM-ID with QSPEC
Type.  In any case, as per the IANA Consideration specified in Section
8, additional QSPEC Types can be defined, if need be, through Standards
action.  So if an RMD-QSPEC, etc. QSPEC Type needs to be defined, that
should be done in a separate document (note that in previous QSPEC
drafts QOSM-IDs were not specified in the IANA Considerations section).

It is necessary IMO for the specification to clearly describe, with
bit-level examples, how exactly the QSPEC Type parameter (e.g.,
RMD-QSPEC type parameter) is going to be used.  E.g., I get concerned
with comments like "QOSMs use the same types of QSPEC (private)
parameters, but use different semantics and values for these QSPEC
private parameters."  I don't see that the semantics of QSPEC parameters
can/should be QOSM dependent.  At the very least, that sounds
non-interoperable and violating basic architectural principles.

Note that it *not* required for a QNE to support any QOSM.  In the case
that no QOSM is supported, the QNE specifies I-QSPEC and L-QSPEC with
the default values specified in Section 8 of the QSPEC draft.

> If QSPEC type is defined differently, that wouldn't be necessary.

I agree, but don't think the QSPEC type really needs to be redefined,
see the above comments.

Thanks,
Regards,
Jerry

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 6 Mar 2007 09:27:45 +0100

Hi Roland, 

could you explain the difference between your proposal for QSPEC Type and the original QOSM ID?

Thanks. Cornelia 

> -----Ursprüngliche Nachricht-----
> Von: Roland Bless [mailto:[email-masked]] 
> Gesendet: Montag, 5. März 2007 17:15
> An: Georgios Karagiannis
> Betreff: Re: [NSIS] comment on reintroduction of QOSM-ID in 
> qspec draft
> 
> Hi Georgios,
>

---

From: Roland Bless <[email-masked]>
Date: Tue, 06 Mar 2007 11:42:29 +0100

Hi Cornelia,

> could you explain the difference between your proposal for QSPEC Type and the original QOSM ID?

Conceptually only little.
As already written earlier (see quote below) it's mainly a name
correction as I think it makes sense that a QOSM may (but need not)
understand different QSPECs. For example, if my particular QOSM is able
to understand the RMD-QSPEC, the Y.1541-QSPEC etc. it doesn't
necessarily mean that my used QOSM is actually RMD etc.

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 6 Mar 2007 11:52:41 +0100

Hi Roland

What I really liked from the QSPEC type is that a QSPEC object can be
identidied as 
"Initial" or "Local".

Thus my proposal is:
Use 1 bit for the QSPEC type:
1: Local
0: Initial

Reintroduce the QOSM ID, which should be assigned by an IANA action for each
QOSM.
The bit format should be the same as given in v.12 of the QSPEC templated
draft.

Best regards,
Georgios

> Sent: dinsdag 6 maart 2007 11:42
> To: Kappler, Cornelia
> Cc: Georgios Karagiannis; ASH, GERALD R, ATTLABS; nsis; 
> Martin Stiemerling
> Subject: Re: AW: [NSIS] comment on reintroduction of QOSM-ID 
> in qspec draft
> 
> Hi Cornelia,
> 
> Kappler, Cornelia wrote:
> As already written earlier (see quote below) it's mainly a 
> name correction as I think it makes sense that a QOSM may 
> (but need not) understand different QSPECs. For example, if 
> my particular QOSM is able to understand the RMD-QSPEC, the 
> Y.1541-QSPEC etc. it doesn't necessarily mean that my used 
> QOSM is actually RMD etc.
> 
> > My intention was to have an ID for a specific QSPEC type, 
> because the 
> > same QSPEC may be understood by several different QoS-Models.
> > by other QoSMs, too. That's why I thought it may be better 
> to signal a 
> > QSPEC type instead of a QOSM ID.
> 
> 
> Regards,
>  Roland
>

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 7 Mar 2007 21:54:29 +0100

Hi Georgios and Jerry,

I'm trying to understand what the issue is, so please correct me when  
I'm wrong!

I believe that the QOSM ID is not needed as there is only one local  
RMF per QNE. This local RMF can actually support multiple QOSMs but  
this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the  
chance to pass the QSPEC in a single piece to a single RMF.
The mapping between the different initiator QOSM and the local QOSM  
is solely happening within the RMF.

Thanks,

   Martin

>> and local QOS-NSLP messages that are carying local QSPEC of QOSML-2

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Wed, 7 Mar 2007 17:37:08 -0600

Hi Martin, 

> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 3:54 PM
> To: Georgios Karagiannis
> Cc: ASH, GERALD R, ATTLABS; 'nsis'
> I'm trying to understand what the issue is, so please correct 
> me when I'm wrong!
> 

I agree.  

In addition, we have defined the QSPEC Type parameter.  As specified in
Section 8 (IANA Considerations), additional QSPEC Types can be defined,
if need be, through Standards action.  For example, if an RMD-QSPEC Type
needs to be defined, that could be done in a separate document (e.g.,
the RMD-QOSM specification draft).  The specification should clearly
describe, with bit-level examples, how exactly the QSPEC Type parameter
is going to be used. 

Thanks,
Jerry

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 7 Mar 2007 22:19:05 +0100

Hi,

please ignore my last email, I've hit the send button too fast before  
noticing the rest of the thread.

   Martin

Am 07.03.2007 um 21:54 schrieb Martin Stiemerling:

> Hi Georgios and Jerry,
>
> I'm trying to understand what the issue is, so please correct me  
> when I'm wrong!
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 9 Mar 2007 11:02:23 +0100

Hi Martin

A QNE can support more RMFs/QOSMs. 
In this case a QOSM ID is needed otherwise the QNE will not 
know what to do with the received QSPEC, see 
e-mail discussions with Roland.

Best Regards,
Georgios

> Sent: woensdag 7 maart 2007 21:54
> To: Georgios Karagiannis
> Cc: 'ASH, GERALD R, ATTLABS'; 'nsis'
> I believe that the QOSM ID is not needed as there is only one 
> local RMF per QNE. This local RMF can actually support 
> multiple QOSMs but this is opaque to the QoS NSLP. I.e., the 
> QoS NSLP has only the chance to pass the QSPEC in a single 
> piece to a single RMF.
> The mapping between the different initiator QOSM and the 
> local QOSM is solely happening within the RMF.
> 
> Thanks,
> 
>    Martin
> 
> the follwing