Subject: On unified QoS policy model

From: Yoram Ramberg <[email-masked]>
Date: Tue, 19 Dec 2000 07:41:59 +0200

Dear esteemed modeling gurus,

Having almost fully recovered from my jet lag, I'm doing some rethinking on 
some of the issues that came up in the San Diego meeting. One thing that's 
stuck in my mind and may be worth commenting on (surely among many 
others...) is the comments made by Yoram Barnet about unified QoS policy 
modeling (my term - I think he would call it 'modular QoS policy 
modeling'). I have to say that I'm quite taken by Yoram's approach. Kindly 
humor me for a few paragraphs as I'm engaged in on-line rumination here...

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. QDDIM (at its current form) is an attempt to take the 
next step past the DiffServ "informal model" and formalize it. It is a 
DiffServ information model. Nothing wrong with this, IMO. Some may claim 
that this positions QDDIM outside the scope of the W'G's charter but I 
won't go into this argument now. The rest of this memo deals with QPIM 
only. Furthermore, when I say 'QPIM' I'm referring to the narrow scope of 
QoS -- not the parts of QPIM that are offered now as extension for PCIM. 
While there are interesting implications to other modeling efforts such as 
ICIM (the IPSP work) and MPLS, I'll restrict myself to QoS as an 
independent discipline, artificial though this approach might seem. It's a 
convenient, narrow scope.

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

Regardless of the control path constructs used in a given policy system, 
says Yoram, a scheduler may still have to be configure and admission 
control may still have to be imposed. Yoram gives some compelling examples 
that I won't repeat here.

What does it all say about the WG work? Quite a bit, IMO. In particular, 
this is a critique of the approach taken by QPIM as a "high level"  QoS 
policy model. 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...) as part of the same policy system but still as 
distinct constructs. It is the wrong "modularization", as Barnet puts it. 
Take, for instance, the construct called PR action (qosPolicyPRAction). 
This is a conglomeration of a set of parameters to configure several data 
path constructs. I suppose this fits well with the DS MIB. 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. Barnet claims (not in so many words) that this 
is a modeling mistake that may cost us in the future (I'll leave the 
detailed argument to Yoram as he fathered it).

Does this mean that QPIM should not include a PR action or and RSVP action? 
I don't necessarily think so. 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. It is a matter of 
"modularization", right?

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. 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. Do I wish 
Yoram had made his enlightening comments on these issues before? I do.

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