Re: AD evaluation comments on draft-ietf-nsis-rmd-15

Hi Jerry

Thanks!
Okay, we will use the suggestion that Magnus and you proposed!
The RMD-QOSM will require the RMD-QOSM TMOD-1 sub-parameters to be
defined such that they are equivalent to peak bandwidth and that the 
RMD QNE interior nodes parse peak bandwidth (p) out of TMOD-1.


Best regards,
Georgios

On 2/28/2010, "Gerald Ash" <[email protected]> wrote:

>Magnus,
>Georgios,
> 
>I agree with Magnus that peak bandwidth can simply be parsed from the TMOD-1 parameter by RMD-QOSM QNEs; it is less complicated than having both a TMOD-1 parameter and a separate/redundant <bandwidth> parameter.
>
>Regarding the history, the <bandwidth> parameter was eliminated in QSPEC version-13 http://tools.ietf.org/html/draft-ietf-nsis-qspec-13.  Version-13 made several changes to the QSPEC (when Dave Oran joined as co-author); these changes were fully discussed at IETF-67 and afterward on the list.  The changes that eliminated <bandwidth> are covered in QSPEC slide 5  http://www.ietf.org/proceedings/67/slides/nsis-7/sld5.htm  and slide 8 http://www.ietf.org/proceedings/67/slides/nsis-7/sld8.htm.  The minutes are given at http://www.ietf.org/proceedings/67/minutes/nsis.txt (no discussion noted of eliminating <bandwidth> parameter).  
> 
>QSPEC version-13 changes are summarized on list at http://www.ietf.org/mail-archive/web/nsis/current/msg07325.html, noting the following points:
> 
>"  o source traffic description (mandatory to include by QNI &
>    mandatory to interpret by downstream QNEs)
>    > specified by traffic model (TMOD-1) parameter consisting of
>      rate (r), bucket size (b), peak rate (p), minimum policed unit
>     (m) (mathematically complete way to describe traffic source)
>    > bandwidth only set r=p; b/m to large values (separate
>      bandwidth parameter not needed)"
> 
>" o eliminated:
>    > Bandwidth
>    > Ctot, Dtot, Csum, Dsum"
>
>" o local QSPEC must be consistent with initiator QSPEC
>    > e.g., RMD can initiate a local QSPEC that contains TMOD =
>      bandwidth (sets r=p, b/m to large)"
> 
>There were no objections to these changes on the list; in particular, no discussion of eliminating the <bandwidth> parameter.
> 
>Again, the TMOD-1 parameter must be included in the QSPEC and must be interpreted by all QNEs.  The RMD-QOSM can require the TMOD-1 sub-parameters to be defined to be equivalent to peak bandwidth and/or for RMD QNEs to parse peak bandwidth (p) out of TMOD-1.  This is straightforward enough.
> 
>I agree with Magnus that if RMD specifies a new <bandwidth> parameter that supplants the TMOD-1 parameter, then this would make RMD-QOSM non-compliant with NSLP/QSPEC and that would have to be noted.  However, I see no reason to go in that direction.  
> 
>Thanks,
>Jerry
>
>--- On Sun, 2/28/10, Magnus Westerlund <[email protected]> wrote:
>
>
>From: Magnus Westerlund <[email protected]>
>Subject: Re: updated version rmd-qosm draft
>To: "Georgios Karagiannis" <[email protected]>
>Cc: "[email protected]" <[email protected]>, "Lars Westberg" <[email protected]>, "Attila Báder" <[email protected]>
>Date: Sunday, February 28, 2010, 3:18 PM
>
>
>Hi Georgios,
>
>I asked you to take this discussion to the list. I do understand some of
>the history here. However, the document was not explicit about this
>issue. Also I don't know the timing of this RMD discussion in relation
>to QoS documents. So RMD has a non-compliancy in regards to the NSLP QoS
>and QSPEC. That needs to be explicitly mentioned in the document.
>
>What I don't understand is why it would be more complicated to read a
>single parameter from the standard QSPEC TMOD rather than a new
>parameter in the QSPEC. If a interior node is RMD only it can just as
>well read a single parameter from the QSPEC as this RMD specific ones.
>
>Cheers
>
>Magnus
>
>
>
>
>      )