Subject: Re: [NSIS] QoS NSLP: Stacking vs. tunneling vs.

From: Roland Bless <[email-masked]>
Date: Mon, 04 Dec 2006 10:50:01 +0100

Hi John,

please see below.

[email-masked] wrote:
> Dave Oran proposed 3 options for supporting domain-local admission
> control operation in NSLP/QSPEC in the following mail:
> 
> _http://www1.ietf.org/mail-archive/web/nsis/current/msg07178.html_
> 
> As stated, these are meant as complete solutions:
> 
> 1. Do complete QSPEC stacking, and deal with the issues around what
> constraints have to be met by the stacked QSPEC, whether the QSPEC lower
> in the "stack" is opacified, and what the rules are for pushing,
> swapping, and popping.
> 
> 2. Allow domain-parameters to be added to a QSPEC on domain entry and
> removed on exit. In this option one has to describe whether anything is
> opacified and which existing QSPEC parameters get "re-interpreted" if any.
> 
> 3. Recurse at the NSLP level, have a separate domain-private NSLP
> session, and that would contain a domain-private set of paramteres
> instead of the end-to-end QSPEC. I'll note that this approach allows
> (but not requires) the two signaling state machines (end-end and edge-
> edge through interior nodes) to be decoupled.
> 
> There seems to be consensus that 3 is mandatory, but 2 is still
> desirable.  Does this mean that 2 would be optional in the QoS NSLP? 

Option 2 is maybe not covering exactly that what I had in mind, so
please also consider my follow on:
http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.html

Option 2 could be also realized by having one QSPEC type
where parameters are added and removed as needed and I guess
that's different from my proposal.

Regards,
 Roland

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 4 Dec 2006 11:01:17 +0100

Hi John and Roland

I agree with Roland's proposal is different than (2)
that encapsulates end-to-end QSPEC into a 
local QSPEC and gives the possibility to the QoS model 
to specify which QSPEC parameters can be ignored.

In the mailing list there was support on using 
the option proposed by Roland instead of 
using option (1) and (2) proposed by Dave.

Best Regards,
Georgios

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: maandag 4 december 2006 10:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [NSIS] QoS NSLP: Stacking vs. tunneling vs.
> 
> Hi John,
> 
> please see below.
> 
> > constraints have to be met by the stacked QSPEC, whether the QSPEC 
> > lower in the "stack" is opacified, and what the rules are 
> for pushing, 
> > swapping, and popping.
> > 
> > removed on exit. In this option one has to describe whether 
> anything 
> > is opacified and which existing QSPEC parameters get 
> "re-interpreted" if any.
> > 
> Option 2 is maybe not covering exactly that what I had in 
> mind, so please also consider my follow on:

---

From: <[email-masked]>
Date: Mon, 4 Dec 2006 22:36:24 +0200

Roland,

Could you summize your proposal, making it easier just to verify
that we can come to consensus on this? It looked like there
was some meandering on the email threads about some parts
of your proposal, so it wasn't clear that we had complete
consensus on your initial proposal.

thanks,
John 

>From: ext Georgios Karagiannis [mailto:[email-masked]] 
>Sent: 04 December, 2006 12:01
>To: 'Roland Bless'; Loughney John (Nokia-NRC/Helsinki)
>Cc: [email-masked]
>Subject: RE: [NSIS] QoS NSLP: Stacking vs. tunneling vs.
>
>Hi John and Roland
>
>I agree with Roland's proposal is different than (2) that 
>encapsulates end-to-end QSPEC into a local QSPEC and gives the 
>possibility to the QoS model to specify which QSPEC parameters 
>can be ignored.
>
>In the mailing list there was support on using the option 
>proposed by Roland instead of using option (1) and (2) 
>proposed by Dave.
>
>Best Regards,
>Georgios
>
>
>> Option 2 could be also realized by having one QSPEC type where 
>> parameters are added and removed as needed and I guess that's 
>> different from my proposal.
>> 
>> Regards,
>>  Roland
>>

---

From: Roland Bless <[email-masked]>
Date: Wed, 06 Dec 2006 09:17:03 +0100

Hi John,

> consensus on your initial proposal.

Ok, I'll try once again.

1. each QSPEC has a type (QSPEC-ID) instead of this QOSM-ID
   because I think that some QSPECs are applicable to more
   than one QOSM (e.g., the e2e QSPEC) and some QOSM may understand
   more than one QSPEC type.

2. Instead of supporting stacking QSPEC objects in QoS-NSLP
   I suggest to have only a "single" QSPEC object in a QoS-NSLP.
   If one wants to carry other QSPECs transparently or simply
   add parameters of local meaning etc. one could
   simply define an "encapsulation" for its own QSPEC type
   like this:
----------------------------------
| QSPEC-Type = RMD-QSPEC         |  Common QSPEC header
+================================+\
|  RMD-specific Parameter 1      | \
+--------------------------------+  \
|             ....               |   local QSPEC parameters
+--------------------------------+  /
|  RMD-specific Parameter n      | /
+--------------------------------+/
| +----------------------------+ |
| | QSPEC-Type = E2E QSPEC     | |
| +============================+ |
| |                            | | Encapsulated "external" QSPEC
| |          ....              | |
| +----------------------------+ |
+--------------------------------+

That's essentially the proposal to remove stacking
while achieving the same functionality with encapsulation.

This simplifies QoS NSLP operation and implementation,
because there are less error cases at the interface from
QoS-NSLP to the RMF and not every QoSM requires its own QSPEC
so stacking would be superfluous for them.

Still unclear?

Regards,
 Roland

---

From: <[email-masked]>
Date: Thu, 7 Dec 2006 10:26:41 +0200

Hi Roland,

This looks reasonable.  Now I just want to make sure this is what the
WG understands and that we can get closure on this.

So, to the WG - are you in agreement with Roland's proposal here?

John 

>From: ext Roland Bless [mailto:[email-masked]] 
>Sent: 06 December, 2006 10:17
>To: Loughney John (Nokia-NRC/Helsinki)
>Cc: [email-masked]; [email-masked]; Ash, Gerald R (Jerry), ALABS
>> Could you summize your proposal, making it easier just to 
>verify that 
>> we can come to consensus on this? It looked like there was some 
>> meandering on the email threads about some parts of your 
>proposal, so 
>> it wasn't clear that we had complete consensus on your initial 
>> proposal.
>
>Ok, I'll try once again.
>
>That's essentially the proposal to remove stacking while 
>achieving the same functionality with encapsulation.
>
>This simplifies QoS NSLP operation and implementation, because 
>there are less error cases at the interface from QoS-NSLP to 
>the RMF and not every QoSM requires its own QSPEC so stacking 
>would be superfluous for them.
>
>Still unclear?
>
>Regards,
> Roland
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 7 Dec 2006 10:05:30 +0100

Hi John

I think that during and after the IETF meeting in San Diego 
many people supported the proposal of Roland.

Best Regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 7 december 2006 9:27
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> This looks reasonable.  Now I just want to make sure this is 
> what the WG understands and that we can get closure on this.
> 
> >This simplifies QoS NSLP operation and implementation, because there 
> >are less error cases at the interface from QoS-NSLP to the 
> RMF and not 
> >every QoSM requires its own QSPEC so stacking would be 
> superfluous for 
> >them.
> >
> >Still unclear?
> >
> >Regards,
> > Roland
> >
>

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 7 Dec 2006 06:17:59 -0600

John,

Yes, I'm in agreement with Roland's proposal and given WG agreement will
update the QSPEC draft accordingly.

Thanks,
Jerry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 07, 2006 3:27 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Ash, Gerald R (Jerry), ALABS
Subject: RE: [NSIS] QoS NSLP: Stacking vs. tunneling vs.

Hi Roland,

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 7 Dec 2006 13:37:00 +0100

Hi John and Jerry

I also agree with this proposal!

Best Regards,
Georgios

> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: donderdag 7 december 2006 13:18
> To: [email-masked]; [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; 
> [email-masked]
> Yes, I'm in agreement with Roland's proposal and given WG 
> agreement will update the QSPEC draft accordingly.
> 
> Thanks,
> Jerry 
>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 7 Dec 2006 08:54:29 -0500

John:

Yes, we agree on Ronald's proposal.

Please also note carefully, we NOT agreeing on anything QOS SLA-specific
things like Y.1451, DSTE, or 3GPP/Y.1451 for QSPEC.

So, anything specific to QOS SLAs (Y.1451, DSTE, or 3GPP/Y.1451) as they
stand in the draft MUST be deleted.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, December 07, 2006 3:27 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] QoS NSLP: Stacking vs. tunneling vs.

Hi Roland,

John

---

From: Bernd Schloer <[email-masked]>
Date: Thu, 7 Dec 2006 17:12:19 +0100 (MET)

Hi,

I agree.

Best Regards,
Bernd

---

From: David R Oran <[email-masked]>
Date: Thu, 7 Dec 2006 11:26:48 -0500

>    simply define an "encapsulation" for its own QSPEC type
This strikes me as really ugly and bug-prone, but it would work and  
give the necessary functionality. In my opinion, it'sbetter to have  
either an explicit stack (so you don't have to figure out whether  
you've escaped from the closed environment and generate errors), or  
multiple QSPEC objects that an RMF can fetch from QNLSP by registered  
type (so you don't have to co-mingle parsers).

I don't want to make a big deal about how kludgy this encoding  
approach is - if this can get WG consensus it isn't a make-or-break  
design issue.

Dave.

---

From: Roland Bless <[email-masked]>
Date: Thu, 07 Dec 2006 18:01:54 +0100

Hi Dave,

please see comments inline.

David R Oran wrote:
> This strikes me as really ugly and bug-prone, but it would work and give
> the necessary functionality. In my opinion, it'sbetter to have either an

It would be interesting to hear why it's ugly and bug-prone in
more technical detail.

> explicit stack (so you don't have to figure out whether you've escaped
> from the closed environment and generate errors), or multiple QSPEC
> objects that an RMF can fetch from QNLSP by registered type (so you
> don't have to co-mingle parsers).

Maybe I don't get your points completely, let's see, so I have a couple
of questions:
If a local QSPEC escapes, the next domain will probably not
understand the QSPEC type and send back an error indicating the
leakage. Is this a problem? Are there better ways to handle this?
What would happen in the case of stacking?
Would the RMF in the next ingress QNE simply search through the stack of
QSPECs until it hits one of the supported QSPEC types or the e2e QSPECs?
Would it ignore (an/or pass on) unknown QSPECs within the stack?
Should QoS-NSLP pass always the whole QSPEC stack up to the RMF
or only registered types?
How can we guarantee that the QSPECs are still "matching" the request if
some of them are ignored and not adapted in intermediate domains?

With this kludgy encapsulation thing, an RMF should know that
there is an e2e QSPEC (or other QSPECs) enclosed and either may ignore
it completely or process it accordingly, so the semantics should be
clear. But maybe I'm missing something or a lot of things completely,
so if you have more rationale, it would be good to hear that.

> I don't want to make a big deal about how kludgy this encoding approach
> is - if this can get WG consensus it isn't a make-or-break design issue.

We shouldn't really go there if this is really kludgy and ugly.
My understanding was that most people in the WG seemed to
dislike QSPEC stacking and thought it would be too complex
(that's why stacking was limited to two QSPECs only). So Georgios
and his colleagues want to have a functionality like this.
But probably there are better ways to do that...

Regards,
 Roland

---

From: Bernd Schloer <[email-masked]>
Date: Thu, 7 Dec 2006 18:55:35 +0100 (MET)

Hi Dave,

I think that Roland's approach makes the QSPEC handling between QoS NSLP
and RMF easier. There's one object to pass to the RMF. This object has inside
in case of encapsulation another object. In C-like pseudocode it would look
like

qspec->header
qspec->parameter_1
qspec->parameter_2
...
qspec->parameter_n
qspec->external->header
qspec->external->parameter_1
...
qspec->external->parameter_n

In qspec->header you can identify the type, the parameters can be accessed via
qspec->parameter_x and if necessary the encapsulated object can be accessed with
qspec->external->xyz.

I think it's a good solution.

Bernd

---

From: David R Oran <[email-masked]>
Date: Mon, 11 Dec 2006 10:52:42 -0500

On Dec 7, 2006, at 12:01 PM, Roland Bless wrote:

> leakage.
Yes, except if the encoding were stacked or not dependent on  
understanding the local QSPEC in order to find and parse the end-to- 
end QSPEC, things would be much more error resilient.

> Is this a problem? Are there better ways to handle this?
Yes. Allow multiple QSPEC objects.

> What would happen in the case of stacking?
you can pop without having to parse.

> QSPECs until it hits one of the supported QSPEC types or the e2e  
If we did stacking, yes. If we simply had parallel QSPECS, it could  
just scan.

> Would it ignore (an/or pass on) unknown QSPECs within the stack?
Sure. Why not.

> or only registered types?
API detail... Doesn't matter to the protocol definition.

> some of them are ignored and not adapted in intermediate domains?
We can't. OTOH, since any intermediary can re-write it's a guarantee  
we can't make anyway (unless we want to go to extremes of having  
signed QSPECS and stuff like that).

> clear.
A fee-for all in how you encapsulate an end-to-end QSPEC in a local  
QSPEC will of course "work". My concerns are aesthetic and  
engineering economy, which is why I'm not making a big deal out of this.

> But maybe I'm missing something or a lot of things completely,
>> approach
> (that's why stacking was limited to two QSPECs only).
We can agree to disagree on that. I find stacking to be simple,  
elegant and allows for recursion as an extensibility mechanism.

Dave.

> So Georgios

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 11 Dec 2006 10:41:55 -0600

> I find stacking to be simple,  

So should we retain stacking instead of encapsulation?  After all, we
allowed stacking of 2 QSPECs for more than 2 years now, so I don't think
there is an urgency to change it now.

It is OK with me to retain stacking instead of using encapsulation.

We need to resolve this issue; it would be good to resolve before the
next update to our QSPEC draft if possible.

Thanks,
Jerry

---

From: David R Oran <[email-masked]>
Date: Mon, 11 Dec 2006 15:18:28 -0500

> next update to our QSPEC draft if possible.
As I mentioned my preference is aesthetic and engineering  
sensibilities. It's not a make-or-break design decision.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 12 Dec 2006 11:03:18 -0500

1. Can anyone provide a specific use-case for any standard QOS models
why they need QOS Model stacking? 

2. Is there any specific case that cannot be solved for any IETF
standard QOS models that Roland and I have already explained using the
e2e-QSPEC?

3. Why do they want to break the e2e-QSPEC model that provides the
standard-based solutions for all standard QOS models and create the door
for "non-interoperability?"

4. If anyone cannot come with a specific use-case as stated above, why
do they make only a philosophical statement like "It's not a
make-or-break design decision?"

More Inline [RRR].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David R Oran
Sent: Monday, December 11, 2006 3:18 PM
To: Ash, Gerald R ((Jerry)), ALABS
Cc: [email-masked]; Roland Bless; [email-masked]
Subject: Re: [NSIS] QoS NSLP: Stacking vs. tunneling vs.

[RRR] It is a make-or-break decision for the NSIS QOS protocol. For
example, QOS SLAs like Y.1451 will demand one kinds of stacking; DSTE
QOS SLAs will like to make other kinds of stacking; 3GPP/Y.1451 QOS SLAs
will need another one; all QOS SLAs using OSP will need a numerous
stacking.

[RRR] If QSPEC is extended for all those "non-standard" and
"proprietary" QOS SLA stacking for which no need as it has been
explained numerous times, it will defeat the main purpose of
"interwoking." 

[RRR] Can you come up with any "use" case that needs stacking?

---

From: David R Oran <[email-masked]>
Date: Tue, 12 Dec 2006 11:59:54 -0500

> why they need QOS Model stacking?
Reservation segmentation ala Packetcable. In this case it might even  
be recursion of a "standard" QSPEC.
I'm not sure what you mean by a "Standard QOS Model" so I can't be  
more specific.

Another use case is a domain that has some clever localized way to  
either compress packet headers, do on-the-fly blocking of packets  
onto lower-layer frames, or have fine-grained control of lower-level  
encryption. Each of these needs some specialized local parameters to  
be passed over and into the domain since those parameters affect  
bandwidth calculations due to the potential for packet expansion or  
contraction in the data plane. Since domains can be recursively  
composed or decomposed, recursion in the expression of QSPECS is  
handy. The most straightforward representation of a recursive data  
structure is a stack.

> standard QOS models that Roland and I have already explained using the
No. As I've said multiple times we are talking about aesthetics and  
engineering sensibilities here. You can always implement a stack with  
a linked list or a heap, or punt the problem as Roland suggests by  
simply letting each local QSPEC roll their own in terms of how the  
encapsulate an "outer" QSPEC.

> for "non-interoperability?"
I don't understand this sentence at all. I'm not interested in  
engaging in another fruitless round of philosophical tit-for-tat  
about what's a standard QOSM and what's not either, so please don't  
bother responding on this point.

> make-or-break design decision?"
That is not philosophical, it's engineering tradeoff.

> will need another one; all QOS SLAs using OSP will need a numerous
Not at all. This is a simple encoding discussion.

> explained numerous times, it will defeat the main purpose of
Who ever said that what was being stacked was standard, nonstandard,  
global, local, or whatever?

> [RRR] Can you come up with any "use" case that needs stacking?
See above.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 12 Dec 2006 12:44:28 -0500

Let us start from the beginning. I appreciate that you have become more
specific, and let us clarify each item for the benefit of the entire
NSIS WG.

The IETF "standard" QOS models are as follows: RSVP, DiffServ, and
IntServ.

QOS SLAs: Y.1451, DSTE, and 3GPP/Y1451 are NOT QOS models; they are QOS
SLAs with specific values of QOS parameters. Similar, all QOS SLAs that
implement DiffServ QOS models with specific values for implementation
any "standard" DiffServ code points will also have the same
value-specific parameters like those of Y.1451/DSTE/3GPP. These are NOT
standards as there can be almost INFINITE numbers of value-specific QOS
parameters for many services. ISPs are there to implement those.

QOS SLAs are "Non-Standards/Proprietary" and are outside scope of the
IETF QSPEC.

Now, let go us inline [RRR] to have specific answers for all of you
explanations.

Best regards,
Radhika

-----Original Message-----
From: David R Oran [mailto:[email-masked]] 
Sent: Tuesday, December 12, 2006 12:00 PM
To: Roy, Radhika R.
Cc: Ash, Gerald R ((Jerry)), ALABS; [email-masked]; Roland
Bless; [email-masked]

[RRR] Please specific which standard of QOS model (RSVP, DiffServ,
IntServ) Packet Cable uses? If packet cable does not use any QOS
standards, let us not bring this "proprietary" QOS models into our
discussions. Let them go to any forum like IMTC or even packet cable
forum can do so once IETF's e2e-QSPEC spec is standardized.

[RRR] Like Ronald, please provide an example with different QOS domains
that use the standard QOS models. We can then discuss this.

[RRR] Our job is to see how e2e-QSPEC is implemented using the "simple"
standard QSPEC template that "interwork" leaving out so-called
"intelligent" domain-specific complexities that create
"non-interoperability."

[RRR] We do not need to solve all those "intelligent QOS schemes" that
create more questions than solving any "meaningful" QOS problems with
one shot as IETF is not going out-of-business soon. It can be two-step
process as stated above.

[RRR] If history is guide for QOS standards, only DIffServ QOS model is
the most successful for scalability and simplicity. All other models are
going to be either obsolete or non-scalable, and are of very limited
use.

[RRR] We do not want to create NSIS QOS QSPEC spec is another "white
elephant" from technical point of view. What is the problem, if we use
all those intelligent QOS schemes after standardization of the e2e-QSPEC
template to see how the things work in implementing the NSIS QOS
protocol first keeping only the e2e-QSPEC "simple?"

[RRR] It is true because to keep it "simple." We not want complexities
and creation of non-interoperability in the name of so-called
intelligent inter-domain QOS support. Moreover, there is no need as no
specific example has been provided using any standard QOS models
(DiffServ, RSVP, IntServ).

[RRR] For example, RSVP, DiffServ, and IntServ QOS models interwork
among themselves. No implementation-specific value-based QOS SLAs
(Y.1451, DSTE, 3GPP/Y.1451, DiffServ-based QOS SLAs, OSP-based QOS SLAs)
will "interwork" among themselves. They are for "non-interoperability."
Is this clear?

[RRR] So, any extensions of QSPEC template for implementation-specific
value-based QOS SLAs (Y.1451, DSTE, 3GPP/Y.1451, DiffServ-based QOS
SLAs, OSP-based QOS SLAs) are out-of-scope in the IETF. Is this clear?

[RRR] If you have specific-examples, please provide to all of us instead
of speaking in general terms. Otherwise, you will be mixing between
"apples" and "oranges." Is this clear?

[RRR] It will be philosophical, if you want to generalize mixing between
"apples" and "oranges" without providing any specific examples of any
QOS models as described above.

See above.