Subject: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 17:19:25 +0200

Hi John

The main problems that we have had in NSIS since 8 months now 
are related to the fact that 13 parameters were specified in the 
QSPEC template draft as being mandatory/QSPEC-1 parameters.

>From what I understood, see below, we finally reached an agreement 
and solved the QSPEC mandatory/optional discussion 
that started +/- 8 months ago. 
Thus actually we come to an agreement!

I am assuming that this means that:

* the QSPEC template will specify only one QSPEC-1 (mandatory) parameter,
i.e.,
 Token Bucket that could be remapped to peak bandwidth

* the rest of the QSPEC parameters are considered as QSPEC-2 (optional)
   parameters!

Now we can finalise the NSIS base specification 
and start with the deployment phase!

John do you agree!

Best regards,
Georgios

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]] 
> Sent: donderdag 19 oktober 2006 15:53
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [NSIS] QSPEC proposal
> 
> 
> On Oct 19, 2006, at 9:34 AM, Georgios Karagiannis wrote:
> 
> > Hi Dave
> >
> > By mandatory I mean:
> > x) must be understood by every QOS NSLP-capable network 
> element in the 
> > universe
> >
> > The current QSPEC template specification defines:
> > 13 parameters that "must be understood by every QOS NSLP-capable 
> > network element in the universe"
> >
> yes. that's a bug in my opinion.
> 
> > My question is:
> > Is your proposal refering only to one parameter, i.e., Token Bucket 
> > that "must be understood by every QOS NSLP-capable network 
> element in 
> > the universe"?
> >
> Yes, with the proviso that I think the user needs the 
> flexibility to control whether he wants admission control to 
> fail if a constraint can't be satisfied due to the path going 
> through something that doesn't understand the parameter. 
> Reread what I wrote below.
> 
> > Best regards,
> > Georgios
> >
> >
> >
> >> -----Original Message-----
> >> From: David R Oran [mailto:[email-masked]]
> >> Sent: donderdag 19 oktober 2006 15:25
> >> To: Georgios Karagiannis
> >> Cc: [email-masked]; [email-masked]; [email-masked]
> >> Subject: Re: [NSIS] QSPEC proposal
> >>
> >>
> >> On Oct 19, 2006, at 9:08 AM, Georgios Karagiannis wrote:
> >>
> >>> Hi John
> >>>
> >>> I also still do not understand point 4)?
> >>>
> >>> Is this relkated to the possibility of ignoring mandatory
> >> parameters?
> >>>
> >>> How many mandatory parameters will then the base QSPEC have?
> >>> I assume that Dave, proposed to have one mandatory
> >> parameter and that
> >>> is the
> >>>
> >>> Token Bucket specification.
> >>>
> >> I still think we are talking past each other. Please tell 
> me which of 
> >> the following is your intended definition of "mandatory"
> >> w) must be present in any QSPEC formulated by the end user
> >> x) must be understood by every QOS NSLP-capable network element in 
> >> the universe
> >> y) must result in admission control success in any NSLP-capable 
> >> network element that has sufficient resources to comply with the 
> >> specified value by the user.
> >>
> >> My preferred formulation is actually none of the above.
> >>
> >> 1. that only the TSPEC-like parameters in my traffic description 
> >> proposal be mandatory in the sense that your request is 
> syntactically 
> >> invalid if they are not present.
> >> 2. That all the traffic description in my (b) category be optional 
> >> both for inclusion and for interpretation by the network elements.
> >> 3. That for the constraint parameters, we explicitly encode in the 
> >> protocol whether the user wants to have admission control 
> succeed  IF 
> >> AND ONLY IF the parameter is understood, and the constraint 
> >> satisfied, by each QOS NSLP-capable network element on the 
> signaling 
> >> path. I do not like the ideaq of statically binning the constraint 
> >> parameters in architectural "mandatory/optional" categories.
> >>
> >> Cheers, Dave.
> >>
> >>
> >>> Best Regards,
> >>> Georgios
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]]
> >>>> Sent: donderdag 19 oktober 2006 14:25
> >>>> To: [email-masked]
> >>>> Cc: [email-masked]; [email-masked]
> >>>> Subject: RE: [NSIS] QSPEC proposal
> >>>>
> >>>> Hi Janet,
> >>>>
> >>>> What I mean is that there could be a way to 
> transparently pass the 
> >>>> QoS Model QSPEC without mapping it to the baseline QSPEC.
> >>>>
> >>>> John
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: ext Janet P Gunn [mailto:[email-masked]]
> >>>>> Sent: 19 October, 2006 15:00
> >>>>> To: Loughney John (Nokia-NRC/Helsinki)
> >>>>> Cc: [email-masked]; [email-masked]
> >>>>> Subject: Re: [NSIS] QSPEC proposal
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Can you please rephrase number 4?  I don't understand it the
> >>>> way it is
> >>>>> currently written.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Janet
> >>>>>
> >>>>>
> >>>>> <[email-masked]> wrote on 10/19/2006 07:43:25 AM:
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I've been in transit for a few days, so trying to
> >> catch-up on all
> >>>>>> mails is somewhat challenging.  Here's a partially baked
> >> proposal,
> >>>>>> considering the mails on this thread.  My proposal for the
> >>>>> WG to consider  is:
> >>>>>>
> >>>>>> 1) We take Dave's proposal as a baseline QSPEC:
> >>>>>>
> >>>>>> 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)
> >>>>>>
> >>>>>> 2) Allow QoS Models to use a secondary QSPEC, that may not be 
> >>>>>> mathmetically complete.
> >>>>>> 3) QoS models specify how to map to the baseline QSPEC.
> >>>>>> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they
> >>>>> want their
> >>>>>> model mapped (or not) to domains support QoS models.
> >>>>>>
> >>>>>> Would this meet people's needs?  I could see that point 4
> >>>>> might allow
> >>>>>> use cases that Lars/Georgios would like.
> >>>>>>
> >>>>>> Robert and Dave seem to agree that point 1) is not too far
> >>>> from the
> >>>>>> current QSPEC.
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> nsis mailing list
> >>>>>> [email-masked]
> >>>>>> https://www1.ietf.org/mailman/listinfo/nsis
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 11:30:31 -0400

Georgios,

You conveniently ignored the part of my message which said:

> protocol whether the user wants to have admission control succeed  IF
> satisfied, by each QOS NSLP-capable network element on the signaling

In the absence of this or something like it, if all you have is the  
source traffic descriptor we are back to having no way for the user  
draw any conclusions about what it means for a QOS NSLP reservation  
to be admitted. The debate isn't really about mandatory versus  
optional parameters, but finding some architecturally clean way to  
define a protocol that allows flexible QoS state installation in the  
data plane while retaining some meaningful semantics for admission  
control.

Cheers, Dave.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 17:38:55 +0200

Hi Dave

I think that what you mentioned in 3. is already specified in 
the current version of the QSPEC template draft, even when the base for 
interoperability between QoS models is considered to (only) be the 
Token Bucket specification.

Best regards,
Georgios

> Sent: donderdag 19 oktober 2006 17:31
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division
> 
> Georgios,
> 
> satisfied, 
> > by each QOS NSLP-capable network element on the signaling 
> path. I do 
> > not like the ideaq of statically binning the constraint 
> parameters in 
> > architectural "mandatory/optional" categories.
> 
> In the absence of this or something like it, if all you have 
> is the source traffic descriptor we are back to having no way 
> for the user draw any conclusions about what it means for a 
> QOS NSLP reservation to be admitted. The debate isn't really 
> about mandatory versus optional parameters, but finding some 
> architecturally clean way to define a protocol that allows 
> flexible QoS state installation in the data plane while 
> retaining some meaningful semantics for admission control.
> 
> Cheers, Dave.
> 
>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 19 Oct 2006 12:52:53 -0400

A clear alternative elaborate proposal will help to understand how we can address these problems.
 
We can then discuss the pros and cons about this proposal.
 
BR/Radhika
 
PS: Did you also have the chance to study the interworking between different QOS models? Is it possible to generalize in the same draft without splitting into two?

________________________________

From: [email-masked] on behalf of David R Oran
Sent: Thu 10/19/2006 11:30 AM
To: Georgios Karagiannis
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division

Georgios,

Cheers, Dave.