Subject: RE: [Diffserv] (No Subject)

From: Andrew Smith <[email-masked]>
Date: Fri, 26 May 2000 16:36:27 -0700

Actually, the relevant drafts from the RAP working group are:
http://www.ietf.org/internet-drafts/draft-ietf-rap-pr-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-00.txt

For some tutorial paterial you might also look at the IETF proceedings,
starting from http://www.ietf.org/proceedings/directory.html. You will find
several slide presentations about COPS-PR under the RAP WG there.

Thanks,

Andrew Smith
RAP WG co-chair

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, May 25, 2000 11:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Diffserv] (No Subject)
> 
> 
> draft-ietf-diffserv-pib-00.txt is the only related document 
> in diffserv.
> 
> draft-ietf-rap-cops-ds is also relevant (not sure of the 
> latest version number).
> 
>   Brian
> 
> Xavier Lopez-Murtra wrote:
> > 
> > I would like to know in which drafts or RFC's
> > can I find information about the utilization
> > of COPS protocol in DS domains. Thank you very
> > much.
> > 
> > Angelfire for your free web-based e-mail. http://www.angelfire.com
> > 
> > _______________________________________________
> > 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/
> 

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

---

From: "Brijesh Kumar" <[email-masked]>
Date: Tue, 30 May 2000 15:33:58 -0400

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 May 2000 15:29:29 -0500

> guidelines for implementation rather than shying away from the core issue.

Well, the WG decided it wanted such a document. One of the main reasons is
to help ensure consistency between the MIB, the PIB and the higher level
policy definitions, by providing a common reference nodel.

> possible N algorithms (tail drop, head drop, ..RED etc.).

Linguistically I tend to agree.

> classifiers and meters? Figure (1 & 2).

True, there is no rationale. But again, this is what the WG wanted.

> multiplexer preceding a meter.

Are you proposing a document change?

> auto-magically implied in any network switch with or without Diff-Serv.

This is included as a basis for the corresponding MIB variables.

   Brian

---

From: "Brijesh Kumar" <[email-masked]>
Date: Tue, 30 May 2000 17:37:14 -0400

In his previous mail, Brian Carpenter writes

> 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.

> True, there is no rationale. But again, this is what the WG wanted.

If the model doesn't explain why an object exists in a model, and its
rationale for existence, then, at least to me, it is like a protocol state
machine which has a state that cannot be reached from any other state. It is
fine with me if others don't see it that way.

> Are you proposing a document change?

I hope the authors will consider it.

> 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).

Cheers,

--brijesh
Ennovate Networks Inc.,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 May 2000 14:33:10 -0500

> multiple Dropper objects (Absolute and Algorithmic) which, I think, is

That's not quite what I meant. I meant that personally I don't like
the choice of word "absolute" - "unconditional" would be better IMHO.
But there is a difference between an absolute dropper and an
algorithmic dropper. (Well, OK, an absolute dropper is an
algorithmic dropper whose algorithm is TRUE, but that's a very
formal approach. It's much more intuitive to distinguish the two.)

   Brian