Subject: Comments on DiffServ MIB (draft-ietf-diffserv-mib-00.txt)

From: "Alain BURGAIN" <[email-masked]>
Date: Tue, 26 Oct 1999 18:24:44 +0200

Hi Fred,

Some comments on DiffServ MIB (draft-ietf-diffserv-mib-00.txt)

==========================
1. Need of a multi-level traffic control.
==========================

It should be possible to classify and control the traffic both at the «
multi field » (application, end user,…) level and at the « aggregate »
(TCS per interface…) level.

Examples :
-----------
- Perform MF classification without control, then perform aggregate
classification and control the respect of the TCS. The TCS of an input
interface can then be defined either per DSCP, or per DSCP +
destination. So, the « aggregate classification » can be a BA or a MF
classification.
- Perform MF classification with control, then perform aggregate
classification and control according to a different basis than the sum
of all the MF traffic specifications (overbooking).
- Have the ability to perform MF classification and control at egress,
to get the corresponding accounting counters (at this MF level), and
then to have BA queuing with the queue management thresholds definition
at the BA level, that is to say within the actions associated to the BA
subclasses of the DiffServ class of service queue.

--------------------------------------------------------------------------------------------------------

Of course, multi-level traffic control consumes processing power and is
to be used only when needed…
--------------------------------------------------------------------------------------------------------

Three levels are sufficient for the most complex cases, for instance, to
perform at egress :
-----------------------------------------------------------------------------------------

- Level 1: Classification [+ traffic control] according to applications
and/or users :
        - ClassifierMF
        - [Meter]
        - Action = mark, no queuing, [+counters]
- Level 2: Traffic control [+ shaping] according to the remote exit
point of the DiffServ network:
        - ClassifierMF
        - Meter
        - Action = mark, [+ shaping queue and its thresholds],
[+counters]
        - [Queue (for shaping)]
- Level 3: Per Hop Behavior for a DiffServ Class/subclass of service
(ex: AF1.1) :
       - ClassifierBA
       - [Meter]
       - Action = [mark], ptr on Class of Service Queue, Subclass of
service drop priority/queue thresholds.
       - Queue (Class of Service Queue and its scheduling parameters).

NB :
-----
1-  In many practical cases, the example above could probably be
optimized with a 2 level traffic control. Thus, if a single level is
sometimes not enough, three levels are quite sufficient and probably
rarely needed.
2- When queuing occurs, it is necessary to associate to the packet (or,
more statically, to the queue) the indication of the current
classification level.

====================================================
2. Proposal of extension to DiFFServ MIB to allow multi level-traffic
control
====================================================

In DiffServClassifierEntry (page 10 to 12), add
“diffServClassifierLevel” (Unsigned32, read-create, current, DEFVAL { 0
} ), before (or after) “diffServClassifierSequence” :

“ The level of the classifier. Level 0 is fully processed first, then,
if other levels are present, processing is made in ascending order. Only
classifiers indicated with the current level are searched for matching
the packet (with respect to the search sequence specified below), then,
as a classifier is found, it is processed with its associated meter and
action and the treatment resumes with the next level of classification.
”

This object may be added at the end of the index list.

========================================================================

3. Proposal of an optional congestion avoidance parameterization for a
more precise queuing delay control.
========================================================================

In term of service differentiation, at least for some service classes,
the number of packets in a queue has not a clear meaning for the user
(or for the network administrator). What is important is the control
over the queuing delay for each class of service.

To trigger drop decision, the evaluation of the pre-congestion level
should then be performed according to the current (instantaneous or
average) queuing delay. That is to say drop thresholds are (optionally)
configured in ?s, in the diffServActionTable.
When a variable bit rate subnetwork is used, the implementation is then
able to take into account the exact [average] queuing delay for each
packet (provided that the current rate of the subnetwork connection is
known. Suitable purge actions may also be needed after a sudden decrease
of this service rate).

The “filling control” option, indicating whether to use packet number
thresholds or queuing delay thresholds can be specified in the
diffServQueueTable entry that is pointed by the diffServActionTable
entry.

The value of the time constant for the calculation of the average
filling of the queue determines the best compromise for the associated
class of service between :
- the tolerance to transient congestion due to bursty traffic, with
reaction only in case of a persistent congestion state, and
- the control of the queuing delay, which can just be a control of the
average queuing delay for elastic traffic, but need to be a more
deterministic control of the maximum queuing delay for interactive and
real time traffic.

This time constant, associated to the class of service can be configured
in the diffServQueueTable. A null value indicates that tail drop queuing
is performed.
The option between tailDrop and randomDrop can then be removed from the
diffServActionPolicy parameter in the action table, and replaced by a
common “dropToAvoidCongestion” value : within the same queue, it does
not seem useful to manage certain subclasses with RED and others
without.

A protection parameter (indeed two, one in packets and one in ?s, used
according the “filling control” option) can limit the instantaneous
queue length (meaningful if the time constant above has a non zero
value).

======
remarks :
======
In the new version of the draft (01), an object,
“diffServQueueOccupancyWeight”, has been added.
It’s a different approach than mine, that could be considered as an
alternative or as complementary. I’m interested in your opinion.

Best Regards
Alain BURGAIN
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 1999 13:28:01 -0500

Alain,

Since we will only be discussing the -01 draft from now on, is it
possible for you to re-formulate your message as a comment on that
version?

Thanks

   Brian Carpenter
   diffserv co-chair

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 1999 13:37:07 -0500

Alain BURGAIN wrote:
...
> (TCS per interface…) level.

However, there is no reason why both these stages must occur
in the same router.

In fact it would seem more natural to do the full MF classification
in the source host (or possibly the first router) and then do
the BA classification in an ISP border router.

If you do want to cascade them both at the same router ingress, 
doesn't the RowPointer in the -01 MIB allow this?

  Brian