Subject: Clarification of comments made during yesterday's WG meeting

From: "Yoram Bernet" <[email-masked]>
Date: Tue, 12 Dec 2000 10:23:36 -0800

At the end of yesterday's meeting, Ed paraphrased my comments. I think
that my comments were not clearly understood. I will attempt to clarify:

The fundamental issue is one of modularization. Policy is such an
overwhelming 'blob' to tackle - as a result, the authors of QDDIM and
QPIM are tackling the effort picemeal. This makes sense. I am not
calling for all pieces of the QoS policy puzzle to be tackled at once.
What i'm calling for is very careful modularization. As I commented
yesterday on the list, the modulariztion in QDDIM strikes me as wrong.
QDDIM repeatedly states that it is tacking the DiffServ module in this
pass and will tackle the IntServ model in the next pass. QPIM talks
about the RSVP part versus the DiffServ part. In QPIM, the two are
pretty much separated, except for the brief part about using RSVP to
return DCLASS objects (whihc are DiffServ related).

In my opinion, the modularization should be one of datapath mechanisms
versus control mechanisms. Datapath mechanisms include:

Classification 
Metering
Dropping
Marking
Queuing

These are neither IntServ nor DiffServ - they are equally applicable to
both. They are more generic than IntServ or DiffServ. 

Control mechanisms configure the datapath mechanisms. They include:

SNMP
COPS
RSVP
Others...

Datapath and control mechanisms interact. For example - when a DiffServ
network provider provisions an EF service instance between ingress point
A and egress point B, it's necessary to verify that resources are
available along the path from A to B and to install the appropriate
policers to assure that the EF service is not abused. This requires
interaction between some policy agents and the queuing and
classification mechanisms in at least some of the network elements along
the path from A to B. Part of this interaction involves admission
control (are there sufficient resources to support the SLA? can the new
service be provisioned without violating other SLAs?), part of it
amounts to configuring policers. Similarly, when an RSVP request arrives
at a PEP/PDP, it is necessary to apply admission control, and then to
configure policers and queuing in accordance with the admission control
decision. 

So - IMHO, the drafts should identify the two types of mechanisms and
the types of interaction between them. They may then choose to tackle
one set or the other set at this time, with the remainder to be tackled
later. However - they should not draw distinctions between IntServ
*versus* DiffServ, nor between DiffServ *versus* RSVP. This distinction
is misleading and short sighted. Just consider that RSVP can be used for
admission control to and configuration of DiffServ traffic handling
mechanisms just as it can be used for admission to and control of
microflow (per 5-tuple) traffic handling mechanisms. Consider that a
single end-to-end path may offer aggregate traffic handling (diffserv)
in certain devices and per-flow traffic handling (traditionally
associated with intserv) in other devices.

In summary, a full service QoS network should be able to make use of
per-flow traffic handling, aggregate traffic handling, relatively static
'push' provisioning and configuration mechanisms and the more dynamic
RSVP signaling configuration mechanism *all in the same network*. Policy
should focus on how these interact seamlessly, thereby uniting them. As
the drafts carve out pieces to tackle, these interactions should be
noted and similar pieces should be tackled in the same draft. 

This is a difficult message to convey - it's somewhat abstract. So -
here's a concrete example of what happens when we artificially separate
RSVP/IntServ from DiffServ:

***************** Example*******************

Consider how COPS/RSVP and COPS/PR are used between PEPs and PDPs:

COPS/RSVP:
* An RSVP message arrives at a PEP. It is a request for resources that
specifies the type of service desired, the amount of traffic for which
this service is required and the classification information by which the
traffic can be recognized.
* The PDP makes an admission control decision.
* If the request is admitted, then the PDP tells the PEP that the
request is admitted. 
* Now the PEP configures: 1. a microflow classifier corresponding to the
5-tuple in the RSVP message 2. a policer corresponding to the tspec in
the RSVP message 3. the appropriate queuing to provide the service
approved (2 and 3 are closely related).

COPS/PR:
* A PEP needs to be configured to support a certain SLA for certain
traffic.
* The PDP must check with the PEP to be sure that it can accommodate
the SLA (admission control decision is made)
* If the SLA can be supported, the PDP configures in the PEP: 1. a
classifier (potentially microflow) corresponding to the customer traffic
stream to recieve the diffserv service per the SLA. 2. a policer to
protect the diffserv network and possibly to protect one subset of the
customer's traffic from another. 3. the appropriate queuing in the same
or in subsequent PEPs. 

Note that in both cases, there is a need to configure classifiers,
policers and queuing mechanisms in PEPs. In the first case, the PDP does
so indirectly (by admitting the RSVP request). In the second case, it
does so directly. However, in both cases - the result is to consume
resources from the same interfaces. It would have been much simpler if
the work of COPS was separated into 1. responding to provisioning and
configuration requests (whetehr they arrvie by RSVP or by administrative
control) and 2. configuring traffic handling mechanisms. In that case,
the COPS/RSVP example would have the PDP directly configuring the
traffic handling mechanisms in response to the RSVP message, just as it
does in the COPS/PR case. There is overlap between COPS/PR and COPS/RSVP
that is related to an artificial distinction between RSVP/IntServ and
DiffServ.
***********************************************