Subject: RE: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt (o n Metering)

From: Sylvain Gingras <[email-masked]>
Date: Mon, 4 Dec 2000 11:43:25 -0800

Regarding the discussion of the 'loose' and 'strict' token buckets, I was also
surprised at the unexplained and gradual shift away from the conventional 'strict' 
token bucket policer in the latest versions of the text.  
 
With all due respect to the authors who produced an admirable draft, I do seem to
perceive a certain bias (intentional or not) in the presentation of the two models.  
This is particularly apparent in the discussion and definitions of token buckets in Appendix A.
 
1) Statements such as "Some find the behavior of a 'loose' token bucket unacceptable, as
it is significantly different than the token bucket description for ATM and for Frame Relay"
belittle the reasoning of those who may prefer the 'strict' model as being simply based on
unwillingness to accept a model that is different to what they are used to in ATM and Frame Relay.
I presume that the people referred to don't "find the behavior of a 'loose' token bucket unacceptable,
but rather are thinking of applications where the 'strict' token bucket is more convenient for some
reasons.
 
Such reasons, which should be mentioned, include the fact that bits cannot be borrowed beyond
the capacity of real-life buffers and beyond the bandwidth of real-life links.  And therefore,
in some applications (eg: when the policed flows must be aggregated and satisfy the
constraints of a given buffer size and link rate) it may be more appropriate to use the 'strict' model
with appropriately configured parameters rather than using the 'loose' model and having 
difficulties in setting the parameters in a way that guarantees that the buffer space won't be exceeded
(eg: if all the policed flows are heavily borrowing at the same time). 
In such a case, the 'burst-size' parameter of the 'loose' policer may require to be set so small 
that the policer becomes unfair to small packets who don't get to benefit from the significant 
'borrowing capacity' that the larger packets enjoy.
 
2) The text goes on to list "three characteristics" [read flaws] "which are important to keep
in mind".  The first two of those take half a page to tell us the obvious and well known
requirement that the bucket size must be set to a value greater than MTU.
A single sentence saying so would save time and keep the focus on the real issues.
 
It should be noted that the same argument applies in a similar way to the 'loose' 
model when the burst-size is set to 1 bit.  In this case the natural jitter in the network
also conspires against the algorithm, as a packet arriving slightly earlier than it should
is rejected due to the token count not having yet reached the positive territory.
In fact, a more meaningful comparison of the two models would compare them
when the 'bucket-size' parameter of the 'strict' model is configured to have MTU tokens
above that of the corresponding parameter of the 'loose' model.
 
3) As for the third characteristic, I fail to see why this one would not apply to the 'loose'
model.  The fact that the 'loose' model provides a greater 'burst tolerance' for the same
value of the 'bucket-size' parameter doesn't change much to the fact that a policing scheme
is only reasonable when the policed flow is being shaped by some means which attempts
to satisfy it's conformance requirements (by the use of a shaper or some feedback mechanism,
such as that of TCP).  As I see it, the difference in 'burst tolerance' between the two models
are in the order of a single MTU, so I would much appreciate a more insightful description of 
why the loose model is more appropriate for 'TCP'.

Despite the above criticism, I do however agree that the 'loose' model may provide some
advantages in certain implementations.  Diff-Serv'ers may be interested in looking at the
the following laid-open Patent Application :
    Kathleen Nichols, Nortel Networks, "Method and Apparatus for Providing Differentiated Services"
    Patent No: WO0030307  
for a good example of how the 'loose' model can be used to elegantly implement a meter-shaper
(email me if you want a copy).

Sincerely,
 
Sylvain Gingras
Senior Product Development Engineer
PMC-Sierra Inc.
Burnaby, BC

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: fm-listproc <[email-masked]>
Date: Mon, 4 Dec 2000 15:51:02 -0500 (EST)

Sylvain,

J'aimerais une copie du brevet de Mme Nichols,

-=Francois=-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2000 10:48:23 -0600

I should say more or less what I've said to Shahram in private:

I believe (without checking the archive) that we changed this 
around in response to a clear majority view, knowing that some
people disagree, but the IETF works by rough consensus. When we 
last call the document we by definition check the consensus 
and then we will see. We can't re-debate every point of disagreement 
on every draft.

   Brian

> token bucket policer in the latest versions of the text.
...