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

As long as an implementer is able to leave with the dual token bucket 
spec, that is enough for me. If I need to choose, I'd typically take the 
simpler approach of two options, and would remove the Bp, but I don't 
have a strong opinion either way.

If no one really objects, we'll just keep the Bp since it is has been in 
the spec for quite some time.

Jukka

Gerald Ash wrote:
> 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 /<[email protected]>/* wrote:
> 
> 
>     From: Gerald Ash <[email protected]>
>     Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07
>     To: "NSIS" <[email protected]>, "Al Morton" <[email protected]>
>     Cc: "Jerry Ash" <[email protected]>, "Magnus Westerlund"
>     <[email protected]>,
>     [email protected]
>     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 /<[email protected]>/* wrote:
> 
> 
>         From: Al Morton <[email protected]>
>         Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07
>         To: "Magnus Westerlund" <[email protected]>,
>         [email protected], "NSIS" <[email protected]>
>         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
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320 (Otakaari 5A)
P.O. Box 3000, FIN-02015 TKK      E-mail: [email protected]
Finland                           WWW:    www.comnet.tkk.fi