Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter list?

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 18 Jul 2006 16:12:34 +0100

hi all,

just to check I understand the draft correctly: the
*current* list of mandatory parameters (that can occur
in a QoS description object) is:

          7.2.3 <Bandwidth>
          7.2.5 <Token Bucket> Parameters (1st instance only)
          7.2.6 <QoS Class> Parameters (3 subtypes)
          7.2.7 Priority Parameters (3 subtypes)
          7.2.12 <Ctot> <Dtot> <Csum> <Dsum> Parameters

is this correct?

r.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: 17 July 2006 14:08
> To: [email-masked]; 
> [email-masked]; [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory 
> parameter list?
> 
> 
> 
> Hi Cornelia
> 
> >From my point of view the only mandatory parameters are the Traffic
> specification parameters i.e., <Token Bucket>, <Bandwidth> 
> and the "Non
> QoSM Hop", assuming that the QoS-NSLP will include the "non QoS-NSLP
> Hop" parameter, see my previous e-mail on this!
> 
> Best regards,
> Georgios
> 
> On 7/17/2006, "Kappler, Cornelia" 
> <[email-masked]> wrote:
> 
> >Dear all,
> >
> >I've been off-list for the last 10 days and may have 
> difficulties grasping the real point of the debate.
> >
> >I'd prefer some concrete suggestions to which parameters 
> should not be mandatory. Rather than blanket statements "List 
> is too long" or "List is too short" or "we should have N parameters".
> >
> >The question is not really whether it should be 2 or 8 or 20 
> mandatory parameters. It is _which_ parameters are necessary 
> to _just_ accomodate the key ideas of typical QOSMs.
> >
> >Cornelia
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Georgios Karagiannis [mailto:[email-masked]]
> >> Gesendet: Samstag, 15. Juli 2006 19:58
> >> An: 'Bernd Schloer'; 'Jukka MJ Manner'
> >> Cc: 'Ash, Gerald R \(Jerry\), ALABS'; [email-masked]
> >> Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory
> >> parameter list?
> >>
> >> Hi
> >>
> >> Okay, but how many mandatory parameters should the central
> >> draft contain?
> >>
> >> Best Regards,
> >> Georgios
> >>
> >> -----Original Message-----
> >> From: Bernd Schloer [mailto:[email-masked]]
> >> Sent: zaterdag 15 juli 2006 19:32
> >> To: Jukka MJ Manner
> >> Cc: Ash, Gerald R \(Jerry\), ALABS; [email-masked]
> >> Subject: Re: [NSIS] Any resolution to the QSPEC mandatory
> >> parameter list?
> >>
> >> Hi,
> >>
> >> it would be easier to define new QOSMs, when the mapping 
> of mandatory
> >> parameters is listed in a central draft. This would also ensure
> >> interoperability.
> >>
> >> Bernd
> >>
> >>
> >> Jukka MJ Manner wrote:
> >> > Hi,
> >> >
> >> > I think the problem is that setting too many mandatory parameters
> >> > effectively limits people to define new QOSMs (even the
> >> current ones)
> >> > - all QOSMs must be based on IntServ or DiffServ.
> >> Interworking is an
> >> > important issue, I fully agree. That is why I'm not sure
> >> which way we
> >> > should actually go: more or less mandatory parameters. 
> (I think I'm
> >> > inclined towards more flexibility)
> >> >
> >> > About the need for a change, I haven't seen any comment 
> so far for
> >> > keeping the longish list of mandatory parameters. All 
> messages have
> >> > been about introducing more flexibility. We should have had
> >> a hummm at
> >> > the meeting to see what people would want.
> >> >
> >> > Maybe people could speak up about what they want?
> >> >
> >> > Jukka
> >> >
> >> > On Thu, 13 Jul 2006, Ash, Gerald R \(Jerry\), ALABS wrote:
> >> >
> >> >
> >> >>Hi Jukka,
> >> >>
> >> >>See below.
> >> >>
> >> >>
> >> >>>-----Original Message-----
> >> >>>From: Jukka MJ Manner [mailto:[email-masked]]
> >> >>>Sent: Thursday, July 13, 2006 10:19 AM
> >> >>>To: [email-masked]
> >> >>>Subject: [NSIS] Any resolution to the QSPEC mandatory
> >> parameter list?
> >> >>>
> >> >>>
> >> >>>I think the discussion on the mandatory and optional
> >> parameters ended
> >> >>>without a clear resolution. I think there were good notes
> >> on making
> >> >>>the list of mandatory parameters shorter and/or allow 
> an "ignore"
> >> >>>interpretation of a mandatory parameter, and other ways to
> >> make the
> >> >>>template less strict. I also support these comments.
> >> >>>
> >> >>>Any views from the QSPEC people on how to resolve these 
> comments?
> >> >>
> >> >>I'm not in favor of fundamentally changing the definition
> >> of mandatory
> >> >>and optional QSPEC parameters, as I think is being proposed.  In
> >> >>effect, to allow a mandatory parameter to be ignored would
> >> eliminate
> >> >>the distinction between mandatory parameters (MUST interpret if
> >> >>populated) and optional parameters (SHOULD interpret if
> >> populated).
> >> >>The original idea of the QSPEC template is to provide a
> >> common set of
> >> >>mandatory parameters that would be interpreted (if 
> populated by the
> >> >>QNI) by all QOSMs.  This would allow a degree of 
> interoperability.
> >> >>The set of mandatory parameters is based in part on 
> parameters from
> >> >>the INTSERV and DIFFSERV models that should be commonly
> >> interpreted by
> >> >>all QOSMs (that was the original charge to the QSPEC 
> template draft
> >> approach).
> >> >>
> >> >>The other alternative (i.e., to be able to 'ignore' mandatory
> >> >>parameters) is essentially to make all parameters optional
> >> parameters
> >> >>(SHOULD interpret if populated).  Optional parameters allow
> >> the N-flag
> >> >>(not supported flag) to be set if a QOSM wishes to 'ignore' (not
> >> >>interpret) a parameter.
> >> >>
> >> >>I'm not clear on the motivation for this other alternative.
> >>  Perhaps
> >> >>some particular QOSM wants to introduce the possibility of
> >> 'ignoring'
> >> >>mandatory parameters.  Y.1541-QOSM doesn't require this nor
> >> does the
> >> >>CL-QOSM (AFAIK).  Perhaps the RMD-QOSM for some reason
> >> requires this
> >> >>-- if so, I'm not clear what is the justification?
> >> >>
> >> >>I haven't seen that much support for a major change in the QSPEC
> >> >>template approach to be able to 'ignore' mandatory parameters.
> >> >>
> >> >>Thanks,
> >> >>Jerry
> >> >>
> >> >>
> >> >>>Regards,
> >> >>>Jukka
> >> >>>
> >> >>>_______________________________________________
> >> >>>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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> 

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

---

From: Bernd Schloer <[email-masked]>
Date: Tue, 18 Jul 2006 23:04:42 +0200

Hi Robert,

currently the following parameters are mandatory (where the M-Flag is set):

    7.2.1 <NON QOSM Hop>
    7.2.2 <Excess Treatment>
    7.2.3 <Bandwidth>

Bernd

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 18 Jul 2006 16:09:59 -0500

Hi Robert,

See below. 

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Tuesday, July 18, 2006 11:13 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]
> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory 
> parameter list?
> 
> hi all,
> 

Yes to the first 3 QSPEC parameters (<Bandwidth> <Token Bucket> <QoS Class>), however <Ctot> <Dtot> <Csum> <Dsum> are optional QSPEC parameters.

Also, I agree with the above characterization.  We can group into only 3 mandatory QSPEC QoS Description parameters (containers), as follows:

1. <Traffic>: <bandwidth>; <token bucket (first instance)>  (populate only one)
2. <QoS class>: <PHB class>; <y.1541 class>; <DSTE class type> (populate only one)
3. <Priority>: <preemption/defending>; <admission/RPH> (populate only one pair)

These plus one mandatory QSPEC control information parameter (<Excess treatment>) makes only 4 mandatory QSPEC parameters in total, which seems minimal, and is consistent with the original concept.

Thanks,
Jerry

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 19 Jul 2006 13:58:01 -0400

"Ash, Gerald R \(Jerry\), ALABS" <[email-masked]> wrote on 07/18/2006
05:09:59 PM:

> ...
> Also, I agree with the above characterization.  We can group into
> only 3 mandatory QSPEC QoS Description parameters (containers), as
follows:
>...

A couple of questions/comments.

With regard to the Priority parameters, it was not at all clear to me (even
going back and reading it again) that you could only populate ONE pair:
<preemption/defending> OR <admission/RPH> but NOT BOTH.

If that is the case, then it needs to be made clearer in the text.  In
fact, it isn't even clear that admission/RPH have to be there as a pair.

The text says:
"   As specified in [RFC3181], <Preemption Priority> and <Defending
   Priority> are 16-bit integer values and both MUST be populated if the
   parameter is used.", so it is clear that you have to have neither or
both of those.

But it also says:
"   Note that the <Admission Priority> parameter MAY be used in
   combination with the <RPH Priority> parameter, which depends on the
   supported QOSM." which leads me to believe you can have one without the
other.

It also says:
"[SIP-PRIORITY] defines a resource priority header (RPH) with
   parameters "RPH Namespace" and "RPH Priority" combination, and if
   populated is applicable only to flows with high reservation priority,"

If "reservations priority" = "admission  priority" (and I think it probably
does), then it would be clearer to use one term instead of two.  This text
then implies to me that it is permissible to have "admission priority"
without "RPH", but not permissible to have "RPH" without "admission
priority" (although it might also mean that RPH is ignored in instances
without "admission priority").

Then my next question is - Why can't you have ALL FOUR of
 <preemption/defending/admission/RPH>?
or three
<preemption/defending/admission>?
or just one
<admission>?
as well as the cases with exactly two of them?

I can certainly think of use cases.  For instance, if you want to implement
eMLPP-like functionality (as defined in 3GPP), you would want an <admission
priority> (corresponding to the "queueing allowed" part of eMLPP) as well
as <preemption/defending> (corresponding to the "preemption capable" and
"may be preempted" parts of eMLPP).

Am I missing something?

Thanks,

Janet

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 19 Jul 2006 15:47:34 -0500

Janet,

See below. 

> From: Janet P Gunn [mailto:[email-masked]] 
> Sent: Wednesday, July 19, 2006 1:58 PM
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; Hancock,Robert

Agreed.  The text has to be clearer on these points (there was also some
prior comment on this on the list).
 
>    supported QOSM." which leads me to believe you can have 

Right.
 
> does), then it would be clearer to use one term instead of 
> two.  

Good point, I agree.

> This text

Right.  This should be clarified also.
 
> as well as the cases with exactly two of them?

<admission> priority without RPH is allowed, which needs to be better
clarified as per above comments.
 
> "may be preempted" parts of eMLPP).

The procedures for the cases of two parameters being used, that is
<preemption/defending> priority and
<admission/RPH> priority
are given in normative references.

Similarly, there need to be referenced normative procedures for how to
treat the case of 3 or all 4 being populated, if these are also
specified:
<preemption/defending/admission>
<preemption/defending/admission/RPH>

Are there such normative references that specify procedures for how to
handle these above cases or 3 or 4 parameters being specified?

Alternatively, procedures for these cases can be specified in the QSPEC
document.  If this approach is used, suggested text is appreciated.

Another approach is that the procedures for the cases of 3 or 4
parameters being used can be contained in separate QOSM specification
documents (that would be pointed out the text in the QSPEC document). 

Thanks,
Jerry

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 19 Jul 2006 17:15:06 -0400

I will find the appropriate references for eMLPP in 3GPP.

Janet

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

"Ash, Gerald R \(Jerry\), ALABS" <[email-masked]> wrote on 07/19/2006

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 19 Jul 2006 17:52:37 -0400

Jerry,

Here are some OLD (release 99) normative references for eMLPP.

 3GPP TS 22.067 version 3.0.1 (1999-10), “3rd Generation Partnership
Project;
Technical Specification Group Services and System Aspects; enhanced
Multi-Level
Precedence and Pre-emption (eMLPP) – Stage 1 (Release 1999).”

 3GPP TS 23.067 version 3.3.0 (2001-06), “3rd Generation Partnership
Project;
Technical Specification Group Core Network; enhanced Multi-Level Precedence
and
Pre-emption (eMLPP) – Stage 2 (Release 1999).”

 3GPP TS 24.067 version 3.2.0 (2001-06), “3rd Generation Partnership
Project;
Technical Specification Group Core Network; enhanced Multi-Level Precedence
and
Pre-emption (eMLPP) – Stage 3 (Release 1999).”

I'll work on nailing down some more recent ones.

Janet

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 19 Jul 2006 22:52:00 -0400

The new versions are

3GPP TS 22.067 V7.0.0 (2006-03)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;
enhanced Multi﷓Level Precedence and Pre﷓emption service
(eMLPP) ﷓ Stage 1
(Release 7)

3GPP TS 23.067 V7.1.0 (2006-03)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Core Network;
enhanced Multi-Level Precedence and
Pre-emption service (eMLPP) - Stage 2
(Release 7)

3GPP TS 24.067 V6.0.0 (2004-12)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Core Network;
enhanced Multi-Level Precedence and
Pre-emption service (eMLPP) - Stage 3
(Release 6)

(I'm not sure when the Release 7 version of 24.067 will be out.)

Janet

> > > Janet_______________________________________________
> nsis mailing list
> [email-masked]

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 19 Jul 2006 22:01:58 -0500

Thanks Janet, will reference these icw procedures for these 2 cases:

Regards,
Jerry

-----Original Message-----
From: Janet P Gunn [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2006 10:52 PM
To: Janet P Gunn
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; Hancock,Robert
Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter
list?

The new versions are

3GPP TS 22.067 V7.0.0 (2006-03)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;
enhanced Multi Level Precedence and Pre emption service
(eMLPP)   Stage 1
(Release 7)

Janet
Janet P Gunn/FED/CSC@CSC wrote on 07/19/2006 05:52:37 PM:

>  3GPP TS 22.067 version 3.0.1 (1999-10), "3rd Generation Partnership
> Project;
> Precedence and Pre-emption (eMLPP) - Stage 1 (Release 1999)."
>
>  3GPP TS 23.067 version 3.3.0 (2001-06), "3rd Generation Partnership
> Project;
> Pre-emption (eMLPP) - Stage 2 (Release 1999)."
>
>  3GPP TS 24.067 version 3.2.0 (2001-06), "3rd Generation Partnership
> Project;
> Pre-emption (eMLPP) - Stage 3 (Release 1999)."
>