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

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

_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis