Subject: Re: Guaranteed Service Specifications, RFC 2212

From: EMMANUEL DESMET DD9/F <[email-masked]>
Date: Tue, 26 Jan 1999 17:36:56 +0200 (MET-DST)

>Mukul,
Roch,

>As stated in the RFC the peak rate is part of the TSpec definition
>which is used for conformance checking (see p. 10).
>
But it seems to me that this peak rate is not subject to any policing
(i.e., only a single token bucket with parameters r and b), so how can
network elements reliably account for this peak rate parameter p?
 
>In addition, the peak rate allows you to compute tighter end-to-end
>delay bounds and buffer requirements at network elements, e.g., see p.
>3 of the RFC and p. 16 (in the section on guideline to implementors).
>
Or have I actually overlooked something?

>Roch
Emmanuel

---

From: Roch Guerin <[email-masked]>
Date: Tue, 26 Jan 1999 15:43:26 -0500

Emmanuel,

On p. 10 of the rfc it says:

   The token bucket and peak rate parameters require that traffic MUST
   obey the rule that over all time periods, the amount of data sent
   cannot exceed M+min[pT, rT+b-M], where r and b are the token bucket
   parameters, M is the maximum datagram size, and T is the length of
   the time period (note that when p is infinite this reduces to the
   standard token bucket requirement).  For the purposes of this
   accounting, links MUST count datagrams which are smaller than the
   minimum policing unit to be of size m.  Datagrams which arrive at an
   element and cause a violation of the the M+min[pT, rT+b-M] bound are
   considered non-conformant.

That is all you need to determine conformance.  Now, if you were to
implement checking for conformance or policing, then you may want to
have two LB in series, one for the peak rate and one for the token rate,
but that's beyond the scope of the specs.

Roch

---

From: EMMANUEL DESMET DD9/F <[email-masked]>
Date: Wed, 27 Jan 1999 09:14:43 +0200 (MET-DST)

Roch,

>have two LB in series, one for the peak rate and one for the token
>rate, but that's beyond the scope of the specs.
>
Thanks for this very comprehensive response.

Emmanuel