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

From: Shahram Davari <[email-masked]>
Date: Tue, 30 May 2000 14:00:52 -0700

Hi,

One of the reasons for having ingress queuing is for the switch fabrics that
support virtual output queues (VOQ). 

Regards,
-Shahram

>-----Original Message-----
>From: Brijesh Kumar [mailto:[email-masked]]
>Sent: Tuesday, May 30, 2000 3:34 PM
>To: [email-masked]
>Subject: [Diffserv] Some comments on Diff-Serve Conceptual 
>Model Draft 3
>
>
>
>This is kind of a strange draft whose usefulness seems only 
>marginal to me
>(rationale for MIB definitions - do we really need one?). It 
>may  have been
>useful at some point, but at this point, there isn't any thing 
>that is not
>already covered in Diff-Serv Arch document, or the MIB draft or the QoS
>policy draft. It would have been more useful it has provided 
>more useful
>guidelines for implementation rather than shying away from the 
>core issue.
>
>Any way, here are some other comments, that I jotted down 
>while having a
>look at this draft.
>
>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.).
>
>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).
>
>3. Classifiers
>
>"Note that we allow a multiplexer before the classifier (see 
>section 6.5 ..)
>...." The section 5. Well, it's not the question of this 
>document allowing
>or disallowing, that is the way many (software) 
>implementations that have a
>centralized routing for merged traffic streams will implement. 
>Therefore, a
>classifier can be visualized either as a 1 to N mapping, or a 
>M to N mapping
>of traffic streams. In reality, multiplexing is a result of an 
>action (i.e.,
>common ingress queueing) as all incoming traffic is written to a single
>classifier input queue. The similar arguments apply to a (conceptual)
>multiplexer preceding a meter.
>
>4. Counting doesn't seem to be a valid action - it is kind of 
>useless to say
>that if the traffic stream meets this criteria, then count, or 
>if it doesn't
>meet this criteria then don't count. Gathering traffic statistics, is
>auto-magically implied in any network switch with or without Diff-Serv.
>
>
>Cheers,
>
>--brijesh
>Ennovate Networks Inc.
>
>
>_______________________________________________
>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: Andrew Smith <[email-masked]>
Date: Tue, 30 May 2000 15:18:51 -0700

Brijesh,

Please see below.

> Sent: Tuesday, May 30, 2000 2:37 PM
> To: 'Brian E Carpenter'
> Cc: [email-masked]
> Subject: RE: [Diffserv] Some comments on Diff-Serve Conceptual Model
> Draft 3
> 
> 
> 
> In his previous mail, Brian Carpenter writes
> 
> > >
> > > other infinite possible theoretical variations. There is
> > only one object
> > > called Dropper which may drop as per the algorithm chosen
> > from the set of
> > Linguistically I tend to agree.
> Brian,
> 
> I am glad that you agree. I hope the authors will re-consider 
> their use of
> multiple Dropper objects (Absolute and Algorithmic) which, I think, is
> unnecessary.

I, for one, am reluctant to re-open that discussion. This was one of the
(few) items that we closed in Adelaide.

...
> 
> > > 3. Classifiers
> > >
> > > "Note that we allow a multiplexer before the classifier
> > (see section 6.5 ..)
> > > centralized routing for merged traffic streams will
> > implement. Therefore, a
> > > classifier can be visualized either as a 1 to N mapping, or
> > a M to N mapping
> > > of traffic streams. In reality, multiplexing is a result of
> > an action (i.e.,
> > Are you proposing a document change?
> 
> I hope the authors will consider it.

Let us see your proposed changes and of course we will consider them.

> > > 4. Counting doesn't seem to be a valid action - it is kind
> > of useless to say
> > > that if the traffic stream meets this criteria, then count,
> > or if it doesn't
> > This is included as a basis for the corresponding MIB variables.
> 
> What I wanted to convey that the existence of a count action object by
> itself is meaningless. In a Diff-Serv context, an action will 
> always be
> "Count and Drop" or "Count and Forward" combination (i.e., 
> (1) Drop with
> Count or (2) Forward with Count).

It is not clear to me whether you are suggesting that we (a) do not include
any counters in this management model, (b) we rename them from "count
actions" to something without the word action in the name or (c) we define a
new element called a "forwarder" just so that we can have some counters in
it. Up to now, the consensus has been that it is useful to include counters
explicitly. I assume that the 3 other co-authors also believe so.

> Ennovate Networks Inc.,

Andrew