Subject: AW: [NSIS] draft-qosmodel-controlledload-04

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 4 Jul 2006 14:00:49 +0200

Hi Bernd, 

I got your idea. To be honest I am the wrong person to judge which parameter should be mandatory or optional. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Bernd Schloer [mailto:[email-masked]] 
> Gesendet: Dienstag, 4. Juli 2006 13:32
> An: Hannes Tschofenig
> Cc: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis; 
> Kappler, Cornelia; [email-masked]; "Attila Báder (IJ/ETH)"
> Betreff: Re: [NSIS] draft-qosmodel-controlledload-04
> 
> Hi Hannes, please see inline.
> 
> Benrnd
> 
> 
> Hannes Tschofenig wrote:
> > Hi Bernd,
> > 
> > 
> > Bernd Schloer wrote:
> > 
> >> Hi all,
> >>
> >> just an idea:
> >>
> >> Token Bucket is the only mandatory parameter.
> > 
> > 
> > There are several mandatory parameters defined in the QSPEC, namely:
> > 
> > * NON QOSM Hop
> > * Excess Treatment
> > * Bandwidth
> > * Token Bucket
> the above should be mandatory.
> 
> > * PHB Class
> > * Y.1541 QoS Class
> > * DSTE Class Type
> > * <Preemption Priority> & <Defending Priority>
> > * Admission Priority
> > * RPH Priority
> this should be optional. as suggested a bit earlier the ping 
> tool could update 
> the path latency.
> > 
> > Are you suggesting to reduce the list to a single mandatory 
> parameter?
> > 
> >  It is interpreted by CLS
> > 
> >> and Y.1541. RMD can map it to Bandwidth.
> > 
> > 
> > CLS and Y.1541 use the token bucket parameter.
> > 
> > RMD says that it can be mapped to bandwidth if the e2e 
> message contains 
> > the token bucket parameter in a QOSM that is not understood.
> > 
> >>
> >> Other Parameters, like Path Latency,etc. are optional. If a QOSM 
> >> doesn't support it, it can be skipped.
> > 
> > 
> > Correct.
> > 
> > 
> >>
> >> Mainly two types of parameters are left: Delay, Priority. 
> If supported 
> >> by two different QOSMs, the following mapping could be tried:
> >>
> >> Delay: <Y.1541 QoS Class> can be mapped to <Path Latency>, <Path 
> >> Jitter>, <Path PLR/PER>
> >>
> >> Priority: <DSTE Class Type ? >, <Premption Priority>, <Admission 
> >> Priority>, <RPH Priority>
> >> Here <Admission Priority> should rather be derived from 
> <RPH Priority> 
> >> than vice versa, as <RPH Priority> is more complex. Or in 
> general the 
> >> simple parameters should be derived from the more complex one.
> > 
> > 
> > I do not quite follow this idea.
> > 
> >>
> >> The only problem I see: Do I know the QOSM of my neighbor 
> domain? Do I 
> >> have to consider this when sending the initiator QSPEC?
> > 
> > 
> > Note that you do not necessarily only need to know your neighoring 
> > domain. Consider the migration scenario where many networks don't 
> > understand the QoS signaling message at all. For example, you might 
> > consider the case where only the access networks inspect the NSIS 
> > signaling messages.
> > 
> > 
> > Ciao
> > Hannes
> > 
> >>
> >> Bernd
> >>
> >>
> >>
> >>
> >> Attila Báder (IJ/ETH) wrote:
> >>
> >>> Hi All,
> >>>
> >>> If "ignore" is not a type interpretation, I also think 
> that it should 
> >>> be reformulated.
> >>>
> >>> In general, to understend mandatory parameters that is 
> not used in a 
> >>> local QoSM, I see less problem. If a QOSM has to fill in 
> mandatory 
> >>> parameters that is not used in this QOSM, seems to be 
> more difficult.
> >>>
> >>> Best regards, Attila
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Hannes Tschofenig [mailto:[email-masked]]
> >>>> Sent: Monday, July 03, 2006 4:37 PM
> >>>> To: Georgios Karagiannis
> >>>> Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila Báder (IJ/ETH);
> >>>> [email-masked]; 'Kappler Cornelia'
> >>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04
> >>>>
> >>>>
> >>>> Hi Georgios,
> >>>>
> >>>> please find my comment below:
> >>>>
> >>>> Georgios Karagiannis wrote:
> >>>>
> >>>>> Hi Jerry
> >>>>> Regarding your last point:
> >>>>>
> >>>>>
> >>>>>>> Hannes:
> >>>>>>> Do you think it is awfully realistic for all QNEs to 
> >>>>
> >>>>
> >>>>
> >>>> understand all
> >>>>
> >>>>>>> mandatory parameters? I could imagine that Attila and 
> Georgios 
> >>>>>>> are not going to implement stateless interior QNEs in 
> such a way 
> >>>>>>> that they understand all the mandatory QSPEC 
> parameters. In fact 
> >>>>>>> they don't have todo it since only edge routers are likely to 
> >>>>>>> ever see QoS NSLP messages that contain QOSM IDs that 
> they do not 
> >>>>>>> understand (otherwise something go terribly wrong).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Jerry: It is up the RMD authors to specify how they want RMD
> >>>>>>
> >>>>>>> to behave wrt mandatory parameters (and obtain rough 
> consensus, 
> >>>>>>> of course).  That is, if a mandatory parameter is 
> remapped and 
> >>>>>>> not strictly interpreted, the remapping must be 
> specified in the 
> >>>>>>> QOSM specification document.  Otherwise, the QOSM 
> must strictly 
> >>>>>>> interpret the mandatory parameters that are not 
> remapped, if they 
> >>>>>>> are populated by the QNI.
> >>>>>>> There are no restrictions on how the remapping must 
> be done, it 
> >>>>>>> can be as simple as necessary (but no simpler).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Georgios:
> >>>>> Jerry, I think that the point raised by Hannes is related to
> >>>>> how the QNE's interior to the RMD domain will have to 
> comply to the
> >>>>> mandatory  descriptions specified in the QSPEC template. An 
> >>>>> interior QNE (in RMD-QOSM) will not process the end to 
> end QSpec. 
> >>>>> The only QSpec that will be processed by the interior 
> QNE is the 
> >>>>> RMD Qsepc that is initiated by the ingress node (i.e., 
> QNI for the 
> >>>>> RMD local session). Note that the above observation is 
> valid for 
> >>>>> all local QOSMs.
> >>>>> However, the above is not allowed due to the following 
> text that is 
> >>>>> included in the QSpec template draft:
> >>>>>
> >>>>> "A QNE MUST interpret all mandatory parameters from this 
> >>>>
> >>>>
> >>>>
> >>>> document even
> >>>>
> >>>>> if it does not support the received QoS NSLP message with the 
> >>>>> indicated QOSM."
> >>>>>
> >>>>> Therefore, in my opinion it is required to modify the above 
> >>>>
> >>>>
> >>>>
> >>>> sentence in
> >>>>
> >>>>> something like:
> >>>>>
> >>>>> "A QNE SHOULD interpret all mandatory parameters from this 
> >>>>
> >>>>
> >>>>
> >>>> document even
> >>>>
> >>>>> if it does not support the received QoS NSLP message with the 
> >>>>> indicated QOSM. A QNE that supports a local QOSM, does not 
> >>>>
> >>>>
> >>>>
> >>>> have to interpret
> >>>>
> >>>>> all mandatory parameters carried by a QSpec that was 
> >>>>
> >>>>
> >>>>
> >>>> generated by a QNI
> >>>>
> >>>>> located outside the domain that supports the given local QOSM." 
> >>>>
> >>>>
> >>>>
> >>>> Something along these lines would probably be more 
> realistic, I guess.
> >>>>
> >>>> Ciao
> >>>> Hannes
> >>>>
> >>>>
> >>>>> Best regards,
> >>>>> Georgios
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] Sent: 
> >>>>> maandag 3 juli 2006 2:03
> >>>>> To: Hannes Tschofenig
> >>>>> Cc: Ash, Gerald R (Jerry), ALABS; Attila Báder (IJ/ETH); 
> >>>>
> >>>>
> >>>>
> >>>> [email-masked];
> >>>>
> >>>>> Kappler Cornelia
> >>>>> Subject: RE: [NSIS] draft-qosmodel-controlledload-04
> >>>>>
> >>>>> Hi Hannes,
> >>>>>
> >>>>> See below.
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Hannes Tschofenig [mailto:[email-masked]]
> >>>>>> Sent: Saturday, July 01, 2006 4:26 PM
> >>>>>> To: Ash, Gerald R (Jerry), ALABS
> >>>>>> Cc: [email-masked]
> >>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04
> >>>>>>
> >>>>>> Hi Jerry,
> >>>>>>
> >>>>>> it is true that I haven't read the most recent QSPEC draft 
> >>>>
> >>>>
> >>>>
> >>>> when I sent
> >>>>
> >>>>>> this mail. In the meanwhile I did. Please find a few 
> comments below:
> >>>>>>
> >>>>>> Ash, Gerald R (Jerry), ALABS wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Hi Hannes,
> >>>>>>>
> >>>>>>> See below.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Hannes Tschofenig [mailto:[email-masked]]
> >>>>>>>> Sent: Friday, June 30, 2006 8:43 AM
> >>>>>>>> To: Bernd Schloer
> >>>>>>>> Cc: [email-masked]
> >>>>>>>> Subject: Re: [NSIS] draft-qosmodel-controlledload-04
> >>>>>>>>
> >>>>>>>> Hi Bernd,
> >>>>>>>>
> >>>>>>>> Bernd Schloer wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> the first open issue in the appendix B is about 
> what to do with 
> >>>>>>>>> mandatory QSPEC parameters which are not needed for CLS.
> >>>>>>>>>
> >>>>>>>>> Does a QOSM have to understand (and provide information 
> >>>>
> >>>>
> >>>>
> >>>> about) all
> >>>>
> >>>>>>>>> mandatory parameters, even if they are not used?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I think the question is wrong. What about the 
> following question:
> >>>>>>>> "
> >>>>>>>> Does a node that implements a particular QOSM has to 
> >>>>
> >>>>
> >>>>
> >>>> understand all
> >>>>
> >>>>>>>> mandatory parameters listed in the QSPEC template draft
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> (even if the
> >>>>>>
> >>>>>>
> >>>>>>>> QOSM does not make use of them)?
> >>>>>>>> "
> >>>>>>>> The answer would be "YES" since the QSPEC template draft 
> >>>>
> >>>>
> >>>>
> >>>> says that
> >>>>
> >>>>>>>> mandatory parameters have to be understood by every 
> NSIS QoS node.
> >>>>>>>>
> >>>>>>>> There is only the question what "understands" means.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> IMO you need to more carefully read the QSPEC I-D 
> document.  All 
> >>>>>>> mandatory QSPEC parameters that are populated in the 
> QSPEC must 
> >>>>>>> be interpreted by every QNE, which is explained in 
> the QSPEC I-D:
> >>>>>>>
> >>>>>>> It says in Section 4.4.1 (Mandatory and Optional QSPEC
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> . Parameters) of
> >>>>>>
> >>>>>>
> >>>>>>> the QSPEC I-D
> >>>>>>> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt:
> >>>>>>>
> >>>>>>> "  Mandatory QSPEC parameters are treated as follows:
> >>>>>>>
> >>>>>>>  o A QNI SHOULD populate mandatory QSPEC parameters if
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> .      applicable to
> >>>>>>
> >>>>>>
> >>>>>>>    the underlying QOSM.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I don't understand this sentence. What does it mean that a QNI 
> >>>>>> "SHOULD"
> >>>>>> populate parameters if applicable?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> It means that a QNI is not required to populate all 
> >>>>
> >>>>
> >>>>
> >>>> mandatory parameters.  A
> >>>>
> >>>>> QNI would only populated a mandatory parameter if is used 
> >>>>
> >>>>
> >>>>
> >>>> by the QOSM
> >>>>
> >>>>> supported by the QNI.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>  o QNEs MUST interpret mandatory QSPEC parameters, if 
> signaled."
> >>>>>>>
> >>>>>>> Furthermore, it says in Section 4.2 (QSPEC Processing):
> >>>>>>>
> >>>>>>> "  a QNE
> >>>>>>>  MUST at least interpret all the mandatory parameters 
> in  a QSPEC 
> >>>>>>> even
> >>>>>>>  if it does not support the corresponding QOSM.
> >>>>>>>
> >>>>>>>  Mandatory parameters provide a minimal subset of 
> parameters. A
> >>>>>>>  QNE MUST either a) strictly interpret a mandatory 
> parameter, or
> >>>>>>>  b) remap the parameter and raise the <NON QOSM HOP> flag  
> >>>>>>> defined in
> >>>>>>>  Section 5.1, where the remapping MUST be specified 
> in the QOSM
> >>>>>>>  specification.  Here the terminology 'strictly  
> interpret' means 
> >>>>>>> that
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> What is the difference  between 'strictly interpret' and 
> >>>>
> >>>>
> >>>>
> >>>> 'interpret'?
> >>>>
> >>>>>> In the rest of the document you use 'interpret'.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 'Strictly interpret' is defined in the text I quoted from 
> >>>>
> >>>>
> >>>>
> >>>> Section 4.2 (QSPEC
> >>>>
> >>>>> Processing), which is given again in the very next 
> >>>>
> >>>>
> >>>>
> >>>> sentences I quoted just
> >>>>
> >>>>> below (after you posed your above question :-)
> >>>>>
> >>>>> "   Mandatory parameters provide a minimal subset of 
> parameters. A
> >>>>>   QNE MUST either a) strictly interpret a mandatory 
> parameter, or
> >>>>>   b) remap the parameter and raise the <NON QOSM HOP> flag 
> >>>>
> >>>>
> >>>>
> >>>> defined in
> >>>>
> >>>>>   Section 5.1, where the remapping MUST be specified in the QOSM
> >>>>>   specification.  Here the terminology 'strictly 
> >>>>
> >>>>
> >>>>
> >>>> interpret' means that
> >>>>
> >>>>>   the parameter is implemented according to the 
> commonly accepted
> >>>>>   definition and/or as specified by references given 
> for each QSPEC
> >>>>>   parameter.  This means that in case a), a <Token Bucket> 
> >>>>
> >>>>
> >>>>
> >>>> parameter
> >>>>
> >>>>>   must be strictly interpreted as a token bucket.  
> >>>>
> >>>>
> >>>>
> >>>> However, in case b),
> >>>>
> >>>>>   a <token Bucket> parameter may be remapped, perhaps to a 
> >>>>
> >>>>
> >>>>
> >>>> <Bandwidth>
> >>>>
> >>>>>   parameter."
> >>>>>
> >>>>> In the document, the term 'interpret' a mandatory parameter 
> >>>>
> >>>>
> >>>>
> >>>> means either a)
> >>>>
> >>>>> strictly interpret (as defined above), or b) remap (as 
> >>>>
> >>>>
> >>>>
> >>>> defined above).
> >>>>
> >>>>> Perhaps this can be made clearer in the text.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>  the parameter is implemented according to the 
> commonly accepted
> >>>>>>>  definition and/or as specified by references given for 
> >>>>
> >>>>
> >>>>
> >>>> each QSPEC
> >>>>
> >>>>>>>  parameter.  This means that in case a), a <Token 
> Bucket>  parameter
> >>>>>>>  must be strictly interpreted as a token bucket.   
> However, in 
> >>>>>>> case b),
> >>>>>>>  a <token Bucket> parameter may be remapped, perhaps to a 
> >>>>>>>  <Bandwidth>
> >>>>>>>  parameter.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I noticed this text improvement and I am happy to see more 
> >>>>
> >>>>
> >>>>
> >>>> text about
> >>>>
> >>>>>> it.
> >>>>>>
> >>>>>> Still, I have some issues with the section:
> >>>>>>
> >>>>>> I had a problem with this paragraph following the previous 
> >>>>
> >>>>
> >>>>
> >>>> one in the
> >>>>
> >>>>>> section. The previous paragraph said "
> >>>>>> However, if a QSPEC arrives at a QNE that does
> >>>>>>   not support the QOSM being signaled, it can still 
> understand the
> >>>>>>   QSPEC content, at least to a basic degree.
> >>>>>> "
> >>>>>>
> >>>>>> When I read through the text I got the impression that the two 
> >>>>>> sections relate to each other and in fact they do not. 
> Hence, I 
> >>>>>> suggest to delete the previous paragraph since this one 
> >>>>
> >>>>
> >>>>
> >>>> contains the
> >>>>
> >>>>>> info already.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> I'm unclear as to which paragraph/text you are 
> proposing to delete.
> >>>>>
> >>>>>
> 
> >>>>>
> >>>>>> You
> >>>>>> might also want to delete the second paragraph as well 
> >>>>
> >>>>
> >>>>
> >>>> since it is far
> >>>>
> >>>>>> too obvious to use RFC2119 language: If you don't 
> support even a 
> >>>>>> single QOSM then why are you a QOS NSLP node in the 
> first place.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> I think it important to state that a QNE MUST support at 
> >>>>
> >>>>
> >>>>
> >>>> least one QOSM,
> >>>>
> >>>>> even if this is clearly necessary to effectively support 
> >>>>
> >>>>
> >>>>
> >>>> QoS-NSLP/QSPEC.
> >>>>
> >>>>>
> >>>>>> You might want to highlight the following sentence, though:
> >>>>>>
> >>>>>> "
> >>>>>> A QNE MUST interpret all mandatory parameters from this 
> >>>>
> >>>>
> >>>>
> >>>> document even
> >>>>
> >>>>>> if it does not support the received QoS NSLP message with the 
> >>>>>> indicated QOSM.
> >>>>>> "
> >>>>>>
> >>>>>> Here is my proposal for the section:
> >>>>>>
> >>>>>> "
> >>>>>> 4.2 QSPEC Processing
> >>>>>>
> >>>>>>   The QSPEC is opaque to the QoS NSLP processing.  The 
> >>>>
> >>>>
> >>>>
> >>>> QSPEC control
> >>>>
> >>>>>>   information and the QoS description are interpreted 
> and MAY be
> >>>>>>   modified by the RMF in a QNE (see description in [QoS-SIG]).
> >>>>>>
> >>>>>>   The QSPEC contains a QOSM ID, i.e. information on 
> what   QOSM is 
> >>>>>> being
> >>>>>>   signaled by the QNI.  However, if a QSPEC arrives at a   QNE 
> >>>>>> that does
> >>>>>>   not support the QOSM being signaled, it can still 
> understand the
> >>>>>>   QSPEC content, at least to a basic degree.  This is  
>  because 
> >>>>>> mandatory
> >>>>>>   parameters have been defined as a common language.   
>  Therefore, 
> >>>>>> a QNE
> >>>>>>   MUST at least interpret all the mandatory parameters in a   
> >>>>>> QSPEC even
> >>>>>>   if it does not support the corresponding QOSM.
> >>>>>>
> >>>>>>   A QNE MUST either
> >>>>>>
> >>>>>>   a) interpret a mandatory parameter carried in the QSPEC 
> >>>>
> >>>>
> >>>>
> >>>> object, or
> >>>>
> >>>>>>   b) remap the parameter and raise the <NON QOSM HOP> flag   
> >>>>>> defined in
> >>>>>>   Section 5.1, where the remapping MUST be specified 
> in the QOSM
> >>>>>>   specification.
> >>>>>>
> >>>>>>   Here the terminology 'interpret' means that
> >>>>>>   the parameter is implemented according to the 
> references   given 
> >>>>>> for   each QSPEC parameter.
> >>>>>>
> >>>>>>   If a QSPEC arrives at a QNE that does not support 
> the QOSM being
> >>>>>>   signaled, it can still understand the QSPEC content, at 
> >>>>
> >>>>
> >>>>
> >>>> least to a
> >>>>
> >>>>>>   basic degree. Hence, with case (a), a <Token Bucket> 
> parameter
> >>>>>>   must be strictly interpreted as a token bucket.
> >>>>>>
> >>>>>>   In case b), a <token Bucket> parameter may be remapped,   
> >>>>>> perhaps to a
> >>>>>>   <Bandwidth> parameter.
> >>>>>> "
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> I don't see any benefit in redefining what 'interpret' 
> means in the
> >>>>> document.  As I mentioned above, the document uses the term 
> >>>>
> >>>>
> >>>>
> >>>> 'interpret' to
> >>>>
> >>>>> mean that a mandatory parameter is 'interpreted' if is 
> >>>>
> >>>>
> >>>>
> >>>> either 'strictly
> >>>>
> >>>>> interpreted' or it is 'remapped' (where the remapping must 
> >>>>
> >>>>
> >>>>
> >>>> be defined in the
> >>>>
> >>>>> QOSM specification document).  OTOH, it might be useful 
> to define a
> >>>>> 'remapping' flag to indicated if a mandatory or optional 
> >>>>
> >>>>
> >>>>
> >>>> parameter has been
> >>>>
> >>>>> remapped by a QNE in the path.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Btw, have you noticed that the draft has
> >>>>>> * a <NON QOSM HOP> flag (Section 5.1)
> >>>>>> * a <NON QOSM HOP> parameter (Section 7.2.1)
> >>>>>>
> >>>>>> I think they refer to the same concept...
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Yes, good catch.  <NON QOSM HOP> is indeed intended to be a 
> >>>>
> >>>>
> >>>>
> >>>> flag, and
> >>>>
> >>>>> perhaps one of the QSPEC object flags defined in Section 
> >>>>
> >>>>
> >>>>
> >>>> 7.1 could be used
> >>>>
> >>>>> for this purpose, rather than use a full 32-bit parameter 
> >>>>
> >>>>
> >>>>
> >>>> for this purpose,
> >>>>
> >>>>> as currently specified in Section 7.2.1.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>  In the latter case, the remapping of the <Token Bucket> to
> >>>>>>>  <Bandwidth> must be specified in the QOSM specification 
> >>>>
> >>>>
> >>>>
> >>>> document.
> >>>>
> >>>>>>>  For example, QOSM X exclusively uses the parameter  
> >>>>>>> <Bandwidth>.  It
> >>>>>>>  must define a mapping of the mandatory parameter 
> <Token Bucket>.
> >>>>>>>  The mapping consists of interpreting the Token Bucket Rate as
> >>>>>>>  the <Bandwidth> parameter and disregarding the other 
> >>>>
> >>>>
> >>>>
> >>>> Token Bucket
> >>>>
> >>>>>>>  parameters.  Clearly, some information contained in 
> the <Token
> >>>>>>>  Bucket> parameter is lost by this mapping, and the  
> resulting 
> >>>>>>> QoS may
> >>>>>>>  not be quite what was intended by the QNI.  
> Therefore,  QOSM X also
> >>>>>>>  specifies that the <NON QOSM HOP> flag be raised.  
> Thus,  a QNE 
> >>>>>>> using
> >>>>>>>  QOSM X is able to make an informed decision whether 
> to admit a
> >>>>>>>  reservation described in terms of <Token Bucket>, and 
> >>>>
> >>>>
> >>>>
> >>>> at the same
> >>>>
> >>>>>>>  time (by means of <NON QOSM HOP>) signals to the 
> >>>>
> >>>>
> >>>>
> >>>> QNI/QNR that the
> >>>>
> >>>>>>>  exact intention of the QNI may not be met."
> >>>>>>>
> >>>>>>> I think this text is pretty clear as to what is required 
> >>>>>>> regarding interpreting mandatory parameters.  If not, please 
> >>>>>>> suggest clarifications.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> The text in the new draft has improved a lot.
> >>>>>> Thanks for the update.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> Another possible question would be:
> >>>>>>>> "
> >>>>>>>> Does a node that implements a particular QOSM has to 
> >>>>
> >>>>
> >>>>
> >>>> define mappings
> >>>>
> >>>>>>>> from all mandatory parameters listed in the QSPEC 
> >>>>
> >>>>
> >>>>
> >>>> template draft to
> >>>>
> >>>>>>>> the QOSM draft (even if the QOSM does not make use
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> of them)?
> >>>>>>
> >>>>>>
> >>>>>>>> "
> >>>>>>>>
> >>>>>>>> The answer is "I don't know".
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> A QNE must interpret all mandatory parameters, if 
> populated, as
> >>>>>>> explained in the above text I quoted.  If a QOSM re-maps a 
> >>>>
> >>>>
> >>>>
> >>>> mandatory
> >>>>
> >>>>>>> QSPEC parameter, that re-mapping must be defined in the QOSM
> >>>>>>> specification.  As stated in Section 4.7 (QOSM Specification
> >>>>>>> Requirements):
> >>>>>>>
> >>>>>>> "   A QOSM specification MUST define QSPEC parameter  
> behavior 
> >>>>>>> for these
> >>>>>>>  cases: a) new optional QSPEC parameters the QOSM 
> specification
> >>>>>>>  defines, and b) remapping of existing mandatory or 
> >>>>
> >>>>
> >>>>
> >>>> optional QSPEC
> >>>>
> >>>>>>>  parameters, as described in Section 4.2.  Unless  otherwise 
> >>>>>>> specified
> >>>>>>>  in the QOSM specification document, the behaviors to strictly
> >>>>>>>  interpret the mandatory and optional QSPEC parameters  are 
> >>>>>>> defined in
> >>>>>>>  this document through the references to RFCs that  
> precisely define
> >>>>>>>  the QSPEC parameter behaviors.  A QOSM specification 
> MUST define 
> >>>>>>> how the mandatory  parameters are to
> >>>>>>>  be mapped onto the QSPEC parameters used by the QOSM, 
> >>>>
> >>>>
> >>>>
> >>>> however the
> >>>>
> >>>>>>>  mapping MAY result in slight modification to the intended
> >>>>>>>  specification when an exact mapping is not possible.   This 
> >>>>>>> definition
> >>>>>>>  MUST allow a QNE implementing this QOSM to make a 
> decision as to
> >>>>>>>  whether a reservation described in terms of mandatory  
> >>>>>>> parameters can
> >>>>>>>  be admitted.  If for a particular mandatory parameter no  
> >>>>>>> mapping can
> >>>>>>>  be found that guarantees the desired QoS, the QNE is 
>  advised to 
> >>>>>>> raise
> >>>>>>>  the <NON QOSM HOP> flag.  In other words, for all mandatory
> >>>>>>>  parameters a mapping must be defined, but it is 
> >>>>
> >>>>
> >>>>
> >>>> acknowledged that
> >>>>
> >>>>>>>  this mapping may result in slightly bending the original 
> >>>>>>>  intention of
> >>>>>>>  the QNI."
> >>>>>>>
> >>>>>>> I think this text is pretty clear as to what is 
> required.  If not,
> >>>>>>> please suggest clarifications.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I understood the token bucket to bandwidth example.
> >>>>>>
> >>>>>> Would the RMD draft, for example, list all mandatory 
> parameters 
> >>>>>> and indicate whether it can map them (and how) to 
> parameters used 
> >>>>>> in the RMD specification?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> As stated in the QOSM specification requirements in Section 
> >>>>
> >>>>
> >>>>
> >>>> 4.7, if a QOSM
> >>>>
> >>>>> remaps a mandatory parameter, the remapping must be defined 
> >>>>
> >>>>
> >>>>
> >>>> in the QOSM
> >>>>
> >>>>> specification document.  If no such remapping is defined, 
> >>>>
> >>>>
> >>>>
> >>>> the default
> >>>>
> >>>>> behavior is that the QOSM must strictly interpret the 
> >>>>
> >>>>
> >>>>
> >>>> mandatory parameter,
> >>>>
> >>>>> as defined above.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Do you think it is awfully realistic for all QNEs to 
> understand 
> >>>>>> all mandatory parameters? I could imagine that Attila 
> and Georgios 
> >>>>>> are not going to implement stateless interior QNEs in 
> such a way 
> >>>>>> that they understand all the mandatory QSPEC 
> parameters. In fact 
> >>>>>> they don't have todo it since only edge routers are 
> likely to ever 
> >>>>>> see QoS NSLP messages that contain QOSM IDs that they do not 
> >>>>>> understand (otherwise something go terribly wrong).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> It is up the RMD authors to specify how they want RMD 
> to behave wrt
> >>>>> mandatory parameters (and obtain rough consensus, of 
> >>>>
> >>>>
> >>>>
> >>>> course).  That is, if a
> >>>>
> >>>>> mandatory parameter is remapped and not strictly 
> >>>>
> >>>>
> >>>>
> >>>> interpreted, the remapping
> >>>>
> >>>>> must be specified in the QOSM specification document.  
> >>>>
> >>>>
> >>>>
> >>>> Otherwise, the QOSM
> >>>>
> >>>>> must strictly interpret the mandatory parameters that are 
> >>>>
> >>>>
> >>>>
> >>>> not remapped, if
> >>>>
> >>>>> they are populated by the QNI.
> >>>>>
> >>>>> There are no restrictions on how the remapping must be 
> >>>>
> >>>>
> >>>>
> >>>> done, it can be as
> >>>>
> >>>>> simple as necessary (but no simpler).
> >>>>>
> >>>>> Thanks,
> >>>>> Jerry
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Ciao
> >>>>>> Hannes
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Thanks,
> >>>>>>> Jerry
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Ciao
> >>>>>>>> Hannes
> >>>>>>>>
> >>>>>>>> The QSPEC-draft says in section 5
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> that
> >>>>>>>>> all parameters listed in the next sections are 
> mandatory. The 
> >>>>>>>>> QSPEC-draft also
> >>>>>>>>> says in section 4.1 that "a given QOSM defines which of the 
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> mandatory and
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> optional parameters it uses, ..."
> >>>>>>>>>
> >>>>>>>>> Are there any specific parameters which makes the open 
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> issue B.1.1.
> >>>>>>
> >>>>>>>>> clearer? Following the QSPEC-draft there doesn't seem to be 
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> a conflict,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> if nothing is
> >>>>>>>>> done with the unneeded parameters.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Bernd
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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, 04 Jul 2006 14:04:47 +0200

Hi Hannes,

that would make the QOSM CLS implemantable. I'm not sure about other QOSMs.

Bernd