Subject: RE: [Diffserv] Comment on model draft-03

From: Andrew Smith <[email-masked]>
Date: Wed, 31 May 2000 17:21:03 -0700

See below.

> -----Original Message-----
> From: jamal [mailto:[email-masked]]
> Sent: Wednesday, May 31, 2000 5:29 AM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: [Diffserv] Comment on model draft-03
...
> There has to be a deeper meaning than this which is not 
> clearly elaborated in the text.
> The question is: do you ever foresee an implementation which does not
> do stats like the packet/byte counters (incoming/outgoing/dropped
> etc) such that you end up needing this luxury of choosing not to do
> stat collection? 

One person's "luxury" is another's "cattle class". I think you're trying to
impose your value judgements here on economic reality.
...
> I should have been more specific:
> with the abovce scheme you periodically sample the queue and 
> compute the
> RED paramaters offline on the control plane (as in not in the data
> path). I refer to this as out of band. Some other scheme might compute
> things per packet on the data path; this would be inband. 

I think you're reading too much into figure 5 and section 7.1.3. I don't
know where you are getting "periodically sample", "offline" or "control
plane" from here. What you describe asn in- or out-of-band sounds very much
like implementation specifics, not a general model.

Andrew

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

---

From: jamal <[email-masked]>
Date: Wed, 31 May 2000 22:11:19 -0400 (EDT)

> impose your value judgements here on economic reality.

hehe. Someone else's "cattle class" is the main reason we are having
all these discusions in the first place. Relax.

What is your opinion this, really?

> like implementation specifics, not a general model.

I might be but lets review the evidence in question ;-> 

           +------------------+      +-----------+
           | +-------+        |  n   |smoothing  |
           | |trigger|<----------/---|function(s)|
           | |calc.  |        |      |(optional) |
           | +-------+        |      +-----------+
           |     |            |          ^
           |     v            |          |Depth
  Input    | +-------+ no     |      ------------+   to Scheduler
  ---------->|discard|-------------->    |x|x|x|x|------->
           | |   ?   |        |      ------------+
           | +-------+        |           FIFO
           |    |yes          |
           |  | | |           |
           |  | v | count +   |
           |  +---+ bit-bucket|
           +------------------+
           Algorithmic
           Dropper

The data path is where the input comes into the discard box, out to the
queue and finally scheduled out of the queue.

What i see above is some smoothing function taking its input from the
queue aka "sampling the queue";  i dont see this being kicked by the
arrival of the packet, so naturally i assumed there's probably
a time trigger associated aka "periodicity"; 
The trigger calculation has its input from the smoothing function
and feeds the discard box. 
Given the above representation it would be very rational to assume
that the trigger and smoothing functionality are running somewhere off the
data path ("offline") and logically that would be in the "control
plane"

If you gave me this diagram, this is how i would have implemented (as
am sure a lot of others will). So there is an implementation
specific-ation attached ;->
I would need a lot more information to deduce that the trigger calculation
and the smoothing function would be along the fast path. Unless the excuse
is that the diagram would look rather ugly ;-> 

cheers,
jamal