Subject: [Diffserv] Comment on model draft-03

From: jamal <[email-masked]>
Date: Sat, 27 May 2000 22:00:25 -0400 (EDT)

My general opinion (havent followed up on this since version 00)
And i havent been subscribed to the list for a long time, so
must have missed a lot of fun discussions. please cc responses to
me.

This version seems to have sunk into more "implementation specifics"

[..]

draft>
draft>   conserving    servicess a packet, if one is available, at every
draft>                 transmission opportunity."

The quotes above seem to be a typo.

[..]

draft>3.1.  Elements of a Diffserv Router
draft>
draft>   o    Traffic Conditioning (TC) actions of Marking, Absolute Dropping,
draft>        Counting and Multiplexing.
draft>

I might have asked this earlier; but why are the actions limited to the
above?

draft>Bernet et al.             Expires November 2000         [Page 8]
draft>
draft>Internet Draft          Diffserv Conceptual Model               May 2000
draft>
draft>
[..]
draft>be implemented on the ingress component, with the packet passed through
draft>the routing core with in-band control information to allow for egress
draft>queue selection.
draft>
draft>>From a device-configuration and management perspective, the following

The extra ">" seems to be a typo.

draft>We use the following diagram to illustrate a classifier, where the
draft>outputs connect to succeeding functional elements:
draft>
draft>      unclassified              classified
draft>      traffic                   traffic
draft>              +------------+
draft>              |            |--> match Filter1 --> OutputA
draft>      ------->| classifier |--> match Filter2 --> OutputB
draft>              |            |--> no match      --> OutputC
draft>              +------------+
draft>
draft>      Figure 3. An Example Classifier
draft>
draft>Note that we allow a multiplexor (see Section 6.5) before the classifier
draft>to allow input from multiple traffic streams. For example, if multiple
draft>ingress sub-interfaces feed through a single classifier then the
draft>interface number can be considered by the classifier as a packet
draft>attribute and be included in the packet's classification key. This
draft>optimization may be important for scalability in the management plane.
draft>Another example of a packet attribute could be an integer representing
draft>the BGP community string associated with the packet's best-matching
draft>route.

This whole classifier being 1:N element is becoming confusing.
What you need to do is define the meaning of "output stream", literally.

[One could argue that infact a classifier is a N:1 element. You have N
different type of packet headers coming in and one "class identifier" or
queue selector or whatever you wanna call it as an output.]

Could a BA classifier be defined to be a special case of the six tuple
classifier (with the 5 tuples other than the DSCP being wildcards?) 

draft>
	[..]
draft>6.  Action Elements
draft>
draft>The classifiers and meters described up to this point are fan-out
draft>elements which are generally used to determine the appropriate action to
draft>apply to a packet. The set of possible actions include:
draft>
draft>-    Marking
draft>
draft>-    Absolute Dropping
draft>
draft>-    Multiplexing
draft>
draft>-    Counting

Is Counting really an action element? I would have thought it is explicitly
part of statistics maintanance; regardless, what has it really got to do
with defining a diffserv router model? I have scanned the document and
observed a spot where it is defined to be used as a  way "to tell the
customer" it is time to upgrade the SLS or something along those lines.
IMO,  that is not a good enough reason. 
It would be good to put it under "other". This way we also leave that
portion open for future additions.

draft>6.3.  Multiplexer
draft>
draft>It is occasionally necessary to multiplex traffic streams into a 1:1 or
draft>1:N action element or classifier.  A M:1 (fan-in) multiplexer is a
draft>simple logical device for merging traffic streams. It is parameterized
draft>by its number of incoming ports.
draft>
draft>      Mux1:
draft>      Type:                Multiplexer
draft>      Output:              Queue2
draft>

I am really trying to understand the use of this multiplexer box.
Is it just a mechanism to logically explain the joining of two
output classifier streams? Would the following not have sufficed?

----|------->
    |
-->-|

Seems like the juncture point has become a box now.
Either that or you need to have a lot more supporting text to justify the
Mux (which is not there right now).

draft>
draft>7.1.1.  FIFO
draft>
	[...]
draft>
draft>In an implementation, packets are presumably stored in one or more
draft>buffers. Buffers are allocated from one or more free buffer pools. If
draft>there are multiple instances of a FIFO, their packet buffers may or may
draft>not be allocated out of the same free buffer pool. Free buffer pools may
draft>also have one or more threshold associated with them, which may affect
draft>discarding and/or scheduling. Other than this, buffering mechanisms are
draft>implementation specific and not part of this model.
draft>

Implementation details ?

draft>7.1.3.  Algorithmic Dropper
draft>
draft>An Algorithmic Dropper is an element which selectively discards packets
draft>that arrive at its input, based on a discarding algorithm. It has one
draft>data input and one output. In this model (but not necessarily in a real
draft>implementation), a packet enters the dropper at its input and either its
draft>buffer is returned to a free buffer pool or the packet exits the dropper
draft>at the output.
draft>
draft>Alternatively, an Algorithmic Dropper may invoke operations on a FIFO
draft>which selectively removes a packet, then return its buffer to the free
draft>buffer pool, based on a discarding algorithm. In this case, the
draft>operation is modelled as a side-effect on the FIFO upon which it
draft>operates, rather than as having a discrete input and output.  These two
draft>treatments are equivalent and we choose the former here.
draft>
draft>The Algorithmic Dropper is modelled as having a single input. However,
draft>it is likely that packets which were classified differently by a
draft>Classifier in this TCB will end up passing through the same dropper. The
draft>dropper's algorithm may need to apply different calculations based on
draft>characteristics of the incoming packet e.g. its DSCP. So there is a
draft>need, in implementations of this model, to be able to relate information
draft>about which classifier element was matched by a packet from a Classifier
draft>to an Algorithmic Dropper.  This is modelled here as a reverse pointer
draft>from one of the drop probability calculation algorithms inside the
draft>dropper to the classifier element that selects this algorithm.
draft>
draft>There are many formulations of a model that could represent this
draft>linkage, other than the one described above: one way would have been to
draft>have multiple "inputs" fed from the preceding elements, leading
draft>eventually to the classifier elements that matched the packet. Another
draft>formulation might have been for the Classifier to (logically) include
draft>some sort of "classification identifier" along with the packet along its
draft>path, for use by any subsequent element. Yet another could have been to
draft>include a classifier inside the dropper, in order for it to pick out the
draft>
draft>

Lotsa more implementation specifics. 

With the algorithmic dropper,since you use the RED-like algorithm as
an example, where does ECN marking fit? (note your usage of "dropper").

draft>The dropping algorithm makes a decision on whether to forward or to
draft>discard a packet. It takes as its parameters some set of dynamic
draft>parameters (e.g. averaged or instantaneous FIFO depth) and some set of
draft>static parameters (e.g. thresholds) and possibly parameters associated
draft>
draft>           +------------------+      +-----------+
draft>           | +-------+        |  n   |smoothing  |
draft>           | |trigger|<----------/---|function(s)|
draft>           | |calc.  |        |      |(optional) |
draft>           | +-------+        |      +-----------+
draft>           |     |            |          ^
draft>           |     v            |          |Depth
draft>  Input    | +-------+ no     |      ------------+   to Scheduler
draft>  ---------->|discard|-------------->    |x|x|x|x|------->
draft>           | |   ?   |        |      ------------+
draft>           | +-------+        |           FIFO
draft>           |    |yes          |
draft>           |  | | |           |
draft>           |  | v | count +   |
draft>           |  +---+ bit-bucket|
draft>           +------------------+
draft>           Algorithmic
draft>           Dropper
draft>
draft>      Figure 5. Algorithmic Dropper + Queue
draft>
draft>

Another rat hole.
Out of band smoothing function versus in-data-path smoothing function.

draft>with the packet (e.g. its PHB, as determined by a classifier, which will
draft>determine on which of the droppers inputs trhe packet arrives). It may

"trhe" is a typo.
 
draft>8.1.  An Example TCB
draft>
draft>A SLS is presumed to have been negotiated between the customer and the
draft>provider which specifies the handling of the customer's traffic by the
draft>provider's network. The agreement might be of the following form:
draft>
draft>   DSCP     PHB   Profile     Treatment
draft>   ----     ---   -------     ----------------------
draft>   001001   EF    Profile4    Discard non-conforming.
draft>   001100   AF11  Profile5    Shape to profile, tail-drop when full.
draft>   001101   AF21  Profile3    Re-mark non-conforming to DSCP 001000,
draft>                                 tail-drop when full.
draft>   other    BE    none        Apply RED-like dropping.
draft>
draft>This SLS specifies that the customer may submit packets marked for DSCP
draft>001001 which will get EF treatment so long as they remain conforming to
draft>Profile1 and will be discarded if they exceed this profile. The

Do you really foresee an SLS looking like the above example ;->?

[..]
draft>The Queueing stage is realised as follows, shown in figure 6.  The
draft>conforming 001001 packets are passed directly to Queue1: there is no

You mean figure 7?

cheers,
jamal

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 May 2000 08:29:19 -0500

Jamal,

Comments on some of your comments...

> This version seems to have sunk into more "implementation specifics"

That's not my impression. While we are not describing an implementation,
it's impossible to describe a model that has no connection to *potential*
implementations.

...
> I might have asked this earlier; but why are the actions limited to the

Because that seemed to be the consensus about a necessary & sufficient set.

...
> What you need to do is define the meaning of "output stream", literally.

Don't agree. A classifier is just a kick-sorter and it kicks packets
into a number of bins. 
> queue selector or whatever you wanna call it as an output.]

Nah. It has a single input stream of mixed up packets and multiple
output streams of classified packets.

> classifier (with the 5 tuples other than the DSCP being wildcards?)

We chose to differentiate between BA and MF classifiers two years ago.
It would be very confusing to change that now.

...
> with defining a diffserv router model? 

In the real world it will be a function of the classifier, and it's
needed for the MIB. I think it's fine where it is.

...
> output classifier streams? 

Or two input streams, yes. This doesn't seem to be a problem.

...
> an example, where does ECN marking fit? (note your usage of "dropper").

ECN isn't part of Diffserv, so it doesn't fit in anywhere.

> Out of band smoothing function versus in-data-path smoothing function.

Doesn't look out of band to me; there's a feedback loop right there.

   Brian

---

From: jamal <[email-masked]>
Date: Wed, 31 May 2000 08:29:14 -0400 (EDT)

> Comments on some of your comments...

And comments on your comments to my comments ;->

> it's impossible to describe a model that has no connection to *potential*

Fair enough. But why the suggestions on how to do things? The details
on freeing buffers etc are based on one/several authors implementation i
am sure. 
Where is this document heading towards again? I can only see it as an
informational RFC.

> output streams of classified packets.

Thats one way to look at it ;-> You could probably go further and say it
is N:N. For consistency, your definition is fine.

> needed for the MIB. I think it's fine where it is.

There has to be a deeper meaning than this which is not clearly elaborated
in the text.
The question is: do you ever foresee an implementation which does not
do stats like the packet/byte counters (incoming/outgoing/dropped
etc) such that you end up needing this luxury of choosing not to do
stat collection? 

> ECN isn't part of Diffserv, so it doesn't fit in anywhere.

Great; so now Diffserv lives in an isolated world. I thought you said that
you cant avoid implementation specifics in some cases. I know you are
trying to close this document but ... 
Both ECN and Diffserv use RED and some of "marking" the old 8bits. That is
a bit too close to hand wave away. 
I see the use of the ECN bits for example being used to provide a lossless
AF end2end service for TCP.

> Doesn't look out of band to me; there's a feedback loop right there.

I should have been more specific:
with the abovce scheme you periodically sample the queue and compute the
RED paramaters offline on the control plane (as in not in the data
path). I refer to this as out of band. Some other scheme might compute
things per packet on the data path; this would be inband. 

cheers,
jamal