Subject: [NSIS] QSPEC Template Draft Review

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Jan 2007 12:39:35 +0100

Hi all,

as a short summary: The draft now provides QoS parameters (Traffic Model 
Parameters, Constraint Parameters, Traffic Handling Directives, Traffic 
Classifiers) and informative  processing descriptions related to the 
QSPEC usage tied to the QoS NSLP.

Regarding QoS parameters:

The goal of defining a "global" QoS model seems to be gone. Instead, the 
M-flag is now used to indicate whether a particular parameter has to be 
understood.
I was always a bit skeptical with the inclusion of Y.1541 and DSTE 
parameters as mandatory-to-implement in the past (the Y.1541 QoS Class 
parameter is just a "compressed" version of the path latency, path 
jitter, and path packet loss ratio parameter of the constraint 
parameters and the DSTE parameter is useful only for a local QoS model). 
BUT: with the most recent draft version this is not the case anymore 
since a domain can just decide to implement a specific QoS model or a 
small number of QoSMs. Nobody implements the QSPEC as such; instead they 
implement a QoSM that makes use of some QoS parameters and may define a 
few more. With this respect the document, is truly a template for QoS 
parameters. At least that's my reading. Is it true?

With this respect, the abstract and Section 5.4 regarding extensibility 
have to be updated.

Usage of RFC 2119 language is a bit challenging in this document given 
that it means "If a QoSM decides to use a certain parameter then it must 
implement the parameter as mentioned in this document.". Do you need to 
a normative reference since it is just a template of QoS parameters?

Regarding processing description:

I never understood why the processing description is also provided in 
this document. I provided this comment already in the past but obviously 
the authors didn't like it too much. Not a big deal though. In some 
sense it is largely a matter of taste anyway. Instead of reducing the 
processing description it was actually enhanced; I was surprised to find 
a QSPEC encapsulation technique in Section 5.1. I always thought that 
this is a QoS NSLP draft aspect. This is probably a document writing 
style and  a matter of worksplit between the QoS NSLP and the QSPEC 
document authors. A deployable solution requires GIST, the QoS NSLP, the 
QSPEC and a QoSM (and the AAA part) and a  reader might want to read  
all these documents anyway.

Section 5.3 should be informative only; no RFC 2119 language since the 
current text just outlines all possible combinations. Currently, one can 
sometimes find RFC 2119 language in some subsections. The QoSMs provide 
the normative text and may restrict the available combinations. [[Note 
that this might raise interesting problems given that different QoSMs 
implement a different signaling behavior and interworking between 
different QoSMs might be really challenging. For example, what happens 
if a receiver-initiated reservation meets a domain with a QoS model that 
only supports sender-initiated reservations.]]

That's it for now. I will provide more detailed comments later.

Ciao
Hannes

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

---

From: David R Oran <[email-masked]>
Date: Tue, 2 Jan 2007 08:47:25 -0500

On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote:

> Hi all,
>
> as a short summary: The draft now provides QoS parameters (Traffic  
> Model Parameters, Constraint Parameters, Traffic Handling  
> Directives, Traffic Classifiers) and informative  processing  
> descriptions related to the QSPEC usage tied to the QoS NSLP.
>
> The goal of defining a "global" QoS model seems to be gone.  
> Instead, the M-flag is now used to indicate whether a particular  
> parameter has to be understood.
> parameters as mandatory-to-implement in the past (the Y.1541 QoS  
> Class parameter is just a "compressed" version of the path latency,  
> path jitter, and path packet loss ratio parameter of the constraint  
> parameters and the DSTE parameter is useful only for a local QoS  
> model). BUT: with the most recent draft version this is not the  
> case anymore since a domain can just decide to implement a specific  
> QoS model or a small number of QoSMs. Nobody implements the QSPEC  
> as such; instead they implement a QoSM that makes use of some QoS  
> parameters and may define a few more. With this respect the  
> document, is truly a template for QoS parameters. At least that's  
> my reading. Is it true?
>
That's a good summary of what the authors and I were trying to  
achieve with the re-write. We wanted to make QSPECs a way of  
expressing traffic sources (via the TMOD parameters), QoS  
requirements for admission (the constraint parameters), and  
parameters which further describe the handling/interpretation of  
traffic(the handling directives). This seems a much better approach  
than the prior way of bundling things in the QoSMs which introduce  
all sorts of interoperability and cross-domain issues.

> With this respect, the abstract and Section 5.4 regarding  
> extensibility have to be updated.
>
> Usage of RFC 2119 language is a bit challenging in this document  
> given that it means "If a QoSM decides to use a certain parameter  
> then it must implement the parameter as mentioned in this  
> document.". Do you need to a normative reference since it is just a  
> template of QoS parameters?
>
I think so, at least in the sense that the parameters have well  
defined semantics that are not dependent of any local QoSM's whim to  
redefine. If a given QNI says "I want delay variance under 200ms and  
if you can't give it to me I don't want my traffic admitted" then the  
QoSM can't just ignore that or decide that it means something else.  
For example if an RMF in one of the nodes allows an EF queue for  
other traffic with a maximum depth more than 200ms then there's no  
way it can admit the traffic needing a delay variance under 200ms.

> I never understood why the processing description is also provided  
> in this document. I provided this comment already in the past but  
> obviously the authors didn't like it too much. Not a big deal  
> though. In some sense it is largely a matter of taste anyway.  
> Instead of reducing the processing description it was actually  
> enhanced; I was surprised to find a QSPEC encapsulation technique  
> in Section 5.1. I always thought that this is a QoS NSLP draft aspect.
Well, this was the subject of a spirited debate among some of the WG  
participants. I didn't particularly like the way it turned out, but  
there seems to be rough consensus that QSPEC encapsulation should be  
part of other QSPEC itself.

> This is probably a document writing style and  a matter of  
> worksplit between the QoS NSLP and the QSPEC document authors. A  
> deployable solution requires GIST, the QoS NSLP, the QSPEC and a  
> QoSM (and the AAA part) and a  reader might want to read  all these  
> documents anyway.
>
> Section 5.3 should be informative only; no RFC 2119 language since  
> the current text just outlines all possible combinations.  
> Currently, one can sometimes find RFC 2119 language in some  
> subsections. The QoSMs provide the normative text and may restrict  
> the available combinations. [[Note that this might raise  
> interesting problems given that different QoSMs implement a  
> different signaling behavior and interworking between different  
> QoSMs might be really challenging.
This was one of the reasons I proposed restricting the variability  
among QOSMs to be in the RMF only and not to allow different  
signaling semantics. I lost that one.

> For example, what happens if a receiver-initiated reservation meets  
> a domain with a QoS model that only supports sender-initiated  
> reservations.]]
>
In order to make this work I think you have to have recursive  
signaling at the edge of the domain.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 03 Jan 2007 12:16:36 +0100

Hi David,

David R Oran wrote:
>> Model Parameters, Constraint Parameters, Traffic Handling Directives, 
>> Traffic Classifiers) and informative  processing descriptions related 
>> to the QSPEC usage tied to the QoS NSLP.
>>
>> The goal of defining a "global" QoS model seems to be gone. Instead, 
>> the M-flag is now used to indicate whether a particular parameter has 
>> to be understood.
>> model). BUT: with the most recent draft version this is not the case 
>> anymore since a domain can just decide to implement a specific QoS 
>> model or a small number of QoSMs. Nobody implements the QSPEC as 
>> such; instead they implement a QoSM that makes use of some QoS 
>> parameters and may define a few more. With this respect the document, 
>> is truly a template for QoS parameters. At least that's my reading. 
>> Is it true?
>>
> That's a good summary of what the authors and I were trying to achieve 
> with the re-write. We wanted to make QSPECs a way of expressing 
> traffic sources (via the TMOD parameters), QoS requirements for 
> admission (the constraint parameters), and parameters which further 
> describe the handling/interpretation of traffic(the handling 
> directives). This seems a much better approach than the prior way of 
> bundling things in the QoSMs which introduce all sorts of 
> interoperability and cross-domain issues.

I agree that it is better to separate topics to improve readability.

>> then it must implement the parameter as mentioned in this document.". 
>> Do you need to a normative reference since it is just a template of 
>> QoS parameters?
>>
> For example if an RMF in one of the nodes allows an EF queue for other 
> traffic with a maximum depth more than 200ms then there's no way it 
> can admit the traffic needing a delay variance under 200ms.

I see it differently. The current collection of parameters are available 
to a QoSM designer. They can decide whether to use it or define 
something new. Every QoSM is allowed to define whatever they want. If I 
want to define a IEEE 802.16e QoSM then nobody should prevent me from 
doing so. I would want to use the parameters that are available in the 
IEEE spec. For example, when I tried to map the existing QSPEC 
parameters to the existing IEEE 802.16e parameters then I noticed that 
they are similar but not exactly the same. Hence, even if they look 
similar I would like to define my own based on .16e rather than reusing 
the QSPEC parameters.

The idea of a template is to offer a set of parameters that might be 
used when building QoSMs. With a specific QoSM some of these QSPEC 
parameters are hopefully implemented.

The question with the parameter selection is therefore: Are these useful 
parameters that might be reused by a number of QoSMs?

>> this document. I provided this comment already in the past but 
>> obviously the authors didn't like it too much. Not a big deal though. 
>> In some sense it is largely a matter of taste anyway. Instead of 
>> reducing the processing description it was actually enhanced; I was 
>> surprised to find a QSPEC encapsulation technique in Section 5.1. I 
>> always thought that this is a QoS NSLP draft aspect.

I must have missed this discussion. If people like it that way then it 
should be fine.

>
>> This is probably a document writing style and  a matter of worksplit 
>> between the QoS NSLP and the QSPEC document authors. A deployable 
>> solution requires GIST, the QoS NSLP, the QSPEC and a QoSM (and the 
>> AAA part) and a  reader might want to read  all these documents anyway.
>>
>> the current text just outlines all possible combinations. Currently, 
>> one can sometimes find RFC 2119 language in some subsections. The 
>> QoSMs provide the normative text and may restrict the available 
>> combinations. [[Note that this might raise interesting problems given 
>> that different QoSMs implement a different signaling behavior and 
>> interworking between different QoSMs might be really challenging.
> among QOSMs to be in the RMF only and not to allow different signaling 
> semantics. I lost that one.

Another alternative is that the QSPEC document demands that QoSM 
documents define all possible signaling behaviors. Then it would be fine 
as well. It would make the QoSMs more complicated. I, btw, was never in 
favor of receiver-initiated signaling behavior since the authorization 
story is really mood.

Do you agree with me that RFC 2119 language shouldn't be used in Section 
5.3?

>
>> For example, what happens if a receiver-initiated reservation meets a 
>> domain with a QoS model that only supports sender-initiated 
>> reservations.]]
>>
Correct.

As an example, in RMD these different cases got considered.

If you only assume that sender-initiated reservations exist then 
documents are simpler since they obviously don't need to consider all 
the different cases.
We noticed this problem already with the mobility document where the 
receiver-initiated reservations are just painful.

Ciao
Hannes

---

From: David R Oran <[email-masked]>
Date: Wed, 3 Jan 2007 08:51:54 -0500

>> On Jan 2, 2007, at 6:39 AM, Hannes Tschofenig wrote:
[snip]
>>> document.". Do you need to a normative reference since it is just  
>>> a template of QoS parameters?
>>>
>> defined semantics that are not dependent of any local QoSM's whim  
>> to redefine. If a given QNI says "I want delay variance under  
>> 200ms and if you can't give it to me I don't want my traffic  
>> admitted" then the QoSM can't just ignore that or decide that it  
>> means something else. For example if an RMF in one of the nodes  
>> allows an EF queue for other traffic with a maximum depth more  
>> than 200ms then there's no way it can admit the traffic needing a  
>> delay variance under 200ms.
>
> I see it differently. The current collection of parameters are  
> available to a QoSM designer. They can decide whether to use it or  
> define something new. Every QoSM is allowed to define whatever they  
> want. If I want to define a IEEE 802.16e QoSM then nobody should  
> prevent me from doing so. I would want to use the parameters that  
> are available in the IEEE spec. For example, when I tried to map  
> the existing QSPEC parameters to the existing IEEE 802.16e  
> parameters then I noticed that they are similar but not exactly the  
> same. Hence, even if they look similar I would like to define my  
> own based on .16e rather than reusing the QSPEC parameters.
>
And herein lies the core of the issue that has bedeviled the working  
group lately (and perhaps since inception, I don't know since my  
participation has been sporadic). I see the purpose of NSIS to define  
a signaling scheme which works end-to-end on the Internet, rather  
than just an architecture and template for defining a set of non- 
interoperable custom, per-network QoS signaling and description  
schemes. To do this there have to be a core set of QoS parameters  
which are universally understood from which you can build the vast  
majority of QoS schemes. Let's face it, the number of feasible data  
plane queueing/scheduling/policing/shaping algorithms is in fact not  
that large. I think it has yet to be demonstrated that the network- 
specific QoS parameter cannot in all but some corner cases be  
represented using the parameters we have come up with. Most of the  
argument has been based on RMFs that wish to be "simpler" than the  
general case in which the exact constraints and traffic model  
parameters of the source are enforced. This is fine, but it does NOT  
mean that we need a free-for-all in terms of parameter space. It is  
in fact why we restructured the Qspec parameters so that the user  
could be explicit and control what is advisory and what is mandatory  
for admission.

Even more important, we don't need a free-for-all in the operation of  
QoS NSLP. The idea that the QoSM can change the signaling state  
machines for the NSLP is quite scary to me, which is why I suggested  
the language which said a QOSM isn't permitted to redefine the way  
QOS NSLP works.

It's pretty clear that a number of people on the WG disagree with  
this position. That's fine - I said I'd shut up if the WG consensus  
went a different way. However, I do detect the weight of opinion  
being closer to what I wrote above. I'll leave it to the WG chair to  
assess this.

> The idea of a template is to offer a set of parameters that might  
> be used when building QoSMs. With a specific QoSM some of these  
> QSPEC parameters are hopefully implemented.
>
If the QSPEC specification is viewed as just a template/base schema,  
then I think we will have failed pretty miserably. We will have the  
illusion of interoperability and not real interoperability.

> The question with the parameter selection is therefore: Are these  
> useful parameters that might be reused by a number of QoSMs?
>
I'd turn it around and say "given that end-to-end QoS  
interoperability is a main goal of NSIS, does the particular QoSM  
achieve this well enough to admit the traffic as requested by the  
QNI". If the QoSM can't do what the user asked then it's the job of  
the QSPEC semantics and the QOS NSLP signaling machinery to not admit  
the traffic, and tell the user why. It's up to the user/QNI to  
formulate QoS requests that are adequate to the needs of the  
application but which have high probability of being admitted under  
conditions where there are adequate resources. QoS NSLP and Qspecs  
(as we have them in the current drafts) give us the tools to  
accomplish this. If we treat the Qspec parameters just as "useful  
suggestions" I think we will have pretty definitely sacrificed this  
goal for the Internet, which is what NSIS exists for.

>>> I never understood why the processing description is also  
>>> provided in this document. I provided this comment already in the  
>>> past but obviously the authors didn't like it too much. Not a big  
>>> deal though. In some sense it is largely a matter of taste  
>>> anyway. Instead of reducing the processing description it was  
>>> actually enhanced; I was surprised to find a QSPEC encapsulation  
>>> technique in Section 5.1. I always thought that this is a QoS  
>>> NSLP draft aspect.
>> Well, this was the subject of a spirited debate among some of the  
>> WG participants. I didn't particularly like the way it turned out,  
>> but there seems to be rough consensus that QSPEC encapsulation  
>> should be part of other QSPEC itself.
>
> I must have missed this discussion. If people like it that way then  
> it should be fine.
>
>>
>>> QoSM (and the AAA part) and a  reader might want to read  all  
>>> these documents anyway.
>>>
>>> Section 5.3 should be informative only; no RFC 2119 language  
>>> since the current text just outlines all possible combinations.  
>>> subsections. The QoSMs provide the normative text and may  
>>> restrict the available combinations. [[Note that this might raise  
> documents define all possible signaling behaviors. Then it would be  
> fine as well. It would make the QoSMs more complicated. I, btw, was  
> never in favor of receiver-initiated signaling behavior since the  
> authorization story is really mood.
>
>
> Do you agree with me that RFC 2119 language shouldn't be used in  
> Section 5.3?
>
I see no problem with the (quite limited) use of RFC2119 language in  
the places in section 5.3 where it appears. It seems quite  
appropriate to me,.

>>
>>> For example, what happens if a receiver-initiated reservation  
>>> meets a domain with a QoS model that only supports sender- 
>>> initiated reservations.]]
>>>
> documents are simpler since they obviously don't need to consider  
> all the different cases.
> We noticed this problem already with the mobility document where  
> the receiver-initiated reservations are just painful.
>
But this is up to the applications which is more useful/natural, no?  
If you are saying that receiver-initiated is harder to achieve under  
some circumstances, then sure. Applications should be cognizant of  
that and use receiver-initiated only when they can't conveniently use  
sender-initiated. Conversely, some applications (e.g. multicast and  
multi-unicast) can get all tied up in knots with sender-initiated  
reservations. But to say that interoperability fails because some  
QoSM decides receiver-initiated reservations are a pain and redefines  
QOS NSLP to eliminate them over its domain strikes me as a very poor  
tradeoff.

Cheers, Dave.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 3 Jan 2007 15:10:17 +0100

Hi Dave

 > It's pretty clear that a number of people on the WG disagree 
> with this position. That's fine - I said I'd shut up if the 
> WG consensus went a different way. However, I do detect the 
> weight of opinion being closer to what I wrote above. I'll 
> leave it to the WG chair to assess this.

It is obvious that you try very hard to change certain QOSM concepts 
that have been decided 4 years ago by the NSIS WG. 
Reading the comments of Hannes I can see that also 
Hannes disagrees with you!

Best Regards,
Georgios

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]] 
> Sent: woensdag 3 januari 2007 14:52
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [NSIS] QSPEC Template Draft Review
> 
> 
> > prevent me from doing so. I would want to use the 
> parameters that are 
> > available in the IEEE spec. For example, when I tried to map the 
> > existing QSPEC parameters to the existing IEEE 802.16e 
> parameters then 
> > I noticed that they are similar but not exactly the same. 
> Hence, even 
> > if they look similar I would like to define my own based on .16e 
> > rather than reusing the QSPEC parameters.
> >
> And herein lies the core of the issue that has bedeviled the 
> working group lately (and perhaps since inception, I don't 
> know since my participation has been sporadic). I see the 
> purpose of NSIS to define a signaling scheme which works 
> end-to-end on the Internet, rather than just an architecture 
> and template for defining a set of non- interoperable custom, 
> per-network QoS signaling and description schemes. To do this 
> there have to be a core set of QoS parameters which are 
> universally understood from which you can build the vast 
> majority of QoS schemes. Let's face it, the number of 
> feasible data plane queueing/scheduling/policing/shaping 
> algorithms is in fact not that large. I think it has yet to 
> be demonstrated that the network- specific QoS parameter 
> cannot in all but some corner cases be represented using the 
> parameters we have come up with. Most of the argument has 
> been based on RMFs that wish to be "simpler" than the general 
> case in which the exact constraints and traffic model 
> parameters of the source are enforced. This is fine, but it 
> does NOT mean that we need a free-for-all in terms of 
> parameter space. It is in fact why we restructured the Qspec 
> parameters so that the user could be explicit and control 
> what is advisory and what is mandatory for admission.
> 
> Even more important, we don't need a free-for-all in the 
> operation of QoS NSLP. The idea that the QoSM can change the 
> signaling state machines for the NSLP is quite scary to me, 
> which is why I suggested the language which said a QOSM isn't 
> permitted to redefine the way QOS NSLP works.
> 
> It's pretty clear that a number of people on the WG disagree 
> with this position. That's fine - I said I'd shut up if the 
> WG consensus went a different way. However, I do detect the 
> weight of opinion being closer to what I wrote above. I'll 
> leave it to the WG chair to assess this.
> 
> If the QSPEC specification is viewed as just a template/base 
> schema, then I think we will have failed pretty miserably. We 
> will have the illusion of interoperability and not real 
> interoperability.
> 
> interoperability is a main goal of NSIS, does the particular 
> QoSM achieve this well enough to admit the traffic as 
> requested by the QNI". If the QoSM can't do what the user 
> asked then it's the job of the QSPEC semantics and the QOS 
> NSLP signaling machinery to not admit the traffic, and tell 
> the user why. It's up to the user/QNI to formulate QoS 
> requests that are adequate to the needs of the application 
> but which have high probability of being admitted under 
> conditions where there are adequate resources. QoS NSLP and 
> Qspecs (as we have them in the current drafts) give us the 
> tools to accomplish this. If we treat the Qspec parameters 
> just as "useful suggestions" I think we will have pretty 
> definitely sacrificed this goal for the Internet, which is 
> what NSIS exists for.
> 
> >>
> provided 
> >>> enhanced; I was surprised to find a QSPEC encapsulation 
> technique in 
> >>> Section 5.1. I always thought that this is a QoS NSLP 
> draft aspect.
> restrict 
> interesting 
> >>> problems given that different QoSMs implement a different 
> signaling 
> >>> behavior and interworking between different QoSMs might be really 
> >>> challenging.
> I see no problem with the (quite limited) use of RFC2119 
> language in the places in section 5.3 where it appears. It 
> seems quite appropriate to me,.
> 
> >>
> >>> a domain with a QoS model that only supports sender- initiated 
> >>> reservations.]]
> >>>
> If you are saying that receiver-initiated is harder to 
> achieve under some circumstances, then sure. Applications 
> should be cognizant of that and use receiver-initiated only 
> when they can't conveniently use sender-initiated. 
> Conversely, some applications (e.g. multicast and
> multi-unicast) can get all tied up in knots with 
> sender-initiated reservations. But to say that 
> interoperability fails because some QoSM decides 
> receiver-initiated reservations are a pain and redefines QOS 
> NSLP to eliminate them over its domain strikes me as a very 
> poor tradeoff.
> 
> Cheers, Dave.
> 
> >
> >>

---

From: David R Oran <[email-masked]>
Date: Wed, 3 Jan 2007 09:28:27 -0500

> Hannes disagrees with you!
If those were in fact "decisions" and if their implications were  
understood then you are correct in characterizing my position as a  
change from prior WG direction. In my defense I'll say that this  
change (or proposal for change) came up as an attempt to break a kind  
of deadlock over the technical content of the qspec specification.

If the conditions that led to that no longer exist, and the WG is  
happy to go back to treating qspecs as templates and QoSMs as being  
the first-class architectural elements then, if the WG chair agrees  
that's the consensus, I'll shut up.

It might be worth asking the transport area directors their opinions  
on this though, since it is in no one's interest to just postpone a  
set of issues that the IESG would wind up raising during the approval  
cycle.

Best, Dave.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 03 Jan 2007 22:21:47 +0100

Hi Dave,

thanks for your quick response.

David R Oran wrote:
>>> if you can't give it to me I don't want my traffic admitted" then 
>>> the QoSM can't just ignore that or decide that it means something 
>>> else. For example if an RMF in one of the nodes allows an EF queue 
>>> for other traffic with a maximum depth more than 200ms then there's 
>>> no way it can admit the traffic needing a delay variance under 200ms.
>>
>> prevent me from doing so. I would want to use the parameters that are 
>> existing QSPEC parameters to the existing IEEE 802.16e parameters 
>> then I noticed that they are similar but not exactly the same. Hence, 
>> even if they look similar I would like to define my own based on .16e 
> a signaling scheme which works end-to-end on the Internet, rather than 
> just an architecture and template for defining a set of 
> non-interoperable custom, per-network QoS signaling and description 
> that large.
> I think it has yet to be demonstrated that the network-specific QoS 
> parameter cannot in all but some corner cases be represented using the 
> parameters we have come up with. Most of the argument has been based 
> on RMFs that wish to be "simpler" than the general case in which the 
> exact constraints and traffic model parameters of the source are 
> enforced. This is fine, but it does NOT mean that we need a 
> free-for-all in terms of parameter space. It is in fact why we 
> restructured the Qspec parameters so that the user could be explicit 
> and control what is advisory and what is mandatory for admission.
>
> the language which said a QOSM isn't permitted to redefine the way QOS 
> NSLP works.
>
> It's pretty clear that a number of people on the WG disagree with this 
> position. That's fine - I said I'd shut up if the WG consensus went a 
> different way. However, I do detect the weight of opinion being closer 
> to what I wrote above. I'll leave it to the WG chair to assess this.

There are a few aspects that need to be discussed here.

I read the QSPEC draft many, many times already (and different 
versions). Whenever I read through the abstract and the introduction I 
had the impression that I understood what the rest of the document is 
going to contain. I was always wrong. This time I was wrong as well.

It shouldn't be too difficult to tell the reader what the document wants 
to accomplish. If I don't understand it then how should someone else 
(slightly ignoring the fact that everyone else might be smarter)?

Let us separate the signaling from the QoS parameter story since they 
are largely a different subject. Let us try to understand what 
interoperability means.

* Signaling

Different QoSMs can nicely interwork if
a) the QoS NSLP or the QSPEC document mandates a single signaling mode
b) all QoSMs "support" all signaling modes.
By support I mean that they describe what needs to be done in the 
different cases. Returning a failure might also be a possible option.

While all possible signaling modes are described in the QSPEC document I 
couldn't see a mandate for a QoSM document to also describe what todo 
for all the signaling modes.

[[ I call the signaling exchanges and respective message processing 
rules in this context "signaling modes" lacking a better term.]]

* QoS Parameters

 From an interoperability point of view it would be ideal to have a 
single QoSM that is understood by everyone. I got the impression that 
this was the initial goal of the QSPEC document. Having a core set of 
parameters that are understood by everyone and a few optional parameters 
was an interesting idea, I thought. [[ I was never really 100 % 
convinced that it can actually work but that's another story. I 
personally was just unhappy about the choice of mandatory parameters. ]]

Another alternative is to define mappings from one QoSM to another 
one.This is done today already but there are no procedures and documents 
in the NSIS working group for defining these mappings. With this 
approach every QoSM can essentially define whatever they want if a 
reasonable mapping exists.

Having a mapping is obviously better than just looking at 
mandatory-to-understand parameters (and ignoring the optional parameters).

 From your description it seems that the QSPEC contains a number of 
parameters that are supposed to be complete and MUST be used by future 
QoSMs. To avoid interoperability problems QoSMs ideally must never not 
introduce parameters. Since some of QSPEC authors are also QoSM authors 
they ensured that their QoSM is nicely supported. To allow the 
end-to-end story to work it is necessary to consider today's access 
networks and the QoS parameters that are being used there. Is someone 
ever wants to use a path-coupled signaling solution then two approaches 
are possible
a) the end host already uses a QoS signaling protocol like RSVP or NSIS
b) the end host uses a link layer protocol (with QoS extensions) towards 
the access network and the network triggers the NSIS signaling exchange
[A combination of the two is also possible.]

In any case I guess you have to deal with the QoS parameters of the 
specific link layer. I wonder whether someone has looked at these issues 
already and whether the QSPEC QoS parameter and local QoSM model 
supports this extensibility.

As an example, the Traffic Priority as defined in IEEE802.16e has 8 
priority levels. What would I do? This parameter does not correspond to 
anything in the QSPEC document at the moment.

The typical question I have is: I want to implement QoSM X. What do I 
have to implement from the QSPEC draft?

[  A minor technical issue: Are there problems (in the IETF document 
processing) if  normative references point to documents that are 
non-IETF documents? ]

I am not sure I understood your comment regarding
"
The idea that the QoSM can change the signaling state machines for the 
NSLP is quite scary to me, which is why I suggested the language which 
said a QOSM isn't permitted to redefine the way QOS NSLP works.
"

> illusion of interoperability and not real interoperability.

This is what I read from the abstract and the introduction. Maybe it 
would be appropriate to delete the term "template" from the document.

> I'd turn it around and say "given that end-to-end QoS interoperability 
> is a main goal of NSIS, does the particular QoSM achieve this well 
> enough to admit the traffic as requested by the QNI". If the QoSM 
> can't do what the user asked then it's the job of the QSPEC semantics 
> and the QOS NSLP signaling machinery to not admit the traffic, and 
> tell the user why. It's up to the user/QNI to formulate QoS requests 
> that are adequate to the needs of the application but which have high 
> probability of being admitted under conditions where there are 
> adequate resources. QoS NSLP and Qspecs (as we have them in the 
> current drafts) give us the tools to accomplish this. If we treat the 
> Qspec parameters just as "useful suggestions" I think we will have 
> pretty definitely sacrificed this goal for the Internet, which is what 
> NSIS exists for.

This sounds like a very nice. When it comes to the details things get a 
bit more difficult.

> the places in section 5.3 where it appears. It seems quite appropriate 
> to me,.
>
I need to read through each paragraph to determine what the implications 
are.

> reservations. But to say that interoperability fails because some QoSM 
> decides receiver-initiated reservations are a pain and redefines QOS 
> NSLP to eliminate them over its domain strikes me as a very poor 
> tradeoff.
I agree with your statement about multicast QoS reservations. I wonder 
whether someone wants to use path-coupled QoS signaling for multicast 
communication.

Ciao
Hannes

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 09:48:33 +0100

Hi Hannes

>> By support I mean that they describe what needs to be done in the
different cases. 
>> Returning a failure might also be a possible option.

>> While all possible signaling modes are described in the QSPEC document 
>> I couldn't see a mandate for a QoSM document to also describe what todo

>> rules in this context "signaling modes" lacking a better term.]]

Regarding signaling the NSIS WG introduced the concept of QOSM to be able 
>> By support I mean that they describe what needs to be done in the
different cases. 
>> Returning a failure might also be a possible option.

Best Regards,
Georgios

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: woensdag 3 januari 2007 22:22
> To: David R Oran
> Cc: [email-masked]
> been based 
> operation of 
> I read the QSPEC draft many, many times already (and 
> different versions). Whenever I read through the abstract and 
> the introduction I had the impression that I understood what 
> the rest of the document is going to contain. I was always 
> wrong. This time I was wrong as well.
> 
> It shouldn't be too difficult to tell the reader what the 
> document wants to accomplish. If I don't understand it then 
> how should someone else (slightly ignoring the fact that 
> everyone else might be smarter)?
> 
> Let us separate the signaling from the QoS parameter story 
> since they are largely a different subject. Let us try to 
> understand what interoperability means.
> 
> * Signaling
> 
> By support I mean that they describe what needs to be done in 
> the different cases. Returning a failure might also be a 
> possible option.
> 
> While all possible signaling modes are described in the QSPEC 
> document I couldn't see a mandate for a QoSM document to also 
> describe what todo for all the signaling modes.
> 
> [[ I call the signaling exchanges and respective message 
> processing rules in this context "signaling modes" lacking a 
> better term.]]
> 
> * QoS Parameters
> 
>  From an interoperability point of view it would be ideal to 
> have a single QoSM that is understood by everyone. I got the 
> impression that this was the initial goal of the QSPEC 
> document. Having a core set of parameters that are understood 
> by everyone and a few optional parameters was an interesting 
> idea, I thought. [[ I was never really 100 % convinced that 
> it can actually work but that's another story. I personally 
> was just unhappy about the choice of mandatory parameters. ]]
> 
> Another alternative is to define mappings from one QoSM to 
> another one.This is done today already but there are no 
> procedures and documents in the NSIS working group for 
> defining these mappings. With this approach every QoSM can 
> essentially define whatever they want if a reasonable mapping exists.
> 
>  From your description it seems that the QSPEC contains a 
> number of parameters that are supposed to be complete and 
> MUST be used by future QoSMs. To avoid interoperability 
> problems QoSMs ideally must never not introduce parameters. 
> Since some of QSPEC authors are also QoSM authors they 
> ensured that their QoSM is nicely supported. To allow the 
> end-to-end story to work it is necessary to consider today's 
> access networks and the QoS parameters that are being used 
> there. Is someone ever wants to use a path-coupled signaling 
> solution then two approaches are possible
> b) the end host uses a link layer protocol (with QoS 
> extensions) towards the access network and the network 
> triggers the NSIS signaling exchange [A combination of the 
> two is also possible.]
> 
> In any case I guess you have to deal with the QoS parameters 
> of the specific link layer. I wonder whether someone has 
> looked at these issues already and whether the QSPEC QoS 
> parameter and local QoSM model supports this extensibility.
> 
> As an example, the Traffic Priority as defined in IEEE802.16e 
> has 8 priority levels. What would I do? This parameter does 
> not correspond to anything in the QSPEC document at the moment.
> 
> The typical question I have is: I want to implement QoSM X. 
> What do I have to implement from the QSPEC draft?
> 
> processing) if  normative references point to documents that 
> are non-IETF documents? ]
> 
> I am not sure I understood your comment regarding "
> The idea that the QoSM can change the signaling state 
> machines for the NSLP is quite scary to me, which is why I 
> suggested the language which said a QOSM isn't permitted to 
> redefine the way QOS NSLP works.
> "
> 
> >
> interoperability 
> technique 
> language in 
> appropriate 
> achieve under

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 04 Jan 2007 12:58:07 +0100

Hi Georgios,

if this is the case then the following text needs to be changed:

 A QOSM specification MUST include the following:

   - role of QNEs, e.g., location, frequency, statefulness, etc.
   - QSPEC definition including QSPEC parameters
[hannes] Replace the following statement with:
"
   - QSPEC procedures applicable to this QOSM
"
this one:
"
   - QSPEC signaling description for all signaling exchanges.
     The signaling exchanges are listed in Section 5.3.
"

   - QNE processing rules describing how QSPEC information is treated
     and interpreted in the RMF, e.g.,
     admission control, scheduling, policy control, QoS parameter
     accumulation (e.g., delay).
   - at least one bit-level QSPEC example
   - QSPEC parameter behavior for new QSPEC parameters the QOSM
     specification defines
   - define what happens in case of preemption if the default QNI
     behavior (tear down preempted reservation) is not followed (see
     Section 5.3.5)

Ciao
Hannes

Georgios Karagiannis wrote:
>>>>>> given that it means "If a QoSM decides to use a certain 
>>>>>>             
>> parameter 
>>     
>>>>>> document.". Do you need to a normative reference since 
>>>>>>             
>> it is just a 
>>     
>>>>> defined semantics that are not dependent of any local 
>>>>>           
>> QoSM's whim to 
>>     
>>>>> redefine. If a given QNI says "I want delay variance 
>>>>>           
>> under 200ms and 
>>     
>>>>> else. For example if an RMF in one of the nodes allows an 
>>>>>           
>> EF queue 
>>     
>>>>> for other traffic with a maximum depth more than 200ms 
>>>>>           
>> then there's 
>>     
>>>>> no way it can admit the traffic needing a delay variance 
>>>>>           
>> under 200ms.
>>     
>>>> define something new. Every QoSM is allowed to define 
>>>>         
>> whatever they 
>>     
>>>> then I noticed that they are similar but not exactly the 
>>>>         
>> same. Hence, 
>>     
>>>> even if they look similar I would like to define my own 
>>>>         
>> based on .16e 
>>     
>>> And herein lies the core of the issue that has bedeviled 
>>>       
>> the working 
>>     
>>> participation has been sporadic). I see the purpose of NSIS 
>>>       
>> to define 
>>     
>>> a signaling scheme which works end-to-end on the Internet, 
>>>       
>> rather than 
>>     
>>> plane queueing/scheduling/policing/shaping algorithms is in 
>>>       
>> fact not 
>>     
>>> that large.
>>> parameter cannot in all but some corner cases be 
>>>       
>> represented using the 
>>     
>>> on RMFs that wish to be "simpler" than the general case in 
>>>       
>> which the 
>>     
>>> restructured the Qspec parameters so that the user could be 
>>>       
>> explicit 
>>     
>> suggested 
>>> the language which said a QOSM isn't permitted to redefine 
>>>       
>> the way QOS 
>>     
>>> NSLP works.
>>>
>>> It's pretty clear that a number of people on the WG 
>>>       
>> disagree with this 
>>     
>>> position. That's fine - I said I'd shut up if the WG 
>>>       
>> consensus went a 
>>     
>>> different way. However, I do detect the weight of opinion 
>>>       
>> being closer 
>>     
>>>> The idea of a template is to offer a set of parameters 
>>>>         
>> that might be 
>>     
>>> If the QSPEC specification is viewed as just a 
>>>       
>> template/base schema, 
>>     
>>> can't do what the user asked then it's the job of the QSPEC 
>>>       
>> semantics 
>>     
>>> tell the user why. It's up to the user/QNI to formulate QoS 
>>>       
>> requests 
>>     
>>> that are adequate to the needs of the application but which 
>>>       
>> have high 
>>     
>>> current drafts) give us the tools to accomplish this. If we 
>>>       
>> treat the 
>>     
>>> pretty definitely sacrificed this goal for the Internet, 
>>>       
>> which is what 
>>     
>>> NSIS exists for.
>>>       
>>>>>> I never understood why the processing description is 
>>>>>>             
>> also provided 
>>     
>>>>>> in this document. I provided this comment already in the 
>>>>>>             
>> past but 
>>     
>>>>>> in Section 5.1. I always thought that this is a QoS NSLP 
>>>>>>             
>> draft aspect.
>>     
>>>>> Well, this was the subject of a spirited debate among 
>>>>>           
>> some of the WG 
>>     
>>>>> participants. I didn't particularly like the way it 
>>>>>           
>> turned out, but 
>>     
>>>>> there seems to be rough consensus that QSPEC 
>>>>>           
>> encapsulation should be 
>>     
>>>> I must have missed this discussion. If people like it that 
>>>>         
>> way then 
>>     
>>>> it should be fine.
>>>>
>>>>         
>>>>>> QoSM (and the AAA part) and a  reader might want to read 
>>>>>>             
>>  all these 
>>     
>>>>>> documents anyway.
>>>>>>
>>>>>> Section 5.3 should be informative only; no RFC 2119 
>>>>>>             
>> language since 
>>     
>>>>>> subsections. The QoSMs provide the normative text and 
>>>>>>             
>> may restrict 
>>     
>>>>> This was one of the reasons I proposed restricting the 
>>>>>           
>> variability 
>>     
>>>> documents define all possible signaling behaviors. Then it 
>>>>         
>> would be 
>>     
>>>> fine as well. It would make the QoSMs more complicated. I, 
>>>>         
>> btw, was 
>>     
>>>>>> For example, what happens if a receiver-initiated 
>>>>>>             
>> reservation meets 
>>     
>>>> documents are simpler since they obviously don't need to 
>>>>         
>> consider all 
>>     
>>>> the different cases.
>>>> We noticed this problem already with the mobility document 
>>>>         
>> where the 
>>     
>>> But this is up to the applications which is more 
>>>       
>> useful/natural, no? 
>>     
>>> that and use receiver-initiated only when they can't 
>>>       
>> conveniently use 
>>     
>>> reservations. But to say that interoperability fails 
>>>       
>> because some QoSM 
>>     
>>> decides receiver-initiated reservations are a pain and 
>>>       
>> redefines QOS 
>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 13:45:01 +0100

Hi Hannes

I believe that what you propose in this e-mail is different 
than what you proposed in the earlier e-mail!

What I would prefer to add to the existing QOSM related list is the
following text:
   
   "The definition of a QoS model may also have implications on how local
   behavior should be implemented in the areas where the QoS NSLP gives
   freedom to implementers. For example, it may be useful to identify
   recommended behavior for how a RESERVE message that is forwarded
   relates to that received, or when additional signaling sessions
   should be started based on existing sessions, such as required for
   aggregate reservations. In some cases, suggestions may be made on
   whether state that may optionally be retained should be held in
   particular scenarios.  A QoS model may specify reservation
   preemption, e.g., an incoming resource request may cause removal of
   an earlier reservation."

Best Regards,
Georgios

> Sent: donderdag 4 januari 2007 12:58
> To: Georgios Karagiannis
> Cc: 'David R Oran'; [email-masked]
>    - QSPEC definition including QSPEC parameters [hannes] 
> Replace the following statement with:
> "
>    - QSPEC procedures applicable to this QOSM "
> this one:
> "
> >>> describe what todo
> processing 
> > Regarding signaling the NSIS WG introduced the concept of 
> QOSM to be 
> > able to support your b) option:
> >   
> parameters 
> feasible data 
> >> versions). Whenever I read through the abstract and the 
> introduction 
> >> I had the impression that I understood what the rest of 
> the document 
> >> is going to contain. I was always wrong. This time I was wrong as 
> >> well.
> >>
> >> It shouldn't be too difficult to tell the reader what the document 
> >> wants to accomplish. If I don't understand it then how 
> should someone 
> >> else (slightly ignoring the fact that everyone else might be 
> >> smarter)?
> >>
> since they 
> processing 
> >> parameters that are understood by everyone and a few optional 
> >> parameters was an interesting idea, I thought. [[ I was 
> never really 
> >> 100 % convinced that it can actually work but that's 
> another story. I 
> >> personally was just unhappy about the choice of mandatory 
> parameters. 
> >> ]]
> >>
> >> one.This is done today already but there are no procedures and 
> >> documents in the NSIS working group for defining these 
> mappings. With 
> >> this approach every QoSM can essentially define whatever 
> they want if 
> >> a reasonable mapping exists.
> >>
> number of 
> >> parameters that are supposed to be complete and MUST be used by 
> >> future QoSMs. To avoid interoperability problems QoSMs 
> ideally must 
> >> never not introduce parameters.
> ensured that 
> >> their QoSM is nicely supported. To allow the end-to-end 
> story to work 
> >> it is necessary to consider today's access networks and the QoS 
> >> parameters that are being used there. Is someone ever 
> wants to use a 
> >> path-coupled signaling solution then two approaches are possible
> triggers the 
> >> NSIS signaling exchange [A combination of the two is also 
> possible.]
> >>
> >> specific link layer. I wonder whether someone has looked at these 
> >> issues already and whether the QSPEC QoS parameter and local QoSM 
> >> model supports this extensibility.
> >>
> >> priority levels. What would I do? This parameter does not 
> correspond 
> >> to anything in the QSPEC document at the moment.
> >>
> >> The idea that the QoSM can change the signaling state machines for 
> >> the NSLP is quite scary to me, which is why I suggested 
> the language 
> >> which said a QOSM isn't permitted to redefine the way QOS 
> NSLP works.
> >> "
> >>
> >>     
> >> This sounds like a very nice. When it comes to the details 
> things get 
> >> a bit more difficult.
> >>
> >>     
> >> I need to read through each paragraph to determine what the 
> >> implications are.
> >>
> >>

---

From: <[email-masked]>
Date: Thu, 4 Jan 2007 15:15:28 +0200

Hi Dave,

>majority of QoS schemes. Let's face it, the number of feasible 
>data plane queueing/scheduling/policing/shaping algorithms is 
>in fact not that large. I think it has yet to be demonstrated 
>that the network- specific QoS parameter cannot in all but 
>some corner cases be represented using the parameters we have 
>come up with. Most of the argument has been based on RMFs that 
>wish to be "simpler" than the general case in which the exact 
>constraints and traffic model parameters of the source are 
>explicit and control what is advisory and what is mandatory 
>for admission.

I agree that this is the goal, in my opinion.  There might be
some QoSM domains that do a little extra, but I think they
need to provide the ability to perform end-to-end signaling.

It has never been a goal of the working group to support
non-interworking
QoS models, or QoS models that would not support end-to-end signaling.

John

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 4 Jan 2007 14:39:55 +0100

Hi Georgios,

> than what you proposed in the earlier e-mail!

I haven't proposed anything in my mail. I tried to understand the new
draft version and the implications. 

I responded to your mail that told me that the QSPEC draft now requires
QoSMs to support all signaling modes. If this is the desired behavior
then the QSPEC draft has to be changed in the way I indicated. 

I would like to better understand the implications. 

Ciao
Hannes

> > >>> a) the QoS NSLP or the QSPEC document mandates a single 
> signaling 
> > >>> mode
> > >> a) the QoS NSLP or the QSPEC document mandates a single 
> signaling 
> > >> mode
> > >> a) the end host already uses a QoS signaling protocol 
> like RSVP or 
> > >> NSIS
> machines for 
> sender-initiated

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 14:42:55 +0100

Hi Hannes

If the the folowing paragraph 
is added to the proposed QoS model capability list 
it will satisfy my concerns on this issue:
"The definition of a QoS model may also have implications on how local
   behavior should be implemented in the areas where the QoS NSLP gives
   freedom to implementers. For example, it may be useful to identify
   recommended behavior for how a RESERVE message that is forwarded
   relates to that received, or when additional signaling sessions
   should be started based on existing sessions, such as required for
   aggregate reservations. In some cases, suggestions may be made on
   whether state that may optionally be retained should be held in
   particular scenarios.  A QoS model may specify reservation
   preemption, e.g., an incoming resource request may cause removal of
   an earlier reservation."

Best regards,
Georgios

> From: Tschofenig, Hannes [mailto:[email-masked]] 
> Sent: donderdag 4 januari 2007 14:40
> To: Georgios Karagiannis; Hannes Tschofenig
> Cc: David R Oran; [email-masked]
> Subject: AW: [NSIS] QSPEC Template Draft Review
> 
> Hi Georgios,
> 
> 
> > Hi Hannes
> > 
> I haven't proposed anything in my mail. I tried to understand 
> the new draft version and the implications. 
> 
> I responded to your mail that told me that the QSPEC draft 
> now requires QoSMs to support all signaling modes. If this is 
> the desired behavior then the QSPEC draft has to be changed 
> in the way I indicated. 
> 
> > >    - QSPEC definition including QSPEC parameters [hannes] Replace 
> > > the following statement with:
> > > "