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

From: "John Strassner" <[email-masked]>
Date: Wed, 28 Jun 2000 12:50:39 -0700

This message deals exclusively with section 8 in the
information model.
=========
Conceptual Model, Section 8, pg 31, says:

 "A general TCB might consist of the following four
  stages:
  - Classification stage
  - Metering stage
  - Action stage
  - Queueing stage"

Comment:
This should be the subject of Yet Another Note, but I
would like to point out that from a modeling point-of-
view, this separation of stages is somewhat arbitrary,
and therefore not helpful to understanding how the
different elements that make up the forwarding path
work together.

ALL of these stages are "actions" at some level of
abstraction. The conceptual model seems intent on
calling these stages because they have different
fan-ins and fan-outs. But from a modeling point-of-view,
this is the wrong level of abstraction to focus on:

  1) each of these elements is performing an action on
     the traffic; therefore, they should be modeled as
     different types of the same element
  2) separating by fan-in or fan-out is not germane to
     modeling the TYPE of function performed by these
     different elements and is an arbitrary way of
     organizing information - you just as easily could
     have used the number of parameters given to an
     element, or its position in the TCB
  3) it isn't true of all elements (e.g., an algorithmic
     dropper can have two outputs, one for dropped
     traffic and one for forwarded traffic), which
     implies that it is not a good way to differentiate
     these elements

==============
Conceptual Model, Section 8, pg 32:
It then goes on to say:

  "Note that a classifier is a 1:N element, metering
   and actions are typically 1:1 elements and queueing
   is a N:1 element."

Comment:
This is an error: metering is NOT typically a 1:1
element. It is typically a 1:N element, having different
actions for in-profile and out-of-profile traffic.

==============
Conceptual Model, Section 8, pg 31:
The last paragraph of pg 31 says:
  "TCBs are constructed by connecting elements
   corresponding to these stages in any sensible order.
   It is possible to omit stages, to include null
   elements, or to concatenate multiple stages of the
   same type. TCB outputs may drive additional TCBs (on
   either the ingress or egress interfaces)."

Comments:
First, you should clarify that an "element" is an
instance of one of the four types (i.e., classifier,
meter, action, or queue) of functions identified earlier.

Second, I don't see how it is possible to omit a
classifier. If you do this, then you essentially have
a single input stream. The only element that you have
for differentiating traffic is then a meter, but a meter
doesn't separate traffic, it simply handles traffic with
different characteristics differently. So essentially,
you don't have differentiated services at all, you have
a single service that operates on a single traffic
stream. This isn't interesting to model.

Finally, you say that "TCB outputs may drive additional
TCBs...". I don't see how this is possible. You have
defined a TCB as an atomic unit that has a single input
and a single output. Classifiers and meters have
multiple outputs, and queues have multiple inputs. This
means that the classifiers, meters and queues must be
enclosed within a TCB. This leaves the only option for
the output of a TCB as the queue, which arguably represents
the end of conditioning of the traffic. So I
fail to see how you can connect another TCB to something
that has already been completely conditioned.

The only exception to this is if you bend the definition
of the TCB and let it "slice" across an element (e.g., if
a classifier has 3 outputs, then define up to 3 TCBs,
where one or more outputs is contained in a TCB). Now, I
think that if you want to do this, you should change the
definition of the TCB (rules were made to be broken, but
definitions weren't). But even if you do do this, then
one has to ask, what is the point of the TCB? There are
three main problems:

  1) You've now taken a clean concept - a classifier
     separates a single input traffic stream into
     multiple output traffic streams - and complicated
     it by adding in a TCB. The TCB doesn't add any
     additional meaning to, or aid in the understanding
     of, the classifier.

  2) You've further complicated things by saying that
     sometimes a TCB represents all outputs of the
     classifier, and sometimes it represents one or more
     outputs. A modeling element should not have to be
     morphed to fit an application.

  3) You don't need a TCB to say that different traffic
     streams are connected to different elements. In
     this case, it is even worse, because now you're
     separating an element into sub-elements and
     complicating the architecture by forcing a TCB to
     either represent an atomic element or a piece of
     what *used* to be referred to as an atomic element.
     This is a Bad Thing, and points to the underlying
     problem that a TCB is only an arbitrary delimiter,
     not a natural way of classifying elements.

==============
Conceptual Model, Section 8.1, general comments

Comments:
Note that figures 6 and 7 combine a number of elements
into a single TCB. If a TCB was useful at a finer level
of granularity, then an example similar in complexity
to this example should be included in the draft.

==============
Conceptual Model, Section 8.1, pg 32, says:

The description in Figure 6 doesn't match the text.
Outputs A, B, C, and X of Classifier 1 are earlier
defined as corresponding to traffic having a DSCP of
001001, 001100, 001101, and other, respectively. Yet,
the draft then says:

  "Packets submitted for DSCP 001001 that are deemed
   non-conforming are counted and discarded while
   packets that are conforming are passed on to
   Dropper1/Queue1."

But, in Figure 6, output A (DSCP 001001) goes to Meter1,
whose conforming traffic goes to Queue1 and whose
non-conforming traffic goes to AbsoluteDropper1. The
problem is that Dropper 1 is directly connected to output
B (DSCP 001100) of the classifier. This feeds a separate
Queue, as shown in Figure 7.

==============
Conceptual Model, section 8.1, pg 32, says:

  "The Queueing stage is realised as follows, shown in
   figure 6."

Comment:
The queuing stage is illustrated in figure 7, not
figure 6

==============
Conceptual Model, section 8.1, pg 32, says:

  "The conforming 001001 packets are passed
   directly to Queue1: there is no way, with correct
   configuration of the scheduler for these to overflow
   the depth of Queue1 so there is never a requirement
   for dropping."

Comment:
What happens if traffic bursts? If this is EF, throwing
away voice packets is a Bad Thing. If instead some other
assumption is being made (e.g., over-provisioning) then
please say so.

==============
Conceptual Model, section 8.1, pg 32-33, says:

  "Packets marked for 001100 must be passed through a
   tail-dropper, Dropper1, which serves to limit the
   depth of the following queue, Queue2: packets that
   arrive to a full queue will be discarded..."

Comment:

You've embedded a dropper within a queue. This is a Bad
Thing - the model should be of sufficient granularity to
be able to model "smart" variations of the fundamental
classifier, meter, marker, dropper, and queue elements
as a combination of these elements without burying
functionality inside one of them. In other words, if
there is a dropper in Queue2, then say so and model it
explicitly. Go ahead and invent another element if you
need to, but that element should explicitly show that it
is composed of a dropper and a queue.

==============
Conceptual Model, section 8.1, pg 33, says:

  "Packets marked for all other DSCPs are passed to
   Dropper3 which is a RED-like algorithmic dropper:
   based on feedback of the current depth of Queue4,
   this dropper is likely to discard enough packets from
   its input stream to keep the queue depth under
   control.

Comment:
Note that figure 7 does not show any feedback from Queue4
to Dropper 3. This is a Bad Thing - the model should be
flexible enough to show this. Note that this also means
that some of the generality implied earlier in the model,
where it was implied that the output of a TCB could
conform to any output of an element, is usually wrong -
there are usually semantic constraints between different
elements.

==============
Conceptual Model, section 8.1, pg 34, says:

  "These four queues are then serviced by a scheduling
   algorithm in Scheduler1 ..."

Comment:
This text, and figure 7, show the outputs of each queue
going into an input of the scheduler. This is wrong.
The scheduler is a process that controls the emptying
of each queue. This does not mean that the queue feeds
the scheduler. In fact, we're talking about two types of
traffic here - the data traffic exiting the queues and
the control traffic between the scheduler and each
queue. A more correct drawing would separate the data
and control traffic.
==============
Conceptual Model, section 8.1, pg 34, says:

  "Scheduler1 which has been configured to give each of
   the queues an appropriate priority and/or bandwidth
   share..."

Comment:
The rest of the paragraph details a large number of
semantics that are not at all obvious from looking at
Figure 7. This is a Bad Thing - the model should at least
be able to represent important semantics.

More importantly, note again that the use of the TCB is
confusing at best. Clearly from the text, one can not put
any of the queues into TCBs that are separate from the
Scheduler. Therefore, this represents another set of
semantic limitations that restrict the general "you can
put anything anywhere" approach espoused by the TCB.

So again, what good is the TCB doing in representing the
scheduling of queues?
==============
Conceptual Model, section 8.2, pg 37, says:

  "First, a TCB is defined for each customer to
   reflect the TCS with that customer: TCB1, defined
   above is the TCB for customer 1 and definitions are
   then added for TCB2 and for TCB3 which reflect the
   agreements with customers 2 and 3 respectively."

Comment:
It is unclear from the above statement whether the same
elements are used for each TCB, but just have different
parameters, or if each TCB requires its own set of
elements. This is illustrated by the following
abbreviated drawing, consisting of figure 8 from the
text:

  input   +-----+
  traffic |    A|-->TCB1
     |    |    B|-->TCB2
      --->|    C|-->TCB3
          |    X|-->AbsoluteDropper4
          +-----+
        Classifier4

Now, the problem is when you actually try and draw what the
above figure implies. I'll do this for just the
first classifier and meter of TCB1 and TCB2. If it is the
former (same elements reused for each TCB), then what you
have is the following, showing just the first two stages
of the EF path:

  +----------------------------------------------------+
  |  input  +-----+            +---------------------+ |
  |traffic  |     |            | +----+   +---+      | |
  | traffic |    A|-->TCB1--+->| |   A|-->|  A|-->...| |
  |    |    |     |         |  | |   B|   |  B|-->...| |
  |    |    |    B|-->TCB2--+  | |   C|   +---+      | |
  |     --->|     |         |  | |   X|   Meter1     | |
  |         |    C|-->TCB3--   | +----+              | |
  |         |     |            | Classifier1         | |
  |         |     |            |                     | |
  |         |     |            |   TCB1, TCB2, TCB3  | |
  |         |     |            +---------------------+ |
  |         |    X|-->AbsoluteDropper4                 |
  |         +-----+                                    |
  |       Classifier4                            TCB4  |
  +----------------------------------------------------+

At which point you have to ask, what has been gained by
using the TCB? You again have to bend the definition of
the TCB by saying that for TCBs 1-3 (which correspond to
customers 1-3), a set of parameters must be applied to
the same set of elements, extracting a logical piece of
each of those elements and defining it to mean something
different for each customer. In other words, you are
forcing the line between output A of Classifier1 and
the input of Meter 1 to mean one thing for customer 1, but a
completely different thing for customer 2. This has three
major problems:

  a) It is impossible in this diagram to distinguish
     between the traffic for customer 1 and 2, which
     means that the TCB did no good, because the whole
     purpose of the TCB was to do just that.
  b) You are forcing the same output (e.g., the line
     between output A of classifier1 and the input to
     Meter1) to simultaneously mean different things.
  c) TCB4 is at a completely different conceptual level
     than TCB 1-3. This is confusing at best, especially
     since TCB4 exhibits none of the semantics of TCBs
     1-3.
  d) What happens when one of the TCBs does not need
     one of the elements?

Thus, I conclude that this can not be this that you
meant.

The other option is to assume that TCBs 1-3 requires
their own copies of the elements in TCB1. Then you get
the following:

  +---------------------------------------------------+
  |                         +-----------------------+ |
  |  input  +-----+         |  +-----+   +---+      | |
  | traffic |    A|-->TCB1--|->|    A|-->|  A|-->...| |
  |    |    |     |         |  |    B|   |  B|-->...| |
  |    |    |    B|-->TCB2  |  |    C|   +---+      | |
  |     --->|     |    |    |  |    X|   Meter1-1   | |
  |         |    C|... |    |  +-----+              | |
  |         |     |    |    | Classifier1-1         | |
  |         |     |    |    +-----------------------+ |
  |         |     |    |    +-----------------------+ |
  |         |    X|... |    |  +-----+   +---+      | |
  |         |     |     ----|->|    A|-->|  A|-->...| |
  |         +-----+         |  |    B|   |  B|-->...| |
  |         Classifier4     |  |    C|   +---+      | |
  |                         |  |    D|   Meter1-2   | |
  |                         |  +-----+              | |
  |                         |  Classifier1-2        | |
  |                         +-----------------------+ |
  |                                              TCB4 |
  +---------------------------------------------------+

I have taken liberties with naming to emphasize my point.
This approach says that I have to have n different
instances of the same element (e.g., Classifier1-1 and
Classifier1-2) for n different customers. This is bad for
the following reasons:

  a) it eliminates any sharing of elements between the
     different customers.
  b) it forces needless duplication of elements because
     the same element performing the same function is
     assigned to a different TCB.
  c) TCB4 is at a completely different conceptual level
     than TCB 1-3.
  d) In this case, if one or more of the TCBs doesn't
     need a particular element, it is still confusing,
     because you're defining a TCB of varying numbers
     and types of elements
==============
Conceptual Model, section 8.2, pg 37:

Comments:
I have two comments here:

  1) Figure 8 is unfortunately placed right below the
     definition of TCB2, which is confusing. It should
     precede the definitions of the TCB
  2) The phrase "...(similar to TCB1, perhaps with
     different numeric parameters)" is bothersome because
     nowhere in the diagram are the numeric parameters
     evident. To me, a model is a visual thing, and even
     if the model needs explanatory text or code, it
     should fundamentally be capable of representing the
     connection of object instances.

Yes, this is an argument for using a UML model to
represent these concepts.
==============
Conceptual Model, section 8.2, pg 38, says:

  "TCB4 has a Classifier stage and an Action element
   stage, which consists of either a dropper or another
   TCB."

Comments:

This conflicts with the definition of Actions (section 6)
on pgs 20-21, which says:

  "The set of possible actions include:
    -    Marking
    -    Absolute Dropping
    -    Multiplexing
    -    Counting
    -    Null action - do nothing"
===============

regards,
John

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