Subject: RE: [Diffserv] Model Draft TB?

From: Shahram Davari <[email-masked]>
Date: Thu, 15 Jun 2000 12:14:54 -0700

Bkumar,

I still think it is better for a TB definition in the model draft to be
consistent with other IETF documents and to reflect the real world
implementation. If the model draft defines a TB that has no significant
advantage over a Normal TB, and that no one is going to implement it, then
to me it serves no value. 

You raised a ver good point, which I didn't want to get in my earlier
emails, and that is the granularity: 

Another drawback of the Simple TB (Negative TB) is its granularity. Assume
that you have a Simple TB of depth B=1 byte (can go to "-MTU"). So the MBS =
MTU. Basically you can't pass even small bursts << MBS if they consist of
more than one packet, through this Simple TB. Or in other words the
granularity of metering is not fine enough.

Regards,
-Shahram     

>-----Original Message-----
>From: Brijesh Kumar [mailto:[email-masked]]
>Sent: Thursday, June 15, 2000 1:19 PM
>To: 'Shahram Davari'; [email-masked]
>Subject: RE: [Diffserv] Model Draft TB?
>
>
>Hi Sharam,
>
>I think you have a very valid point. Having said that, it is important
>to note that  the real behaviour of TB depends on how one implements
>it - no matter how the model draft defines it. I too couldn't figure
>out why the model defined it differently, but it is not a big thing
>for us. To me, the major critical factor is the granularity at which
>the TB is implemented. But, you did raise a good question.
>
>Cheers,
>
>--brijesh
>Ennovate Networks Inc.
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]On Behalf
>> Of Shahram Davari
>> Sent: Thursday, June 15, 2000 12:08 PM
>> To: [email-masked]'
>> Subject: [Diffserv] Model Draft TB?
>>
>>
>> Hi,
>>
>> Could the authors of Model draft please explain the following:
>>
>> The Diffserv Model draft proposes a Simple TB model, in
>> which, the Token
>> count can go negative up to "- MTU", and won't accept any
>> packet while the
>> token count is negative.
>>
>> As far as I can see the only difference that this model has
>> compared to a
>> Normal TB (i.e., the one that can't go negative) is that in a
>> Normal TB,
>> large packets are punished after a set of small packets
>> consume the tokens.
>> While in the Simple TB, small packets are punished after a
>> large packet
>> consumes the tokens and causing negative token count.
>>
>> If we consider the fact that the majority of the Internet
>> traffic consists
>> of small packets (40% are ~40 byte, specially TCP control
>> packets). I would
>> say that the Normal TB is the preferred one. On the other hand RFCs
>> 2697,2698, 2211, 2212 , ATM and FR policers all are
>> implemented using Normal
>> TB.
>>
>> 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.
>>
>> Regards,
>>
>> Shahram Davari
>> Systems Engineer
>> Product Research
>> PMC-Sierra, Inc. (Ottawa)
>> 555 Legget drive,
>> Suit 834, Tower B,
>> Ottawa, ON K2K 2X3, Canada
>> Phone: +1 (613) 271-4018
>> Fax  : +1 (613) 271-7007
>>
>>
>>
>> _______________________________________________
>> 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/
>

_______________________________________________
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: Tue, 20 Jun 2000 14:42:48 -0700

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.

---

From: "gravey" <[email-masked]>
Date: Fri, 23 Jun 2000 10:20:51 +0200

this is documented in the last version of I.371 concerning GFR. A public
paper by Herbert Heiss, QoS results for the GFR ATM service, in ITC'16,
1999, also documents the issue

It has nothing to do with TCP.

The following example explains the phenomenum: consider a packet stream that
alternates short and long packets.
assume also that you have two TBs with different max sizes maxTB1<maxB2
You can build an example where the short packet is not accepted by TB1, and
the large packet is then accepted. At the same time, the short packet would
be accepted by TB1, which would stop the large packet from being accepted.

Although the above example is not very realistic, it shows something which
is indeed a problem.
the following result is also given: if maxTB2>maxTB1+max_packet_size, this
does not happen.

annie

-----Message d'origine-----
De : Fred Baker [ mailto:[email-masked]]
Envoyé : mercredi 21 juin 2000 18:18
À : [email-masked]
Cc : 'Shahram Davari'; [email-masked]
Objet : RE: [Diffserv] Model Draft TB?

At 02:31 PM 6/21/00 +0200, gravey wrote:
>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.

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.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 29 Jun 2000 09:03:48 -0700

Hi Fred,

Sorry that I could not reply earlier. Here are my responses:

>From: Fred Baker [mailto:[email-masked]]
>Sent: Tuesday, June 20, 2000 5:43 PM
>To: Shahram Davari
>Cc: [email-masked]'
>Subject: Re: [Diffserv] Model Draft TB?
>
>
>You are complaining that this TB description differs from that 
>in ATM. 

My main concersn is not ATM. I am more concerned about IETF documents
themselves, which are not consistent. As you know RFC 2697, 2698, 2211, 2212
are not using negative TB and they work very well.

In 
>  - he can set the TB variable to zero and take the rest of 

Why are you talking about two stage TB. Let's talk about a single stage
Token bucket. In a single stage token bucket, after receiving a packet, with
a size that is greater than the TB count, you have only two choices:

1) subtract the size of the packet from the TB count and leave the 
TB count negative. (in this case you are hopping that no packets would
arrive till the TB count goes to positive).

2) If there is not enough token just declare the packet as non-conformant.
(in this case you are hopping that you would have enough tokens for the next
packets)

Both of these approaches work fine. They have however, some differences:

A) The second approach is more in favor of smaller packets. Which I think
seems logical for the Internet, because majority of the Internet traffic,
specially TCP control packets consists of short packets. 

B) The first approach is more in favor of larger packets. In that sense it
could cause many small packets that arrive after a large packet to be deemed
as non-compliant, and this could trigger multiple TCP flow back off.

C) The first approach has granularity problem. For example if I want to set
my Max burst size to "MTU", which probably is true for EF, then I need to
set the TB size to "one" byte. Now the TB can't accept any back to back
packets. Because when the TB goes negative it won't accept any other packet
until it comes back to positive.

>make them happy. I'm designing this so that it will work 

We should not design it for ATM Forum or ITU. we should design it for IP.
But we should design it with valid data, and valid justification and be
consistent to other IETF documents and standards.

Regards,
-Shahram