Subject: Re: model draft comments

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 20 Jan 2003 21:35:56 -0800

Hi Alan,

One clarification before I reply, I was looking at model-01 draft
and section 5 does not have item 10. do you mean section 4.3.2 ?

Thanks
Hormuzd
-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Monday, January 20, 2003 10:39 AM

> However, the protocol
> should facilitate this, to be done by any app on the CE in a standard way.
> And the FE model is one way of expressing these caps. Is there any
specific
> text in the draft which you think could be reworded or causes this
> understanding ?

  My main is section 5, item 10.  I agree that the FE's must provide
topology information to the CE, but I'm unclear as to what kind of
topology information is required.

  e.g.  "This FE implements the DiffServ model" is a topology
description, which would appear to satisfy the requirements.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 21 Jan 2003 09:48:50 -0500

> and section 5 does not have item 10. do you mean section 4.3.2 ?

  Sorry.  I meant the requirements document, section 5, item 10.

  My comments were not that the requirments document had to be revised,
but that the model document should make it clear how it will satisfy
those requirements.  Simply saying "we represent a graph topology and
the CE interprets it" is insufficient for me to understand how it's
supposed to work.

  Alan DeKok.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 21 Jan 2003 04:08:44 -0500

Why is Hormuzd doing all the responding on behalf of the model draft's
authors? Occasionaly Joel appears, you pose a question to him then he
disappears.
I think we should kill the current model draft and start a new one perhaps
with new authors. I honestly see no point in discussing it at all if the
authors dont bother to participate.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jan 2003 11:11:03 -0500

I will presume that you did not intend to be rude.
The reason I have stopped responding to most of your questions is that
although two of you are raising issues, I have not been able to understand
the issues.  I have tried several times.
I and other author's have tried to explain the reasoning in the document.

You are certainly free to write an internet draft that takes the
perspective you think is helpful.  Such a draft might allow others in the
working group to understand what problem you are trying to raise.  We might
decide that yours was a better direction.

However, I can not see throwing away the current draft without having a
working group accepted alternative in hand.

Yours,
Joel M. Halpern

---

From: Alan DeKok <[email-masked]>
Date: Tue, 21 Jan 2003 11:48:10 -0500

"Joel M. Halpern" wrote:
> the issues.

  I mostly agree with the current model draft.  I've said so previously
on the list.  What I disagree with are the extensions to that draft
which have been discussed recently.

  e.g. The draft talks about FE topology, but does *not* say how you
would build a network device which uses that topology to handle
arbitrary network traffic.  Yet discussions on the list show that some
people think that step is easy.

  Call me dumb, but I don't understand how that would work.  I think
it's hard.  And as justification for that opinion, I have not yet seen
*any* explanation on the list as to how that would be done.  There have
just been assertions that it's not hard.  That's not a way to achieve
consensus.

  Saying that we can implement the diffserv model and have a CE
understand that topology doesn't help.  I already know that we can
hand-code applications for any network protocol or polocy.

  I want to know how we can automate the process of a CE configuring
network policy.  I've been told it's easy, but I haven't been told why.

> decide that yours was a better direction.

 A short description of my opinion follows, as an analogy to the OSI
seven layer model.  It's not perfect, but it gives a glimpse of where my
issues lie.

 ForCES as an OSI 7 layer model

1) Physical

  We have Physical FE's on a forwarding plane.

2) Data link

  The PFE's do error checking on their physical connections.

3) Network layer.

  The PFE's are configured in some kind of network on the forwarding
plane.

4) Transport layer

  The CE has some connection to the PFE's, to manage & configure them

5) Session layer

  The CE manages how the FE deals with session information.  (e.g. TCP
accelerators, stateful firewalls, etc)

6) Presentation layer

  Management of data encapsulation (ipsec, etc)

7) Application layer

  The CE interacts with other devices on the network to act as a
network-aware device.

  e.g. BGP, Diffserv, etc.

  My belief is that most everything up to layer 5 is well understood.
Layer 6 is a little trickier, and layer 7 is extremely difficult.

  The discussions I've seen on the list appear to say that writing CE
applications can be automated, once the graph topology and capabilities
are known.  My response is that if that were true, the most of the IETF
working groups would disappear, and we could "compile" new network apps
from a set of requirements.

  I think that the model document needs updating to address these
issues, because it's silent on them.   I don't have many objections to
what the model document does say, however.

  Alan DeKok.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jan 2003 12:07:19 -0500

This is a fair question.

Lets start with an easy cases, just to make sure that we are un the same page.
Given a CE that understands diffserv, it will understand that for an AF
service it will need a classifier (to select which traffic gets the
service) a meter, and a set of markers on the ingress path.  It will also
understand that for the egress path it will need a mark sensitive queue
selector (to get the traffic into the queue it is using for AF1x) and a
mark sensitive RED element if it has one and wants to use it.  It may well
have logic that changes the input behavior if the available outputs do not
have mark sensitive RED.

In one sense this is easy.
In another sense, this is extremely difficult.  Trying to go from a service
description of the form [given 10.x traffic AF1x, with these rate limits
for red, yellow, green] to the sequence above is non-trivial.  However, I
do not expect the CE to make that transform.  The CE will be given a set of
descriptions along the line of the QDDIM model or diffserv model, which
defines the actual processing required.  It can then look at the
capabilities of the FE and deploy the service.
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.

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.
Given the transformed service description, the CE will then evaluate what
FEs can be adjusted to deliver the service.  This will likely require using
/ creating a path that was not used before.  Whether that is done by
reconfiguring the paths, or by using an available path, will depend upon
the FE implementation.

Probably the hardest part of the CEs algorithmic job will be determining
when it can use the same parts for different services.  The place where
this will be most complicated is in the handling of output queues and their
scheduling.  The interaction of scheduling disciplines and the resulting
service delivery may be intractable.  But the interaction of classifiers,
policers / meters, markers, encaps / decaps elements, etc is easily modeled
and understood by software.  I believe that the CE can find available
resources to meet its needs.  Understanding both the capacity and
connectivity flexibility of the blocks inside the FE is very helpful for
the CE in doing this job.

I hope that this helps explain the assumptions I at least am making.

Yours,
Joel M. Halpern

At 11:48 AM 1/21/2003 -0500, Alan DeKok wrote:
>I don't understand how that would work.  I think

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 21 Jan 2003 06:16:27 -0500

> I will presume that you did not intend to be rude.

Absolutely not the intent. I was more raising my hands in frustration.
[Ram, i know you were away, but from your email you were supposed to be back
last week monday - i was going to wait but this discussion got out of
control.]
In any case i am glad killing-the-draft idea woke people up.

> I and other author's have tried to explain the reasoning in the document.

The main contention as i see it are:
a) Forces is not just about QoS and diffserv alone; in my opinion they are
merely examples of the larger forces model. Diffserv and QoS fit within the
larger ForCES model but the vice-versa is not necessarily true.
b) There are infact layers for the model to make sense: The lower two being a
policy/service layout of a graph of functional block/elements and beneath it
being the functional block itself which is not aware of the larger picture.

The draft model does lump the two layers in b) together or at least does not
unambigously declare them separate.

To me the above  makes any discussion on the draft hard to start.

> working group accepted alternative in hand.

I didnt wanna exercise the option of releasing another draft yet(i did in the
case of the requirements draft after similar frustration); i was hoping we
could reach some understanding.

cheers,
jamal

---

From: Alan DeKok <[email-masked]>
Date: Tue, 21 Jan 2003 12:47:13 -0500

> have logic that changes the input behavior if the available outputs do not

  I agree.

  For me, the important concept in a CE "understanding" diffserv is that
it probably does NOT need to explicitely know or manage the topology.
The topology is implicit: it's diffserv.

  For well-known protocols and applications, a lot of the topology
discussions disappear.

> could and could-not deliver this service given their configuration and

  I agree.  Some simple "sanity checking" of the topology by the CE is
possible, even if it does nothing more than that.

> the necessary processing elements.  I do not expect the CE to perform taht

  I would like to see that statement made explicit in the draft.

  e.g. An administrator can pick & choose network elements, and tell the
CE "implement diffserv using A, B, and C".  In this situation, the
policy is human controlled, and all of the topology issues go away.

> when it can use the same parts for different services.

  The FE can make that information available.  If an administrator says
"use element B for metering", then that element can know it's in use,
and refuse to make itself available for implementing other functions.

>  But the interaction of classifiers,
> and understood by software.

  I agree.  A classifier may be able implement ACL's and routing
simultaneously.  In that case, it can make itself available twice, to
the adminstrators policy engine.

> I hope that this helps explain the assumptions I at least am making.

  It does.  I think we're very close in outlook.  We just have the
communications barrier of a shared language to overcome. :)

  Alan DeKok.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jan 2003 12:52:55 -0500

I agree.  We can and will add a statement along these lines to the draft.
Yours,
Joel M. Halpern