One more time from left-field (I know... I've lost this one before  
and should keep my mouth shut).

Much of this confusion is because I believe the qspec draft and the  
current notion of "QoS models" has a poor architectural partitioning  
and hence falls into these kinds of discussions of what is over and  
under specification, what it means for a parameter to be mandatory, etc.

A long time ago I proposed a different architectural partitioning  
(and moving some things like priority outside the qspec entirely  
since it was a general admission control parameter and not a QoS  
parameter). I won't resurrect the whole thing here but remind people  
if they want to go back a couple of years in the archives they;ll  
find the outline of the proposal and the ensuing discussion. I shut  
up because the WG consensus was against my proposal and I'm not in  
the habit of continuing to make a pain of myself when I lose an  
argument.

However, it does strike me that this long thread and the last-minute  
discussions on the qspec draft do have a flavor of the issues I was  
raising way back when. Just to remind folks, I proposed, more or less:

a) a set of parameters, all mandatory, that describe the traffic  
source in a mathematically complete way.
b) a set of parameters, all optional, which give additional hints  
about characteristics of the source traffic which may allow network  
elements to optimize their treatment (compressibility hints, pre- 
encryption hints)
c) a set of parameters, mostly optional, that describe the QoS  
constraints the source wishes applied to the treatment of this  
traffic (loss rate, jitter, sensitivity to out of order delivery, etc.)
d) a set of handling directives, all optional, which specify the  
source's preferences for for traffic handling (e.g. excess treatment)

I think there are a number of ways to close down this discussion ,  
through which I notice there have been only a few people complaining:

a) tell them to shut up, that the WG consensus stands, and see what  
happens during last call.
b) rethink the spec along the lines I outline above and ask those  
folks if that would address their concerns
c) ask for a formal outside review, either by raising these issues  
explicitly in the last call and requesting comments, or punting to  
the IESG to solicit such advice.

I promise not to rock the boat if you choose (a).

Dave  Oran.

On Oct 17, 2006, at 8:32 AM, Lars Westberg wrote:

>
> The specification of Qspec1 is mandatory and therefore as I can see  
> can not be avoided and
> The parameter description in The Qspec-1 is more detalied than   
> Int.serv.
> The reason for dividing NSIS in three layers was that Int.serv.   
> was too tightly built-into RSVP.
> Now, I see that this benefit is gone and what's the gain with NSIS  
> for QoS ?
>
> If one just read the specification, and compare it with Int.serv.  
> oe can conclude the following:
> 1) More parameters than Intserv. (excess treatment, priority???)
> 2) More functionality required for implementation even if its never  
> used.
>
> issues like :
> how to model MEF bearer service definition ?????
>
> ...more layers with more functionality in each layer stacked on  
> each other. I do not know what to do.....
>
> regards Lasse
>
>
>
> Kappler, Cornelia wrote:
>> Hi Lasse,
>>
>> "specification of treatment of a flow" should be done in the QOSM  
>> Specs (e.g. RMD, CLS), it is not at an issue of the QSPEC.
>>
>> The job of the QSPEC draft is to define a set of parameters that  
>> QOSM specs can choose from to define this treatment. (Would you  
>> agree this is a reasonable approach?)
>>
> if the collection of paramters does not limit the applicabillity of  
> QoS-models that may be ok.
>
>> Could you more concretely point out where in the QSPEC a specific  
>> flow treatment is defined - beyond the (necessary) description of   
>> how a particular parameter should be dealt with?
> I have sent out pointer to Metro-Ethernet forum specification.
>>
>> Cornelia
>>
>> Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]
>> Gesendet: Dienstag, 17. Oktober 2006 10:56
>> An: Kappler, Cornelia
>> Cc: Georgios Karagiannis; gash@att.com; nsis@ietf.org
>> Betreff: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
>>
>> comments inline
>>
>> Kappler, Cornelia wrote:
>>> Hi Lars,
>>>
>>> could you explain why the qspec draft defines a new bearer service?
>>>
>> let's define it as "Specification of the Controlled-Load Network  
>> Element Service"
>> =>a specifiaction of treatment of a "flow".
>>> What is a bearer service? This concept exists in 3GPP, but it  
>>> does not exist in IETF I dont think, and I dont think the 3GPP  
>>> definition is transferrable to IETF. So what exactly are you  
>>> stating?
>>>
>> see above.
>>> Cornelia
>>>
>>> Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]
>>> Gesendet: Dienstag, 17. Oktober 2006 08:46
>>> An: Georgios Karagiannis
>>> Cc: gash@att.com; nsis@ietf.org
>>> Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
>>>
>>> yes.
>>> the main problem is that IETF is not the only Standardization  
>>> organization that like to discuss "bearer services". Just as an  
>>> example :
>>> If we specify the those parameters, How can we use NSIS for SLAs  
>>> specified by MEF????
>>>
>>> How can we use it for 3GPP-Qos definitiions ?
>>>
>>>
>>> In the draft I also see  that we the draft specify a new bearer  
>>> service. It is not compliant to old Int.serv architecture.  This  
>>> is a completely new one with new parameters like priority.
>>>
>>> I can sure that we can have a never-ending discussion about the  
>>> "optimal"-set of parameters.
>>>
>>> I think we agree in beggining the working group discussion that  
>>> we should not specify any "bearer-service" because NSIS should be  
>>> a modular architecture with  more flexibillity than RSVP.   
>>> Therefore, I am surprised that we are doing the same mistake as  
>>> in RSVP: Integrating a bearer service definition into the NSIS- 
>>> architecture.
>>>
>>> If we go this track, the QoS-part of NSIS has much less use. RSVP  
>>> is in this case significantly better in terms of performance and  
>>> have the same functionality than NSIS.
>>> If have to choose I would select RSVP rather than a much more  
>>> complex  three layer protocol stack.
>>>
>>> regards Lasse
>>>
>>> Georgios Karagiannis wrote:
>>>> Hi Lars Do you mean that the QSPEC template must not contain any  
>>>> mandatory (QSPEC-1) parameters? Best Regards, Georgios On  
>>>> 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com> wrote:
>>>>> Hi, The template seems not to be a template because the  
>>>>> mandatory part is more or less the same as Intserv. The main  
>>>>> idea with QoS-template was to make an modular solution that  
>>>>> could allow flexibillity for different Qos-models Therefore, I  
>>>>> do not understand the scope of the specification. I suggest  
>>>>> that we move the major part of the parameters to a separate  
>>>>> "Int.serv. over NSIS" specification. Int.serv. can be seen as a  
>>>>> common bearer service. regards Lasse Ash, Gerald R (Jerry),  
>>>>> ALABS wrote:
>>>>>> Lars,
>>>>>>> You mention in the below e-mail that there are no open  
>>>>>>> issues, while there is a huge discussion on the nsis mailing  
>>>>>>> list regarding the QSPEC-1 parameters.
>>>>>> John can call a different consensus if he sees one (I've asked  
>>>>>> him a couple of times to do that). What I saw was 1. Many  
>>>>>> posts supported the QSPEC-1 concept, only one (or maybe two) I  
>>>>>> saw opposed. The opposing view was repeated *many* times (and  
>>>>>> is still being repeated) but it only counts as one opinion. 2.  
>>>>>> Many posts supported retaining the 4 QSPEC-1 parameters, only  
>>>>>> one I saw opposed. The opposing view was repeated many times.  
>>>>>> 3. There was only one opinion expressed to be able to ignore  
>>>>>> QSPEC-1 parameters. That one opinion has been repeated many  
>>>>>> times but it only counts as one opinion. John asked a while  
>>>>>> ago for new opinions on these issues, that would be good if  
>>>>>> there are any *new* opinions. We don't need to hear opinions  
>>>>>> repeated that we've seen so many times. I invite John once  
>>>>>> again to make a consensus call so we can move on here. I think  
>>>>>> it is time to make progress and stop repeating ourselves,  
>>>>>> we're not generating any new light in this rather endless  
>>>>>> discussion. Thanks, Jerry
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis