Subject: RE: [Diffserv] Model Draft TB?

From: "gravey" <[email-masked]>
Date: Wed, 21 Jun 2000 14:31:09 +0200

Hi

designing a TB for packets with varying size has also been addressed in ATM,
for the conformance definition used in Guaranteed Frame Rate (GFR).
And the problems that have been identified are similar to the ones listed
here.

In ATM, the constraints were as follows :
1) the decision (accept, drop or tag packet) is taken when the packet enters
the system (i.e. the TB), on the basis of the number of available tokens,
and of the negotiated maximum frame size
2) complete information concerning the length of the packet is  known only
when the last cell of the frame is received

The case leading to negative values of TB for GFR in ATM is the following:
1) a packet is accepted under the assumption that its length is compatible
with TB (i.e. the number of available tokens is above an agreed limit).
2) however the actual length of the packet is larger than expected (in ATM,
this may happen if the user sends frames that exceed an agreed Maximum Frame
Size)

However, this is probably not a major problem. And if the IP packet size is
known when the packet accesses the TB, this problem is even not relevant for
IP.

What is still relevant, is that the amount of traffic that is accepted
varies over time, depending on the dynamic contents of the TB. But this
should be taken into account when allocating resources (resource allocation
SHOULD take account of the traffic that can be filtered by a TB, and CANNOT
rely on smooth traffic unless a shaper is appended to the TB).

other problems have been identified in ITU concerning TBs for streams with
variable packet size, which are more important. These are related to the
amount of traffic that is accepted by the TB, depending on the
characteristics of the traffic and on the characteristics of the TB
mechanism. For example,  increasing the bucket size of a TB (with fixed
token rate) may lead to accepting LESS TRAFFIC (in terms of bits) than the
TB with a smaller bucket size, unless the increase is large enough.

I hope this helps in designing a good TB spec for IP.

Annie

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]]De la part
de Fred Baker
Envoyé : mardi 20 juin 2000 23:43
À : Shahram Davari
Cc : [email-masked]'
Objet : Re: [Diffserv] Model Draft TB?

You are complaining that this TB description differs from that in ATM. In
ATM, there is a single cell size, so the current TB depth is always greater
than or equal to zero. If one is smart enough to specify TB burst sizes in
cell-sized units, all calculations are exact. If one isn't that smart, one
has the same problem I propose here, and ATM's TB definition is problematic
in operational reality.

IP has variable length packets. This leaves an implementor with a dilemma.
When the amount of bandwidth left in the token bucket is positive but less
than the size of the packet being operated on, he must do one of three
things:

  - he can subtract the whole size of the packet from the bucket, leaving it
   negative, remembering to *add* the token bucket size to the TB variable
   rather than simply setting it full, and so potentially putting more than
   the token bucket size into this token bucket interval and less into the
   next token bucket interval but making the average amount per token
   bucket interval equal to the TB specification.

  - he can leave the amount alone and go on to the next color and threshold
   and see if he can fit it there, remembering to *add* the token bucket
   size to the TB variable rather than simply setting it full, and so
   potentially putting less than the token bucket size into this token
   bucket interval and more into the next token bucket interval but making
   the average amount per token bucket interval equal to the TB
   specification.

  - he can set the TB variable to zero and take the rest of the packet size
   out of the next color.

One thing that he cannot to is exactly fit the TB burst size specification
with random sized packets.

So, pick one.

   - The first will always work, with a per-interval variance of one MTU.

   - The second has a bug. If you configure the TB specification smaller
    than the MTU, it is possible to get into a situation where no traffic
    ever matches the specification. You can fix this by not allowing such
    a configuration. But the effect is the same - the average burst allowed
    is as specified, but individual bursts may be larger or smaller by one
MTU.

   - The third gives you incorrect operation (you can't color half the
packet
    one color and the other half another).

None of the options gives you ATM behavior. So slavishly parroting the ATM
TB model is not consistent with IP reality.

I picked the first (I originated the first incarnation of that bit of text,
or at least the concept it presents). If you want to argue for another,
present your case. If you want this discussion in the model draft, Andrew
can no doubt adapt this text.

>So if there no strong reason, I highly recommend changing the Simple TB to
a
>Normal TB to be consistent with other IETF RFCs and ATM and FR and most
>probably ITU.

With all due respect to ATM and the ITU, I for one am not designing this to
make them happy. I'm designing this so that it will work correctly in an IP
world.

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Fred Baker <[email-masked]>
Date: Wed, 21 Jun 2000 09:18:22 -0700

At 02:31 PM 6/21/00 +0200, gravey wrote:
>For example,  increasing the bucket size of a TB (with fixed

Can you provide a pointer to that? I'm guessing that if this is measuring 
TCP with long data flows, it may work that way because the interval (bucket 
size/token rate) approaches a value which is significantly out of tune with 
the particular TCP stream's RTT.