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

From: Andrew Smith <[email-masked]>
Date: Tue, 30 May 2000 14:50:02 -0700

Brijesh,

On your detailed points 1 and 2 (Brian answered 3 and 4):

> -----Original Message-----
> From: Brijesh Kumar [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2000 12:34 PM
> To: [email-masked]
> Subject: [Diffserv] Some comments on Diff-Serve Conceptual 
> Model Draft 3
...
> 
> 1. What is an Absolute Dropper? Till recently, I thought a 
> Dropper was a
> Dropper. Either you drop a packet (and free the memory), or 
> you forward it
> and put on the queue. Let us not get into tail drop versus 
> head drop or
> other infinite possible theoretical variations. There is only 
> one object
> called Dropper which may drop as per the algorithm chosen 
> from the set of
> possible N algorithms (tail drop, head drop, ..RED etc.).

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.

> 2. Egress and ingress interfaces - despite the number of 
> pages, the document
> doesn't explain the rationale for ingress queueing, and egress based
> classifiers and meters? Figure (1 & 2).

That is what Fred's material (originally in the MIB draft, now transplanted
to the Model section 3.2 because it is generally applicable) is talking
about: it explains the requirement to model the same things on ingress as on
egress, at least for management purposes. 

BTW, which pages would you like to see left out?

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  [email-masked]
****************************************************************

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

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 30 May 2000 15:31:08 -0700

Andrew Smith wrote:
	[..]
> 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