Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to beIgnored

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 25 Aug 2006 14:38:33 +0100

hi,

on the question of whether a type 1 parameter can be ignored:

i agree that making this change reduces the distinction within
the protocol operation between type 1 and type 2 parameters.

however, i don't think we should lose sight of the fact that
there can still be a difference which applies during the 
specfication process. namely, that when a QoS model is reviewed,
if it defines something a bit like a type 1 parameter but not
identical to it, and/or refuses to say how a type 1 parameter
should be handled when there is a clear way to do so, then this
would be grounds for preventing it being approved as a specification.
(at least, that i my interpretation of the proposal.) 

so, it is a weaker distinction, but still valuable.

cheers,

robert h.

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: 25 August 2006 13:27
> To: Georgios Karagiannis; [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 
> Parameter to beIgnored
> 
> 
> Hi Georgios,
> 
> See comments below. 
> 
> > -----Original Message-----
> > From: Georgios Karagiannis [mailto:[email-masked]] 
> > Sent: Friday, August 25, 2006 5:45 AM
> > To: Ash, Gerald R (Jerry), ALABS; [email-masked]
> > Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 
> > Parameter to be Ignored
> > 
> > Hi Jerry
> > 
> > The below comments are coupled to my comments on QSPEC Issue #1:
> > I am in favour of having the possibility to ignore QSPEC-1 
> > parameters.
> > The reasons are identical to the ones I mentioned in my 
> > comments on Issue #1
> > 
> > 
> > The reasons are:
> > 
> > * Excess treatment parameter.  
> > It should be possible to ignore this parameter in certain domains.
> > For example, when a Diffserv domain is using PCN or RMD it 
> > should be able to
> > ignore this parameter.
> > The reason of this is that the way of how the remarking or 
> > the dropping of
> > packets 
> > is influencing e.g., the PCN or RMD solution. Therefore, it 
> should be
> > possible that the 
> > QNEs that are located in such regions to ignore this parameter.
> > 
> > * QoS class:
> > It should be possible for some QNEs 
> > to ignore this parameter.
> > E.g., problematic when:
> > * a non Diffserv aware QNE receives a PHB class parameter
> > * a non Y.1541 aware QNE receives a Y.1541 class parameter
> > * a non MPLS aware QNE receives a DSTE class parameter.
> > In such situations such QNEs should be able to ignore this 
> parameter.
> > 
> > * Priority
> > You already mentioned some reasons on why it should be 
> > possible to ignore
> > this parameter.
> > 
> > Thus if we allow to ignore QSPEC-1 parameters, then I can 
> > agree on having 4 QSPEC-1 parameters.
> 
> As stated below, allowing to ignore QSPEC-1 parameters would 
> pretty much
> do away with the distinction between QSPEC-1 and QSPEC-2 parameters.
> 
> Thanks,
> Jerry
>  
> > 
> > Best regards,
> > Georgios 
> > 
> > -----Original Message-----
> > From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> > Sent: maandag 14 augustus 2006 23:46
> > To: [email-masked]
> > Cc: Ash, Gerald R (Jerry), ALABS
> > Subject: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 
> > Parameter to be Ignored
> > 
> > Hi All,
> > 
> > One of the issues identified in the updated 'QoS NSLP QSPEC 
> Template'
> > I-D 
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as
> > follows:
> > 
> > 3. agreement/consensus on whether to allow a QSPEC-1 
> (formerly called
> > "mandatory") parameter to be ignored; see Section 4.3.1
> > 
> > There was extensive discussion on the list RE whether to 
> > allow a QSPEC-1
> > parameter to be ignored, as is allowed for a QSPEC-2 
> (formerly called
> > "optional") parameter.  Reasons given for allowing this are 
> > a) use of a
> > QSPEC-1 parameter might be illegal, as with preemption in the 
> > U.S. PSTN, and
> > b) a particular QOSM might not want to support certain 
> > QSPEC-1 parameters,
> > i.e., while it would be nice for all QOSMs to support <QoS
> > Class>, some have suggested that might not be practical/realistic.
> > 
> > Note that this issue is related to Issue #1, that is, if we 
> retain the
> > QSPEC-1 parameter concept, then allowing a QSPEC-1 parameter 
> > to be ignored
> > is a step toward doing away with the distinction between 
> > QSPEC-1 and QSPEC-2
> > parameters.  It is also related to Issue #2 in that an 
> alternative to
> > "strict interpretation" of QSPEC-1 parameters is remapping 
> > these parameters.
> > However, in some cases remapping QSPEC-1 parameters between 
> > classes of QSPEC
> > parameters may not make sense, e.g., mapping <QoS Class> to 
> > <Token Bucket>.
> >  
> > The default resolution is that the QSPEC-1 concept is 
> > retained and that all
> > QSPEC-1 parameters must be strictly interpreted or remapped 
> > by all QOSMs.
> > Alternatively, it is suggested in Section 4.3.1 that if 
> > ignoring a QSPEC-1
> > parameter is to be allowed, that a high threshold be placed 
> > on justification
> > for this in the QOSM specification document:
> > "a QOSM may simply not want to support a QSPEC-1 parameter.  
> > In (that) case
> > justification may be more difficult, however there is a filter on
> > reasonableness in that QOSM specifications must be reviewed 
> > and approved by
> > the IETF."
> > 
> > Please express any further comments in support of the 
> > proposed resolution,
> > or otherwise, so that we may reach consensus on this issue.
> > 
> > Thanks,
> > Regards,
> > Jerry
> 
> _______________________________________________
> 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: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 31 Aug 2006 17:18:36 +0200

Hi Robert

Are you in favour on 
allowing to ignore QSPEC-1 parameters?

Best regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]] 
Sent: vrijdag 25 augustus 2006 15:39
To: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis; [email-masked]
Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to
beIgnored

hi,

i agree that making this change reduces the distinction within the protocol
operation between type 1 and type 2 parameters.

however, i don't think we should lose sight of the fact that there can still
be a difference which applies during the specfication process. namely, that
when a QoS model is reviewed, if it defines something a bit like a type 1
parameter but not identical to it, and/or refuses to say how a type 1
parameter should be handled when there is a clear way to do so, then this
would be grounds for preventing it being approved as a specification.
(at least, that i my interpretation of the proposal.) 

cheers,

robert h.

> Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to 
> beIgnored
> 
> 
> Hi Georgios,
> 
> See comments below. 
> 
> > Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter 
> > to be Ignored
> > 
> > Hi Jerry
> > 
> > The reasons are identical to the ones I mentioned in my comments on 
> > Issue #1
> > 
> > 
> > The reasons are:
> > 
> > For example, when a Diffserv domain is using PCN or RMD it should be 
> > able to ignore this parameter.
> > The reason of this is that the way of how the remarking or the 
> > dropping of packets is influencing e.g., the PCN or RMD solution. 
> > Therefore, it
> should be
> > possible that the
> > It should be possible for some QNEs to ignore this parameter.
> > E.g., problematic when:
> > You already mentioned some reasons on why it should be possible to 
> > ignore this parameter.
> > 
> > Thus if we allow to ignore QSPEC-1 parameters, then I can agree on 
> > having 4 QSPEC-1 parameters.
> 
> As stated below, allowing to ignore QSPEC-1 parameters would pretty 
> much do away with the distinction between QSPEC-1 and QSPEC-2 
> parameters.
> 
> Thanks,
> Jerry
>  
> > 
> > Best regards,
> > Georgios
> > 
> > Subject: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to be 
> > Ignored
> > 
> > Hi All,
> > 
> > There was extensive discussion on the list RE whether to allow a 
> > QSPEC-1 parameter to be ignored, as is allowed for a QSPEC-2
> (formerly called
> > QSPEC-1 parameter might be illegal, as with preemption in the U.S. 
> > PSTN, and
> > QSPEC-1 parameter concept, then allowing a QSPEC-1 parameter to be 
> > ignored is a step toward doing away with the distinction between
> > QSPEC-1 and QSPEC-2
> > "strict interpretation" of QSPEC-1 parameters is remapping these 
> > parameters.
> > However, in some cases remapping QSPEC-1 parameters between classes 
> > of QSPEC parameters may not make sense, e.g., mapping <QoS Class> to 
> > <Token Bucket>.
> >  
> > The default resolution is that the QSPEC-1 concept is retained and 
> > that all
> > QSPEC-1 parameters must be strictly interpreted or remapped by all 
> > QOSMs.
> > Alternatively, it is suggested in Section 4.3.1 that if ignoring a 
> > QSPEC-1 parameter is to be allowed, that a high threshold be placed 
> > on justification for this in the QOSM specification document:
> > reasonableness in that QOSM specifications must be reviewed and 
> > approved by the IETF."
> > 
> > Please express any further comments in support of the proposed 
> > resolution, or otherwise, so that we may reach consensus on this 
> > issue.
> > 
> > Thanks,
> > Regards,
> > Jerry
>