Subject: Re: model draft comments

From: Jamal Hadi <[email-masked]>
Date: Tue, 21 Jan 2003 19:40:13 -0800

On Tuesday 21 January 2003 12:07, Joel M. Halpern wrote:
[..]

> One could easily imagine a CE taht was smart enough to understand which
FEs
> could and could-not deliver this service given their configuration and
> resource limits.

Or FEs that are capable of rejecting configs ...

>
> Now, a harder case is trying to build a service that involves
> classifying,
> decapsulating, reclassifying, metering, etc.  Clearly, again, this will
> first require that some external logic takes a description of the form
> [deliver service X to users A-C via IPSec from Q] and transform that
> into
> the necessary processing elements.  I do not expect the CE to perform
> taht transform.

I am glad ipsec shows up - it's good to see a digression away from the
dogma of QoS and diffserv and related elements.
Essentially the way i see it is: [deliver service X to users A-C via IPSec
from Q] is a description of a service in a natural language; probaly the
highest layer in the chain but has no place in a forces model. Below it is
a composition of elements which someone/software creates to deliver this
service. This composition of elements is a policy. At the lowest layer is
the per-element description to deliver the policy.
I think the service model is a different problem domain; however, i
certainly see the other two as items that have a role in the model.

I deleted most of what you wrote because i agree with it;
My problem is those two issues which i'll repeat one more time:
1) the fact that qos/diffserv is a subset of the forces model. In other
words  i should be able to use forces (model and protocol) to not only be
able to  express diffserv, but also things like TCP splicing etc. This is
not clear to me, maybe because qos is spoken with reverence around here.

2) the need for the layering i described to be clear.

I would like to move to critiquing the draft itself but i find it hard
without clarity on these two issues.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Jan 2003 13:36:07 -0500

I hope I can clarify these two questions.

On the question of supporting things other than QoS, the only possible
answer is "somewhat".  We will be producing a list of functional blocks for
the model.  We will try to include more than just the diffserv
blocks.  However, There will be things people want to do that we will not
include.  We have to bound the work somewhat.

On the question of layering, I suspect that the problem lies in how people
look at the word policy.  Note that the QPIM and QDDIM models are both
"policy".  However, I am much more comfortable with expecting the CE to
handle a description at the QDDIM level of specificity rather than
expecting it to handle a QPIM level description.  It would not surprise me
if we need to tighten up the text in the model draft in this regard.

We currently do not discuss where a CE fits in the overall conceptual model
of policy management.  We avoid this for many reasons, probably the largest
being that the real practice deviates wildly from theory.  The next largest
is that this is not the forces applicability statement.  That document will
describe where the forces component live in the real network and how they
interact with the rest of the systems.

I hope that this helps you understand the assumptions that the authors have
made to date in working on the draft.

Yours,
Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 23 Jan 2003 01:55:10 -0500

> include.  We have to bound the work somewhat.

"Somewhat" worries me. I believe that line of reasoning is based on the fact
theres some attachment to the QoS model.
Ive attached a small file mostly because the graphics will get mangled if
i send it in the email txt.

I claim i can easily model a diffserv router, and anything else which may
have a FE-CE sort of relationship ranging from bridging, ipv6 forwarding,
ipip tunneling to tcp-splicing etc.
The sample model doesnt care what those actions are, as long as something in
the CE (via the forces protocol) is able to control them and tell them what
to do.
[There is even publicly available code that runs to prove it].

Sure the charter restricts us to go as far as diffserv but it does not say
that QoS is dogma. We should be able to _at least_ express diffserv. I am
fine with building all the minimal blocks needed (forwarding and diffserv)
but not restricting the Forces protocol to have just that capability.
If that is not the goal of Forces then i have been, regretfully, wasting my
time.

Note: i am not saying we cant take advantage of the QoS modeling experiences;
where i have a problem is that Forces modeling (or protocol) becomes QoS
first then squeeze other semantics later - "somewhat".

> if we need to tighten up the text in the model draft in this regard.

Google just told me of QPIM and QDDIM and she wants me to filter the noise -
i promise to read more later; i scanned some slide presentation on QPIM and i
saw the QoS annotations there as well (infact the Q there stands for Qos).

Agreed, it depends on the semantics of "policy" used.
My use of the word "policy" isnt quiet in the spirit of QoS policy management
rather more in relation to the classical OS description of policies and
mechanisms. Policies in the CE tell the individual mechanisms on the FE what
to do.
[It eventually boils down to the same classical meanings but spiced out
differently.]

> interact with the rest of the systems.

I dont think we need to describe where things live in relation to policy
management. I agree thats another ball game.
However, once a policy has been digested into something the CE understands
and can use to configure an FE then that is, IMO, a core component of the
model discusion.  From a modeling perspective, thats well represented by
graphs.

> made to date in working on the draft.

I have just not been comfortable with the assumptions.

cheers,
jamal