Subject: [Diffserv] draft-ietf-diffserv-model-01.txt

From: Kathleen Nichols <[email-masked]>
Date: Fri, 05 Nov 1999 12:45:15 -0800

Mostly I thought this was a good document and I think
the upfront statement "It is not intended as a guide to hardware
implementation." means that one can take a fairly relaxed
view on some of the stickier points. However, I have some
points to bring up, a few of which are possibly "nits", but
it would be nice to know what other folks think.

1. A minor terminology nit. The term "mirror" seems a
a bit strange to me since you seem to be defining a packet
replication function. It seems like "replicator" would be
more descriptive, but perhaps there is some other justification
behind the choice of "mirror"?

2. The definition of "monitor" is an element that only counts up or
increments; don't you think it might sometime need to count down?
For example, monitoring a queue size?

3. The definition of TCB seems to need work. In the definitions, you
say: 

"A logical datapath element consisting of a number of
other functional datapath elements interconnected in
such a way as to perform a specific set of traffic
conditioning functions on an incoming traffic stream.
A TCB can be thought of as a "black box" with a single
input and output."

and in section 8. you say:
"The classifiers, meters, action elements, and queueing elements
described above can be combined into traffic conditioning blocks
(TCBs).  The TCB is an abstraction of a functional element that may
be used to facilitate the definition of specific traffic conditioning
functionality."

So, I believe the notion is to use the TCB to allow one to define
some grouping of diffserv primitives, possibly with a specific
set of settings for some of their parameters, so that it is
later possible to just refer to that TCB and to just configure
the parameters of it that have been externalized, thus simplifying
configuration. So, the TCB is not an "element" in the same sense
you use that word for diffserv primitives. It is an abstraction, 
allowing you to build up a hierarchy more "cleanly". This is
fine, it just needs to be cleaned up in your text. I also rather
take issue with calling it "black box": when I was in engineering
school, a black box was used to refer to something where you
don't know what's inside it and characterize it by the input-
output relationship. A TCB is actually the opposite, you know
what's in it, you're just chosing to ignore that detail. You
say a "logical datapath element" - I'd suggest perhaps a "logical
datapah entity".

4. Figure 1 and the RSVP-optional box. In diffserv, we have
not made any limitation on what kind of "QoS agent" configures
the diffserv-specific forwarding path primitives. I would
be much more comfortable with a model that showed that there
has to be some functional block that does this and then you
might say, "for example, one could use RSVP to do this as...."

5. Section 4.3 is about considerations for an MPLS router in
doing diffserv classification. This is not a strong objection,
but my feeling is that the MPLS working group should be
defing such functionality in their documents and perhaps
be refering to this document and saying how they differ.
After all, we could specify "other flavors" each time one
came up.

6. Section 7 talks about queue sets and scheduling and does
not mention the CSC PHB group defined in rfc2474. This should
probably be corrected.

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

---

From: Steve Blake <[email-masked]>
Date: Fri, 05 Nov 1999 16:37:25 -0500

> behind the choice of "mirror"?

Well, someone asked that mirroring be incorporated in the model.
I agree with the need of a better term.

> For example, monitoring a queue size?

As of now this function is assumed to be performed in the enqueueing
element (another term in need of a better replacement IMO).  This could
be considered a parameter of a queue as well.

> the parameters of it that have been externalized, thus simplifying

Right.

> say a "logical datapath element" - I'd suggest perhaps a "logical

Ok.

> might say, "for example, one could use RSVP to do this as...."

Well, I think my co-authors might object, so I will let them argue that
point.  :)

> After all, we could specify "other flavors" each time one

This draft takes a pretty liberal view about what bits one could classify
to invoke Diffserv functionality, and IMO MPLS labels fits right into that
set, which is why they were added to Sec. 4.  The intent was only to fold
LSRs into the family of Diffserv routers, without specifying the details.

> not mention the CSC PHB group defined in rfc2474. This should

Ok, but what queue parameters are implied by the definition of the class
selectors?  I don't think any additional ones are, but I will add the
reference.

Thanks for the feedback,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake                  <[email-masked]>
Ericsson IP Infrastructure             (919)468-8466 x232

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Nov 1999 17:02:28 -0600

Steve Blake wrote:
...
> Well, I think my co-authors might object, so I will let them argue that

Kathie is absolutely right. As Yoram knows, I've had my doubts about
this part of the model for a long time, and Kathie has articulated
why. The optional box is some sort of QOS manager, which might
be RSVP based or (in at least one product I could mention) might
not be.

   Brian

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 05 Nov 1999 15:38:58 -0800

But I do want to point out that I have no problems (I think) with
including most of the text about using RSVP, but it needs to be
done as an *example* of *one way* to configure or implement the
box's QoS agent/manager.

	Kathie

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 07 Nov 1999 06:18:13 -0600

No disagreement with that.

  Brian