Subject: Re: [Diffserv] Diffserv MIB - droppers

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

The Linux implementation, publicly available, implements several
Multi-level "RED-like" algorithms fit for AF PHB. We have WRED,
Generalized coupled Multi-level RIO as well as a decoupled one.
 
RED configuration was a small headache we had to worry about; the draft
<draft-almesberger-wajhak-diffserv-linux-01.txt>"Differentiated Services
on Linux" found at:
ftp://lrcftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.txt
although slightly dated (eg it doesnt show the ingress components)
will explain how we configure the different variants.
look at section 4.3 "sch_gred"

Sorry, dont have the time to go over the draft.

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:15:53 -0500

Jamal,

So what MIB parameters do you think are necessary for a RED dropper?

   Brian

---

From: jamal <[email-masked]>
Date: Wed, 31 May 2000 07:59:55 -0400 (EDT)

> So what MIB parameters do you think are necessary for a RED dropper?

For each of the MRED algorithms you need to be able to:
A) select it (among a set of such algorithms. In our case We have two: GRED
and GRIO and a small variation of the first one.)
B) Configure the associated FIFO with limits which are defined by 
either packet or byte counting (in our case we only do byte counting)
C) Select the number of "virtual Queues" within the physical queue.
(This is mostly for flexibility. In the case of AF one can assume
3 virtual queueus within a physical queue). For example if you have one
virtual queue within the physical queue, it reduces to the simple case
of classical RED. If you have two virtual queues within a physical queue
and have select the GRIO mode then it reduces to RIO with the IN/OUT 
defining the virtual queues. 
We have limited to 16 virtual queues, but your mileage may vary.

C) above is implementation specific whereas A) and B) are what i would
consider to be available generally.

For each of the above you need to configure the virtual queue parameters;
There is no way around this, unless you start making more specific assumptions.

Each of these virtual queues in some cases could be "a little RED" in itself.
We have made it generic such that you can couple the relationship between
the virtual queues or leave them independent of each other (since we wanted
to have the flexibility of service setup). The coupling is controlled
by a parameter we define as "prio" (expndable to priority).  You can think
of this as the reverse of precedence in CISCOs WRED. 

The virtual queue parameters also include:
0) a virtual queue identifier/selector
1) physical limit (again byte or packet counting)
2) min avg threshold
3) max avg threshold
4) defining the moving window queue weight, W. In our case to make
it intuitive we select to use the number of packets allowed to burst as the 
parameter to set because it is more intuitive. This is based on the 93
paper which limits the lower limit of W
burst + 1 - qmin/avpkt < (1-(1-W)^burst)/W
5) The drop probability
6) "avpkt" the average packet size in bytes foreseen
7) "bandwidth" the wire-speed of the interface being configured.

6) and 7) are implementation specific. 4) is needed but could be described in
a multitude of ways (eg CISCO-WRED with the "n" parameter, and some folks 
who use floating point who might want to describe it as floating point
number with information regarding the mantissa and exponent).

We configure things in two steps; first the shared MRED parameters 
A)-C) then followed by the virtual queue specifics (0-7).
However, since we have selectors in both A) and 0) things can
be configured in one step using the selectors/identifiers.

In case all that is still note clear here is an example of the policy
set (which could be done using an SNMP MIB ). This is an
example with virtual queue coupling for AF1*. 

----------------------------------------
# select GRIO mode with 3 virtual queues with virtual queue 2 as the default
configure gred setup DPs 3 default 2 grio

# --- AF Class 1 DP/VQ 1 min/max 15KB/45KB etc ---
configure 1 gred DP 1 limit 60KB min 15KB max 45KB burst 20 avpkt 1000 \
bandwidth 10Mbit probability 0.02 prio 2

# --- AF Class 1 DP 2---
configure gred limit 60KB min 15KB max 45KB burst 20 avpkt 1000 \
bandwidth 10Mbit DP 2 probability 0.04 prio 3

# --- AF Class 1 DP 3---
configure gred limit 60KB min 15KB max 45KB burst 20 avpkt 1000 \
bandwidth 10Mbit DP 3 probability 0.06 prio 4

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

All the above settable parameters are retrievable in addition to the 
current values that dynamically change 

+per AF Class paramter values:
(Physical queue limit, total packets/bytes, the amount out of the total that 
have been dropped)
+per virtual queue dynamic values:
-the current virtual queue size 
-the physical queue.
-total packets/bytes, the amount out of the total that have been dropped)

If i could rant for a sec:
Unfortunately most people on the list seem to be preaching their own
version of the truth (based on some specific implementation). You need to
get away from that. It is sad to see that the compromise seems to be
heading towards a really silly direction of "lets leave RED out of this".
I suggest maybe you need a bakeoff of some sort before you close this
document. Keep this document open!

cheers,
jamal

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 31 May 2000 10:04:49 -0700

Jamal,

One of the problems with getting too specific about
how people set/interpret the various RED parameters
can be seen in two of your recent emails to the list.

First, you said you pick the "queue weight" to "select
the number of packets allowed to burst":

jamal wrote:
...
> burst + 1 - qmin/avpkt < (1-(1-W)^burst)/W

This interpretation would derive from using consecutive
packet arrivals (with no idle time) to run your RED
algorithm. This was the approach that was used in
the simulations and the development of the 93 Floyd
and Jacobson RED paper. There is a mention of using
the "sampled queue" approach in that paper, but the
algorithm and parameters are not developed for that
assumption.

Then, in your next email, you say:

> 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.

For a variety of reasons, this is our preferred approach
and the one we've been working on the past couple of
years. In this case, the "queue weight" type of parameter
has, of necessity, a slightly different interpretation.
So it's important to NOT make any implementation-specific
statements about parameter setting. (For example, consider
sampling queues for high-speed links at times on the
order of 1 ms.)

	Kathie

---

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

Kathie,

> can be seen in two of your recent emails to the list.

[..]

So in general i agree with you but it seems tricky to ignore some
implementation specifics in the case of some _very important_
parameters. 

ones i have seen being kicked around are:

-  the time constant, w or some concept used for its derivation can be
visualized/represented in a variety of ways to the network manager: 
  +as a floating point number, 
  +as the negative log 2 number, 
  +as a "queue sampling time"  
  +and as i just described in my earlier post using the "burst" parameter. 

- the drop probability; 
+if you time sample offline then it is possible to say to the data path
"drop after x packets" (refering to Van's presentation to NANOG which i
think is the scheme Fred is preaching)
+if you use the ns-like implementation then in the simple case you do
actually roll the dice in the fast path

So the dilema is: you cant leave these parameters out and neither can you
ignore the existence of "implementation specifics"
If inter-operability is key then there should be some compromise; imagine
multiple vendor boxes and some poor ISP network manager trying to get a
service created inter-operating them ;-<

cheers,
jamal