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

---

From: [email-masked]
Date: Tue, 12 Dec 2000 17:07:20 -0500

Yoram,

Thanks for sending this clarification.  I think you are right in that we
collectively need to understand the linkages better, between rsvp/intserv
and diffserv, from the perspective of policy.

Thanks again,

Ed Ellesson

[email-masked]
Office at Tivoli:  919-224-2111
Office at home:  919-644-3977

---

From: "Robert Moore" <[email-masked]>
Date: Thu, 14 Dec 2000 10:59:04 -0500

Yoram,

Speaking just for myself, i.e., not for the other
QDDIM authors, I think you have described more
accurately than we did the reduction of scope we
intended when we moved from QDIM to QDDIM.
I know, for example, that we said things like
"Let's just focus on the data path elements, and
finish them."

Obviously there's more to it than this, but I think
that we should move immediately to a more accurate
full title for QDDIM, QoS Device Datapath Information
Model, when we produce the -03 draft.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

"Yoram Bernet" <[email-masked]>@raleigh.ibm.com on
12/12/2000 01:23:36 PM

Please respond to "Yoram Bernet" <[email-masked]>

Sent by:  [email-masked]

To:   <[email-masked]>
cc:
Subject:  Clarification of comments made during yesterday's WG meeting

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

Classification
Metering
Dropping
Marking
Queuing

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:

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.

---

From: "Yoram Bernet" <[email-masked]>
Date: Mon, 18 Dec 2000 08:03:58 -0800

Bob:

I think that your suggestion regarding focusing on the datapath elements
is valid. But - I think that first, we need to sketch out the high level
'modules' and to keep that modularization in mind while pursuing the
datapath elements. This doesn't have to be a painful or drawn out
effort. I think that we understand pretty well what the modules are:

1. Datapath stuff.
2. Provisioning and configuration stuff (which includes signaling and
admission control).

The scope of the modules should also be made clear wrt the various
underlying QoS technologies:

Datapath stuff is equally applicable to diffserv and the kind of traffic
handling that is traditionally (yet erroneously) associated with
RSVP/Intserv. In other words - datapath stuff is equally applicable to
aggregate and per-flow traffic handling.

Provisioning and configuration (including signaling and explicit
admission control) include COPS and RSVP (among others) and are
applicable both to intserv and to diffserv. The various mechanisms can
be applied to configure the various datapath elements. The goal of the
provisioning and configuration mechanisms is to configure the datapath
elements in a cohesive manner across a network. 

I would like to see this message captured somewhere, loud and clear. It
could be kept short and inserted in the introduction to the QDDIM (and
related drafts). Or - it could be made part of a policy framework draft.
It doesn't necessarily need more words than offered here, but it might
benefit from a few paragraphs of elaboration and some examples. 

Yoram

> -----Original Message-----
> From: Robert Moore [mailto:[email-masked]]
> Sent: Thursday, December 14, 2000 7:59 AM
> To: Yoram Bernet
> Cc: [email-masked]
> Subject: Re: Clarification of comments made during yesterday's WG
> meeting
> 
> 
> Yoram,
>