[NSIS] Dual Token Bucket Requirements -- Re: AD review of draft-ietf-nsis-y1541-qosm-07

[Gerald Ash <[e-mail]>]

All,
 
The draft http://www.ietf.org/id/draft-ietf-nsis-y1541-qosm-07.txt currently requires a dual token bucket and peak bucket size parameter (Rp) be specified.  However, in expired draft http://tools.ietf.org/id/draft-vaananen-mpls-svc-diff-framework-00.txt, it says:
 
" - Three color marker based service [RFC 2697, RFC 2698]: Here the
   customerÆs traffic is marked with one of three colors (using a dual
   token bucket scheme) and the packets marked with each color are
   guaranteed a certain maximum loss probability. Practically this
   could mean that packets conforming to committed rate specification
   have better delivery guarantee than those that exceed it."
 
Since the QSPEC draft (http://www.ietf.org/id/draft-ietf-nsis-qspec-22.txt) currently provides 2 TMOD parameters to accommodate the 3-color marker based service, it appears that a dual token bucket capability is already provided by the QSPEC and there is no further need to specify the Rp parameter in the Y.1541-QOSM draft.  It would be up to an individual QOSM specification to detail the use of the 2 TMOD parameters to achieve a dual token bucket.
 
Comments?
 
Thanks,
Jerry 


--- On Fri, 11/13/09, Gerald Ash <[e-mail]> wrote:


From: Gerald Ash <[e-mail]>
Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07
To: "NSIS" <[e-mail]>, "Al Morton" <[e-mail]>
Cc: "Jerry Ash" <[e-mail]>, "Magnus Westerlund" <[e-mail]>, [e-mail]
Date: Friday, November 13, 2009, 5:30 PM







I wasn't aware that Al Morton was taking this question to the list, so I would like to clarify the points I'm making regarding the dual token bucket parameter Bp:
 
1. The basis for including the parameter Bp is the ITU-T Recommendation "Signaling Requirements for IP-QoS" (available at http://www.itu.int/rec/T-REC-Q.Sup51/en), which REQUIRES the dual token bucket parameters (including Bp) for QoS signaling.  IMO if the the ITU doesn't want to require a dual token bucket for QoS signaling, they should revise the requirements.  Perhaps co-authors of the ITU-T QoS signaling requirements could comment.
 
2. Magnus only asked for a definition of Bp, which is readily available.  Magnus made no claim that Bp was too complex or any suggestion that the parameter should be removed.  But rather than simply providing the definition as requested, Al Morton has now decided that Bp is too complex and should be removed.
 
3. The intent of the Y.1541-QOSM document is to specify an NSIS QoS model (QOSM) based on all QoS signaling requirements contained in ITU-T recommendations, not only the Y.1541 QoS classes, but also the Q.Sup51 traffic model (TMOD) signaling requirements, and restoration priority signaling requirements.
 
Thanks,
Jerry 

--- On Fri, 11/13/09, Al Morton <[e-mail]> wrote:


From: Al Morton <[e-mail]>
Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07
To: "Magnus Westerlund" <[e-mail]>, [e-mail], "NSIS" <[e-mail]>
Date: Friday, November 13, 2009, 2:54 PM


NSIS WG,

At 08:47 AM 10/16/2009, Magnus Westerlund wrote:
>3. Section 3.1: What are the definitions of the Bp and M parameter?

Those of us who have discussed Magnus' comment above are
trying to agree on a path forward.

Both parameters have standard definitions:
A reference definition for M, max datagram size, is in RFC 2212.
ITU-T Y.1221 seems to be the only standard where Bp,
the peak Bucket Size of a dual token bucket is specified.

I have proposed removing Bp because the additional complexity
of a dual token bucket is not essential to the main subject
of the draft (the Y.1541 classes).
I have asked at this week's ITU-T meeting, and the only implementors
of ITU-T Y.1221 indicated that they were not using Bp,
only the parameters for a single token bucket.

Jerry Ash would like to retain Bp, citing the informational
ITU-T Supplement referenced in the draft, and indicated that
dual token buckets are well-established and non-controversial.

Others have asked me to phrase the question to the list.
So, with the above background, should we simplify and drop Bp,
or keep it in?

thanks and regards,
Al