Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model Draf t 3

From: Andrew Smith <[email-masked]>
Date: Tue, 30 May 2000 16:22:52 -0700

"Absolute      A functional datapath element which simply discards all
   Dropper       packets arriving at its input.

   Algorithmic   A functional datapath element which selectively discards 
   Dropper       packets that arrive at its input, based on a discarding 
                 algorithm. It has one data input and one output."

Their different plumbing is the primary reason for treating them
differently. This draft is for building plumbing diagrams.

Andrew

> -----Original Message-----
> From: Grenville Armitage [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2000 4:22 PM
> To: Andrew Smith
> Cc: [email-masked]
> Subject: Re: [Diffserv] Some comments on Diff-Serve Conceptual Model
> Draft 3
> 
> 
> 
> Consistency is one thing, conciseness is another. I'm suggesting
> that the Absolute dropper is merely an instance of an Algorithmic
> dropper (with an algorithm of 'always drop'). Other readers are going
> to notice (or believe they've noticed) the same thing, and wonder why
> 'we' created two different names. To forestall confusion, yes you
> probably ought to define the two terms (and their differences) at
> the front of the document.
> 
> cheers,
> gja
> 
> Andrew Smith wrote:
> > 
> > I think it is well enough described in the Conceptual Model 
> draft. Should we
> > maybe place it in UPPERCASE PRINT (or even in upside-down 
> print since we
> > agreed it dahn-unda)? Seriously though, we could make the 
> definitions more
> > prominent by placing them in the Glossary section up front. 
> I really don't
> > think any more radical restructuring than that is needed.
> > 
> > Andrew
> > 
> > P.S. I need one of those quote-of-the-day things that comes 
> up with some
> > deep and meaningful philosophy from Marx or Confucius about 
> all taxonomies
> > and glossaries being arbitrary - but that that does not 
> matter as long as
> > everyone uses the same ones.
> > 
> > > -----Original Message-----
> > > From: Grenville Armitage [mailto:[email-masked]]
> > > Sent: Tuesday, May 30, 2000 3:31 PM
> > > To: Andrew Smith
> > > Cc: [email-masked]
> > > Subject: Re: [Diffserv] Some comments on Diff-Serve 
> Conceptual Model
> > > Draft 3
> > >
> > >
> > >
> > >
> > > Andrew Smith wrote:
> > >       [..]
> > > > Maybe you missed the discussion in Adelaide: the consensus
> > > there seemed to
> > > > be to use the terms "absolute dropper" for what you
> > > describe above and
> > > > "algorithmic dropper" for anything that makes a decision
> > > based on some sort
> > > > of external inputs (e.g. a queue length). It's a somewhat
> > > arbitrary choice
> > > > but we need to pick a terminology and this was declared 
> the winner.
> > >
> > > Now I'm a little confused. I thought a dropper always derived its
> > > drop/no-drop decision based on additional inputs (e.g. a 
> queue length
> > > or metering stage output). Not that I'm particularly 
> opposed to having
> > > two types of 'dropper', just curious if there's any better
> > > phrasing that
> > > would avoid this discussion recurring after the I-D 
> becomes an RFC.
> > > (Somehow show that an 'absolute' dropper isn't simply a particular
> > > instance of an 'algorithmic' dropper.)
> > >
> > > cheers,
> > > gja
> > >
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> -- 
> ______________________________________________________________
> __________
> Grenville Armitage                    
> http://members.home.net/garmitage/
> Bell Labs Research Silicon Valley
> 

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

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 31 May 2000 00:43:53 +0100 (BST)

>    Dropper       packets arriving at its input.

functional? I prefer 'dysfunctional'.

L.

prefers 'uncontrolled dropper' and 'controlled dropper' for these, too.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 30 May 2000 17:03:24 -0700

>                  algorithm. It has one data input and one output."

Perhaps I'm being dense, but wouldn't the Algorithmic dropper
be better described as having *two* inputs - one data, and one control?
(the control input being the external variable(s) upon which the
algorithm makes the drop decision)

> differently. This draft is for building plumbing diagrams.

Understand the desire to build plumbing diagrams - guess I'd
just prefer there to be less 'functional elements' if it is possible
to use parameters to control functional elements. Yes, I should have
been more awake during the preceding discussions on this topic :)

cheers,
gja

p.s. but if there's any chance to revisit it - how about:

  DROP(F) is a functional datapath element that discards packets
          arriving at its input if F==1, otherwise passes packets
          through if F==0.

An 'absolute dropper' would be just DROP(1), an algorithmic RED
dropper on queue X could be expressed as DROP(RED(X)), etc....

---

From: "Brijesh Kumar" <[email-masked]>
Date: Wed, 31 May 2000 11:23:56 -0400

> dropper on queue X could be expressed as DROP(RED(X)), etc....

You nicely explained it.

This is exactly the way I have internally documented here except that in my
case F=0 (means no control algorithm defined than drop it - which is an
instance of always drop), else apply Drop Algorithm F(X) whatever it is.
Either way is OK.

Why define a new class for an object, when the new object is nothing, but an
instance of an existing class. That is the way I see it.

Cheers,

--brijesh
Ennovate Networks Inc.