[Diffserv] Comments on the TCB of the Conceptual Model - msg 1 of 2

["John Strassner" <[e-mail]>]

Hi,

I have a number of questions on the Conceptual Model.
However, the most troubling part of the draft is the section
on TCBs. This is the first of two messages that examines the
definition of TCBs, and whether or not they help.

====================
Executive Summary: kill the concept of TCB ;-)

Detailed comments:

====================
pg 4
(Definition)
A logical datapath entity consisting of a number of other
functional datapath entities interconnected in such a way
as to perform a specific set of traffic conditioning
functions on an incoming traffic stream. A TCB can be
thought of as an entity with one input and one output and
a set of control parameters.

Comment:
This adds no value. In particular, the restriction that a
TCB have just one input and just one output constrains it to
modeling just the ingress and egress ports of the device.
This in turn means that it can't be used to model the
internal components of the device, which is its stated
intention, since many of the internal components have
multiple inputs or outputs.

And as we will see, from a modeling point-of-view, there
should be no difference in modeling the different components
used to condition traffic (e.g., classifiers, meters,
markers, droppers and queues). Yet, the Conceptual Model
insists on using an arbitrary distinction - that of the
number of inputs and outputs - along with other less clear
distinctions to classify the various internal components of
a device into four "stages" of forwading. Exacerbating this
problem is the insistence of the Conceptual Model that these
elements can be put together in any "reasonable" order.
While that may be technically correct, the purpose of a
model
should be to help define explicitly what the components
being modeled look like and their inter-relationships.
Therefore, since the TCB fails to define specifically how
these components can be interconnected, the TCB can't be
used to model these components.

Finally, it makes problematic statements scattered in the
draft about building TCBs out of TCBs. If the goal of this
draft is indeed to:

  "...define [and model] the general functional datapth
   elements..., their possible configuration parameters,
   and how they might be interconnected to realize the
   range of classification, traffic conditioning,
   and ...PHB functionalities..."

(from the abstract, no less), then TCBs as currently defined
are utterly useless in this regard.

====================
The Conceptual Model says, on pg 9:
At the top level, the network administrator manages
interfaces. Each interface consists of an ingress component
and an egress component.  Each component may contain
classifier, action, meter and queueing elements.

Comments:
At the top-level, the network administrator certainly
doesn't manage interfaces. The network administrator manages
services which are provided by network devices which have
interfaces (and sub-interfaces, but that's another
ball-of-wax altogether). Please tie this part of the draft
into the work being done in the Policy Framework wg
(specifically, Polterm), or I'll do that for you if you
would like.

So I think that what you meant to say is that this draft is
concerned with modeling network services (or, if that is
still a Bad Word, modeling network configuration), starting
at the interface level. Right?

====================
The Conceptual Model continues (on page 9):
At the next level, the network administrator manages groups
of functional elements interconnected in a DAG

Comments:
I had to read these three times to guess that by
"functional element", you meant things like classifiers and
queues. I first thought that you were talking about network
devices. Recommendations:

  1) define "functional element" in your glossary
  2) relate the interface of a device to the functional
     elements that it uses (which you don't)

====================
The Conceptual Model continues (on page 9):

These elements are organized in self-contained Traffic
Conditioning Blocks (TCBs) which are used to implement some
desired network policy (see Section 8).

Comments:
Forward references are a Bad Thing. At this point the reader
has no idea what a functional element or a TCB is. But a
reader does know that a TCB is a black box with one input
and one output. Therefore, all you've said is that SOME (but
not which) of the components that are buried somewhere
inside the device are also buried within a TCB.

So in fact, all you've done is confused the issue by
introducing a new term (TCB). You're still talking at the
interface level.

====================
The Conceptual Model continues (on page 9):

One or more TCBs may be instantiated on each
ingress or egress component;

Comments:
First, you haven't defined what an ingress or egress
component is (do you mean interface, or component of an
interface?). Second, you just defined a TCB as a black box
with one input and one output. So how can you have multiple
of these on either an ingress or an egress interface? Note
that throughout your draft, you get around this constraint
by dumping all of the needed conditioning components inside
of a TCB. So the only thing that I can figure is that you're
trying to equate multiple traffic streams (from, for
example, multiple customers) that happen to be multiplexed
over the same input and output interfaces (which is starting
to sound a bit bizarre) to multiple TCBs. But since you
never say this anywhere, I'm not sure what in fact you're
trying to communicate. And if this is what you're trying to
communicate, then please see my comments on my second
message on TCBs (section 8.2, pg 37).

====================
The Conceptual Model continues (on page 9):

...they may be connected in series and/or in parallel
configurations on the multiple outputs of a classifier.
The TCB is defined optionally to include classification
and queueing elements so as to allow for flexible
functionality.

Comments:

This violates your own definition! First you say that a
classifier can be part of a TCB, and then you say that it is
feeding multiple TCBs. I realize that this is a voting year
;-) but it seems like you have to make up your mind here -
it can't both be part of and not part of a TCB. Because the
TCB has one input and one output.

But even if you relaxed that constraint, now you're saying
that the classifier (and any components that occur in the
datapath before it) are feeding multiple TCBs. Which means
that you can't combine any of the paths emanating from the
classifier that may want to have common services performed.

For example, a Classifier could have several outputs, two of
which feed into meter A and meter B. But if what we wanted
was to use an absolute dropper for the non-conforming
traffic of each of these meters, you have to instantiate two
of them since the TCB makes them atomic. This is a real
shame, and leads to instance explosion for the case of a lot
of classifiers using a lot of cascaded meters that feed into
the same queue.

====================
The Conceptual Model continues (on page 9):

A TCB can be thought of as a "black box"
with one input and one output in the data path. Each
interface (ingress or egress) may have different TCB
configurations.

Comments:
How can this last statement possibly be true? All of the
examples in the draft handle the multiple outputs and inputs
of conditioning components (classifiers, meters, etc.) as
part of a single TCB, doubtless to get around its
definitional problems. Please provide an example that
illustrates this.

====================
The Conceptual Model continues (on page 9):
At the lowest level are individual functional elements,
each with their own configuration parameters and management
counters and flags.

Comments:
OK, so assuming that this level is talking about
classifiers, meters, queues, etc. - how does this relate to
the two levels above, and how does a TCB help this
relationship?

Also, note that you are talking in general terms - you
haven't tried to distinguish that there are fundamental
differences between classifiers, meters, markers, droppers,
and queues (we'll get to schedulers later). This is a Good
Thing. Strangely enough, the information model that was
developed to represent the data forwading path in a network
device makes no distinction among these either - they are
each modeled as a common conditioning service. But more on
this later too in the second message.

regards,
John


_______________________________________________
diffserv mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/