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

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Jun 2000 11:42:04 -0500

Jamal, if people choose to ignore the disclaimer at the beginning of
the document, and use it as an implementation blueprint, there's
not much we can do about it.

  Brian

jamal wrote:
> 
> On Wed, 31 May 2000, Andrew Smith wrote:
> 
> > 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.
> > ...
> 
> 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?
> 
> > 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.
> 
> 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

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

---

From: Andrew Smith <[email-masked]>
Date: Thu, 1 Jun 2000 11:59:19 -0700

Again, you are reading more into the diagram than what is on the page. My
opinions are reflected in the current draft (not surprisingly!).

Andrew

> Sent: Wednesday, May 31, 2000 7:11 PM
> To: Andrew Smith
> Cc: [email-masked]
> Subject: RE: [Diffserv] Comment on model draft-03
> 
> 
> 
>