Subject: [Diffserv] Diffserv MIB - updated draft and open issues

From: Andrew Smith <[email-masked]>
Date: Fri, 19 May 2000 15:38:33 -0700

Somewhat later than was promised in Adelaide, I have just submitted an
update of the MIB draft - please watch out for
draft-ietf-diffserv-mib-03.txt coming soon to a draft-repository near you.

Here's a head-start on the open issues list from that draft (there's a list
of the now-closed issues in the draft itself) - these all need to be
resolved by the WG as soon as possible. You'll note that I've assumed
solutions to most of these and so your silence will be taken to indicate
assent on these proposals. Issue 22 is especially important. Please comment
on these issues with messages that indicate which issue you're addressing in
the subject line.

Thanks,

Andrew

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

3.2.  Still Open Issues

(16) How should the creation of counter actions be under the control of
     manager or agent: should a diffServActionEntry and
     diffServCountActEntry appear by magic (the device surely knows what
     counters it can and cannot maintain on a given interface)? (assume
     no) If not, should diffServCountActEntry appear magically when a
     diffServAction element is created which points at the
     diffServCountActTable (then would be no need for
     diffServCountActStatus)? (assume no)

(18) Should manager be allowed to create Queue elements or should agent
     be in control of this? (the former)

(19) Should manager be allowed to create Scheduler elements or should
     agent be in control of this? (the former)

(20) Related to (17) above, do we also need a "level" index for elements
     other than classifiers? (no)

(21) Do we need diffServAlgDropType of both "headDrop" and "tailDrop" or
     should we just represent the tail dropper by placing a dropper
     after the queue instead of before the queue, as linked by the
     diffServQNext and diffServAlgDropNext RowPointers? (the former).

(22) Do we need to support RED algorithms for algorithm parameter
     configuration and monitoring?  If so, what variables are needed?

_______________________________________________
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: Mon, 22 May 2000 08:21:35 -0500

First, I want to thank Andrew in particular, and the rest of the
authors of the model and the MIB, for all the back room work that
has led to these drafts.

Second, we need to reach closure on them as soon as possible. So I would
like to propose that we try to reach consensus on the open issues in the MIB
over the next 2 weeks at most, so that we can conduct a WG last call
on both documents in early June.

  Brian Carpenter
  diffserv co-chair

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]

---

From: John Schnizlein <[email-masked]>
Date: Wed, 24 May 2000 20:03:32 -0400

Is the type of Masked-DSCP consistent with the prohibition against
treating DSCP values as structured rather than as arbitrary values?
Section 4.1.2 of the model seems to encourage something other than 
MUST match against the entire 6-bit field requirement in RFC 2474.

excerpts from both documents follow:

diffserv-model-03:
4.1.2.  Overlapping Filters

Note that it is easy to define sets of overlapping filters in a
classifier. For example:

      Filter5:
      Type:   Masked-DSCP
      Value:  111000
      Mask:   111000

RFC 2474 Differentiated Services Field:       
   Implementors should note that the DSCP field is six bits wide.  DS-
   compliant nodes MUST select PHBs by matching against the entire 6-bit
   DSCP field, e.g., by treating the value of the field as a table index
   which is used to select a particular packet handling mechanism which
   has been implemented in that device.  The value of the CU field MUST
   be ignored by PHB selection.  The DSCP field is defined as an
   unstructured field to facilitate the definition of future per-hop
   behaviors.

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 May 2000 23:00:54 -0700

>      configuration and monitoring?  If so, what variables are needed?

My humble opinion on these:

On kinds of droppers:

I see great utility in describing a tail dropper, as there are a great
number of implementations that use tail drop.

I see great utility in describing a rudimentary RED dropper, as the IETF
recommends the deployment of RED to improve handling of TCP traffic, and
because we have an instance of a PHB that uses that kind of dropper. More in
a moment.

I see very limited utility in describing a head dropper, as I am not aware
of a commercially deployed head dropper. I have seen some research
concerning the things in a French paper, which suggests that it may be
useful on extremely asymmetric links (ADSL), but I have no customers asking
me for one and I don't know of a commercial implementation regardless of
vendor. Obviously, I'm willing to be corrected there.

On random droppers:

The authors had a rollicking discussion of random droppers. It is fair to
say that one of us can live without them, one of us wants a random dropper
with a number of parameters, and one of us (me) thinks that a simple start
is best. The working group has discussed other dropper implementations than
RED, which have various characteristics. The simplest random drop algorithm
I am aware of is RED Light, which Kathy posted a note to the working group
about some time ago, and is documented in
ftp://ftp-eng.cisco.com/ftp/kmn-group/docs/red_light.9.30.pdf; I have to say
that in my experimentation it seems to be quite effective. My druthers tend
towards describing the simplest thing in the public MIB and adding
additional knobs as needed in each vendor's private MIB until it becomes
apparent that there is sufficient commonality in vendor MIBs to justify
standardizing a variable.

It seems to me that the simplest implementation we can have that is a subset
of each of the implementations I am aware of consists of three objects,
which have been described in these words:

At 03:39 PM 3/22/00 -0800, Kathleen Nichols wrote:
 >Okay, then I'd say that the parameters that REDlight has in common
 >with 93RED are:
 >
 >  a threshold for the filtered or averaged queue size below which no
 >         packet dropping takes place (in 93RED, min_thresh)
 >
 >  a parameter for that filter or average (a filter gain or a "queue
 >         weight") that controls the history of the filtering or averaging
 >
 >  an upper bound to the "controlled range", that is a value of the
 >         filtered or averaged queue above which 100% of packets are dropped

Some quick observations:

The min-threshold could be characterized as the target mean queue depth. My
observations of RED in deployment tests is that the effect of the algorithm
is to make the mean queue depth hover close to that value. If we describe it
in those terms, it probably generalizes a little better to the
algorithms that Walter has described.

The max-threshold, the so-called "upper bound", is something that Van has
argued and I think I have heard Kathy agree is non-essential. It may be that
we could agree to drop it as a control.

I would additionally suggest a counter for the packets dropped as a result
of the filter (so we know what it is doing), and that these be indexed per
interface per action using the queue, which is roughly equivalent to being
per interface per queue per DSCP (which the model might more suggest).

I was surprised that we the authors could not come to a consensus similar to
this among ourselves, and I hope that the working group will do so. It seems
to me a bit daft for us to define a public MIB which doesn't adequately
describe the PHBs that we have defined for general deployment.

---

From: Dan Grossman <[email-masked]>
Date: Thu, 25 May 2000 10:57:30 -0400

> number of implementations that use tail drop.
The way the model works, a tail dropper is an algorithmic dropper which is 
placed before the FIFO in the data flow and for which the algorithm is:
  get_next_packet;
  if (qdepth >= threshold) then 
    return_packet_to_free_buffer_pool;
  else
    enqueue (packet, FIFO);

> vendor. Obviously, I'm willing to be corrected there.
There are advantages to head droppers, especially for real-time flows.  There 
have been
some very good papers which used a wine/milk metaphor, and a personal butler 
maintaining
newspaper clippings for a travelling boss metaphor to illustrate why it is 
better to
get rid of stale packets for real time traffic, but also better to advance the 
TCP window
for non-real time traffic.  

I have also seen suggestions (perhaps what you're referring to) that in the 
case of highly asymetric links, it's best to get rid of stale TCP ACKs to 
avoid unnecessarily getting into congestion avoidance due to ACK starvation.  
I believe this is mentioned in one of the PILC drafts.

In any event, a head dropper is an algorithmic dropper which is placed _after_ 
the FIFO in the data flow and for which the algorithm is:
  await_FIFO_full_trigger;
  dequeue (packet, FIFO);
  return_packet_to_free_buffer_pool;

> standardizing a variable.
I think I'm ok with this approach.  But how to represent the multiple thresholds implied in AF?

Dan

---

From: Fred Baker <[email-masked]>
Date: Thu, 25 May 2000 12:35:28 -0700

>   return_packet_to_free_buffer_pool;

I know *what* a head dropper is. I'm saying I don't know of anyone who is 
asking for that in deployed product, and therefore needs one *managed*.

Again, willing to be convinced/corrected, but if our MIB supports features 
that are bright gleams in some random researchers eye and doesn't support 
deployed and recommended product, we are doing something that is blatantly 
stupid.

---

From: Fred Baker <[email-masked]>
Date: Thu, 25 May 2000 12:38:14 -0700

>thresholds implied in AF?

simple. They have different target queue depths, indexed by which action 
the traffic gets applied to it. We first try to control to AFx3's queue 
depth by dropping AFx3 traffic; if that doesn't work out, the drop rate for 
that approaches 100% because the queue depth is increasing, and we start 
trying to control to AFx2's target depth by dropping AFx2 traffic. If that 
doesn't work, we start trying to control to AFx1's depth by dropping AFx1 
traffic.

---

From: Dan Grossman <[email-masked]>
Date: Thu, 25 May 2000 16:45:33 -0400

> asking for that in deployed product, and therefore needs one *managed*.

I have heard tell of such a thing in one implementation (but would rather its
implementor speak for themselves).  I also cannot speak to implementations that
I might involved in.  However, speaking for myself, I think
that head dropping is a good thing for some scenarios, albeit a bit more 
difficult to 
implement.

> deployed and recommended product, we are doing something that is blatantly 

I think we can agree to disagree *respectfully*.

Dan

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 May 2000 12:47:44 -0700

At 04:45 PM 5/25/00 -0400, Dan Grossman wrote:
>I might involved in.

Sounds like more than one. OK, I won't argue too hard against it if it is 
real as opposed to research.

My point has to do with the disparity between the fact that this version of 
the MIB supports this, which I needed someone to tell me is actually in use 
by someone, and the fact that it doesn't support something which diff-serv 
standardizes and the IETF strongly recommends that people implement. The 
latter makes no sense to me.