Subject: RE: On unified QoS policy model

From: "Yoram Bernet" <[email-masked]>
Date: Tue, 19 Dec 2000 15:00:00 -0800

Yoram:

Thanks for your comments. I think that I mostly agree with you. My
comments follow below...

> Yoram talks about two drafts in particular: QPIM and QDDIM. 
> Even though 
> Yoram criticized QDDIM for the explicit DiffServ-only scope 
> it spans (and 
> for which an extra 'D' had been added to the document's 
> title), I think his 
> critique of QDDIM is unduly harsh. The Barnet argument can 
> actually be used 
> to justify QDDIM's DiffServ-only approach as long as it is explicitly 
> stated, which it is. 

I fear that I have been misunderstood... I did not criticize it for
limiting its scope. In fact, I acknowledged the need to limit scope and
I fully support doing so. However, I questioned the 'definition' of the
scope. The scope is defined as 'diffserv', as opposed to 'intserv'. I
think that the scope is actually right, but the words defining the scope
strike me as wrong. I think that the draft talks about datapath
elements. That is an appropriate scope. These elements are equally
useful to insterv as they are to diffserv, as currently defined in the
draft. Therefore, the draft should not say "this is about diffserv and
not about intserv", but possibly: "this is about datapath elements
equally applicable to intserv as to diffserv.  Similarly, a useful and
complete policy model for diffserv must address issues of explicit
admission control. (Without doing so, it's impossible to support high
quality services without significant overprovisioning). Discussion of
admission control is absent in this draft, so - it doesn't provide a
complete model for diffserv. My claim is that - in some ways, this draft
defines more than diffserv and in some ways, less than diffserv. What it
defines is useful and is a resonable piece to chew off, but it's not
'diffserv'. All i'm saying is that that needs to be noted, up front.
And, as you questioned later in the mail, I do believe that in this case
(as in the case of QPIM) the issue is more than one of elegance, but
that it gets at the very heart of the model and will have repercussions
later if it's not clearly understood up front. More on this below.

> 
> To recap and interpret the Barnet argument: Yoram expressed a concern 
> regarding the artificial distinction between IntServ and 
> DiffServ in the 
> various documents. In his comments (spoken and written) he 
> points out that 
> the correct distinction is between data path and control path 
> constructs. 
> Data path constructs are those which effect (or operate on) 
> the *objects* 
> of policy, e.g. micro and/or aggregate flows. Control path 
> constructs are 
> those which are used to configure the data path constructs, 
> e.g. COPS, 
> RSVP, etc..

and SNMP and CLI - important to include these because they represent a
(generally) more static approach to provisioning and configuration of
the datapath elements, whereas COPS/RSVP and RSVP represent more dynamic
approaches. 

(I'm using the term 'constructs' because it is 
> still "clean" 
> enough and has no problematic connotation. Saying 'class' or 
> 'mechanism', 
> for example, might imply inaccurate context).
> 

What was done in QPIM is an attempt to model 
> DiffServ and 
> IntServ (the latter is not distinguished from RSVP, an interesting 
> discussion all by itself...)

Indeed. I have been the target of many a tongue lashing by esteeemed
gurus, that this distinction must be made. I must say that - I have come
to support this myself. IntServ and RSVP are very different things -
related, but different. 

However, 
> "policing" and "shaping" are not necessarily the exclusive domain of 
> DiffServ. In particular, these are useful concepts when 
> specifying how to 
> treat data flowing through the network. But this treatment may be 
> configured as a result of an RSVP RESV signal as well as result of 
> provisioned DiffServ policy. 

Exactly.

> Does this mean that QPIM should not include a PR action or 
> and RSVP action? 
> I don't necessarily think so. 

I agree. If you want the scope of QPIM to address PR actions and RSVP
actions, by all means - do so, but - these should be clearly identified
as similar actions that act on a common set of datapath elements. 

Policy systems may wish to 
> allow their users 
> to specify control path constructs, data path constructs and 
> inter-associate them as part of the policy specification. A 
> certain policy 
> instance may contain specification for the markers, shapers, 
> droppers, 
> schedulers, etc. and also the control path constructs such as 
> PR actions 
> and/or RSVP actions that may clump them together as a 
> "control" action. Say 
> a PDP responds to a user command by reading the data path 
> construct for a 
> set of PEPs (roles come to play here) and use COPS to 
> configure those PEPs 
> (how nice we're mapped to the PIB...). A PEP may also respond 
> to an RSVP 
> signal by consulting a PDP and, based on a PDP response, 
> configure the very 
> same elements using the very same policers, etc. 

Yes - I agree completely.

> Can we live with current QPIM (or the next revision thereof)? 
> Probably, but 
> I really think that some work should be done to manifest the 
> elegance and 
> clarity that the Barnet approach preaches.

Thanks. I'm honored.

 I'm not sure how 
> much work this 
> entails but I want to find out. Is it merely a matter of 
> elegance? Barnet 
> says it is not. I hereby request Yoram to clarify his point 
> regarding the 
> future price we may incur for not using his unified approach. 

Did you see my example of how COPS/PR and COPS/RSVP overlap (posted at
the end of my last mail on this)? It suggests that we arrived at
COPS/RSVP by focusing on RSVP and that we arrived at COPS for PR by
focusing on DiffServ. The result is kind of confusing. Admitting a
COPS/RSVP request results in actions that affect the very same datapath
elements that a COPS/PR command impact. But doing it via COPS/RSVP is
implicit, while doing it by COPS/PR is explicit. I think that this
raises all sorts of interesting questions such as - "where is the
accounting of the datapath resources actually kept (because both
approaches impact the resource availability)? Is this a sufficiently
clear example of what results? If not, we can discuss further. But -
this is one obvious example that i'd like to get common understanding on
before proceeding.

> Do I wish 
> Yoram had made his enlightening comments on these issues before? I do.

I did - in Adleaide and before, though with less vigor :-)...

> 
> I most certainly expect to be severely flamed for this note, 
> either for 
> missing the point altogether, being wrong on the issues 
> themselves or, at 
> an extreme, for discombobulating the work processes of the 
> WG. Still, I'd 
> rather be flamed than ignored...
> 
> Cheers,
> *Yoram
> 
Cheers
the other Yoram

---

From: Andrew Smith <[email-masked]>
Date: Tue, 19 Dec 2000 21:37:40 -0800

I think we're onto an important issue with this thread and I'd fully support 
work along the lines outlined by these Yorams (seems like there are 2 out of 3 
of the Yorams in agreement :-)).

If the current scope of modelling work has to be limited (which I guess is 
necessary just to stop the whole thing from getting out of hand) then I think 
I'd rather see the scope of the current piece of work focus on the data plane 
model, one that includes Intserv as well as Diffserv data planes, and leave the 
"admission control" modelling (for IS and DS) for later.

BTW, Yoram B. and several others having been making this "grand unified theory 
of QoS" argument for quite a while now - maybe it's the first time in this WG 
though.

<WARNING: infocommercial follows> Yoram B. is probably too modest to mention it 
but there is quite a lot of argument in favour of this approach explained in 
gory detail in his new book "Networking QoS and Windows Operating Systems" (New 
Riders) - I'd highly recommend it as background reading material for this WG 
work item (don't worry - it doesn't mention W*****s until about page 500 :-) - 
most of the book is generically about the IETF QoS work).

Andrew

> Thanks for your comments. I think that I mostly agree with you. My
...