Subject: [Diffserv] We think this is the MIB edits that we are supposed to do

From: Fred Baker <[email-masked]>
Date: Thu, 03 Aug 2000 16:53:01 -0400

So the authors are trying to determine exactly what the editing instructions
are for the MIB. Let me state what we think they are and see if we all agree.
If we do, then this is exactly the edits we propose to do, and then present
the MIB for last call.

(1) following Joel's suggestion, we are going to change the indexing of all
tables. The tables will uniformly each have a single enumeration as their
index, with two exceptions. The first exception is the classifier table; it
will be enumerated by an enumerator and a TCB number, so that we can
unambiguously say what classifier a particular test applies to. The second
is the meter, which I will talk about below.

(2) further to that, we will come up with a "first TCB on an interface"
table, indexed by ifIndex and direction, which contains a RowPointer to the
first Classifier/Meter/Action/Queue in the first TCB that will apply. An
entry which is not specified - common on the ingress side - will simply mean
"no diff-serv action, do the usual forwarding".

(3) for open item 23, this was essentially a debate between Andrew, Keith
McCloghrie, and myself about whether the Random Drop Entry needed a
RowStatus variable. Kwok and I believe it does, and barring contention we
will leave the entry as it is, having a RowStatus variable.

(4) for open item 16, this is a philosophical disconnect among some of us
regarding counters. I observe that in implementation, the counter is either
there and counting in every case or it is not there at all. In a driver or
an ASIC, I am not likely to conditionally allocate the space for the counter
or conditionally increment it. So the question is not whether the device
will count, it is whether the counter will be accessible by network
management. I believe that one of the key values of diff-serv is the
management information (billing information) that derives from these
counters, so I believe that one wants to always externalize them. But... the
way the actions are specified in the MIB, configuring a Count Action is
optional, and could conceivably occur anywhere in a list of actions. I think
that is unfortunate at best, but it's not obvious how to cleanly do what I
consider to be "the right thing" in the current structure.

To resolve this, we propose to put some text into the MIB specification (it
could be in the DESCRIPTION of the counter action or in the prose portion of
the document) bringing out this tension and recommending that count actions
always be configured (the set of actions applied to a stream of traffic -
such as the red output of a meter - is never null, and must always contain
at least a count action), and that the count action be the first in the list.

(5) there was an open item from the Adelaide meeting regarding meters, which
got overlooked in the editing, and which relates to the discussion of models
among the authors of the MIB and Model drafts in preparation for this
meeting. The issue is that some feel it is difficult to build a TRTCM (RFC
2698) meter using the MeterEntry and TBMeterEntry as it exists, and we
agreed to look at how we might explicitly build a multi-rate meter.

So here's a suggestion: flame now, give me a better idea, whatever.

Suppose that we design the MeterEntry and TBMeterEntry so that we have a
single meter which has a set of subsidiary rates and colors. By definition,
there is exactly one more color than rate, and the way that the rates and
colors relate is as specified in some RFC, notably 2697/2698.

So the entries wind up with these objects:

	diffServMeterEntry
	INDEX {diffServMeterId}
	DiffServMeterEntry ::= SEQUENCE  {
	   diffServMeterId            Unsigned32,
	   diffServMeterSpecific      RowPointer,
	   diffServMeterType          INTEGER {
                                         other(1),
                                         srtcmBlind(2), -- SRTCM, Color-blind
                                         srtcmAware(3), -- SRTCM, Color-Aware
                                         trtcmBlind(4), -- TRTCM, Color-blind
                                         trtcmAware(5)  -- TRTCM, Color-Aware
                                      }
	   diffServMeterStatus        RowStatus
	}

	diffServTBMeterEntry
	INDEX {diffServMeterId, diffServTBMeterSpigot}
	DiffServTBMeterEntry ::= SEQUENCE  {
	   diffServTBMeterSpigot            Unsigned32,
	   diffServTBMeterSucceedNext       RowPointer,
	   diffServTBMeterRate              Unsigned32,
	   diffServTBMeterBurstSize         BurstSize
	   diffServTBMeterStatus            RowStatus
	}

The rule is, as specified in the Metering RFCs, the first N-1
diffServTBMeterEntries enumerate rates and colors; the last simply
enumerates a color, where by "color" I mean a set of actions to apply to the
traffic which include counting and probably marking with a DSCP. The hard
part here is deciding which color to apply to which case, as it isn't
obvious. For example, you want to wind up, in the color-blind case of TRTCM,
if the peak fails making the traffic red, if the peak succeeds but the
committed fails then update the peak token bucket and mark the traffic
yellow, and otherwise update both token buckets and mark the traffic green.
I submit that the simplest rule is that the diffServTBMeterSpigot enumerates
the colors (RowPointers) in that order.

This approach will make Steve Blake happier with me, although I continue to
observe that Frame Relay vendors routinely specify burst sizes smaller than
an MTU, and TCP traffic patterns have no relation to evenly spaced constant
bit rate streams, or even VBR streams :^)

(6) Kwok and I have a sense that there is a strong need for some text of the
form "this is what the designers of the MIB had in mind; if you want to
achieve <this> then do <that>." For example, the question has come up just
how one implements a scheduler that combines priority and WRR/WFQ amng a set
of queues. Of course, the way you do it is by having two sets of queues
feeding into two WRR schedulers, and feed the outputs of those through a
priority scheduler, or in the case that you have only one priority queue,
feed that queue directly into the second scheduler. We think this needs to
be written down somewhere *related*to*the*MIB*. The question is not "what is
the model" but "how does the MIB implement the model". So we propose to put
some specific examples into the MIB document (that particular one was there,
but got moved to the model). We will also write some general "how to use
this" text. If folks have particular suggestions of what might be good
constructs to spell out besides the TRTCM-Color-Aware Meter and this
particular scheduler, a private note to the authors would be appreciated.

RFC 2697
      A Single Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999.
RFC 2698
      A Two Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999.

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 04 Aug 2000 15:53:04 +0200

Fred,

> counters, so I believe that one wants to always externalize them. But... the

I agree.
To those doubting the usefulness of counters in the MIB: counters are
also highly required for monitoring the network, which is very important
to detect various problems, e.g., one of the following kind:
suppose some first-hop-router in the stub domain marks packets wrongly 
for a higher level PHB (e.g, by misconfiguration) and no resources were
actually allocated along the path for this particular flow. Then some DS
domain downstream may have to drop packets (also affecting other flows)
within an aggregate at an egress boundary router due to resource
shortage for this BA at a particular link. Although every aggregate may
still be in conformance to its profile at this domain's ingress points,
the "misbehaving" flow adversely affects other flows by unexpectedly
consuming resources along some "new" (yet underprovisioned) path.
Therefore, counters can indicate that there is a problem within the
domain, even if its cause is beyond the provider's responsibility. To
identify the non-admitted flow subsequently is another difficulty...

As far as I've seen there are some DSCP counters in the proposed
rmonmib-ds, but it would be useful to have them (and other various
more specific counters) also in the diffserv-mib.

Best regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, F.R. of Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
Phone: +49 721 608-6396 Fax: +49 721 388097

---

From: Harrie Hazewinkel <[email-masked]>
Date: Fri, 04 Aug 2000 07:18:36 -0700

HI All,

I have found some additional problems in the DIFFSERV-MIB.

1) The table DiffSerActionTable and the DiffServAlgDropTable
have both an 'NEXT' object defined. This can create an inconsistancy
when  'diffServActionNext (RowPointer) and 'diffServAlgDropNext
(RowPointer)
point to to different datapath elements.
 I would recommend that the 'diffServAlgDropNext' will be deleted.

2) The connection from the specific meter tables (like
'diffServTBMeterTable towards the 'diffServMeterTable'
is broken.
Currently they are combined via a common shared index
as well via the 'diffServMeterSpecific'. One would quickly
assume that equal indexes in the 'diffServTBMeterTable' and
the 'diffServMeterTable' are associated. However, via the
'diffServMeterSpecific' can point to something completely else.
IMHO, this creates ambiguity.

I would recommend that the 'diffServTBMeterTable' will have its
own priovate single integer index "INDEX { diffServTBMeterIndex }"
and _NOT_  "INDEX { ifIndex, diffServMeterIfDirection, diffServMeterId
}".

In addition text needs to be added that specific meter tables
are associated with the 'diffServMeterTable' via the
'diffServMeterSpecific'.

3) The same problem as explained in point 2 (see above) applies also for
the
action tables. Example, 'diffServActionTable' and the
'diffServAlgDropTable'.
I would recommend a similar solution as point 2 (see above)

NOTE: The 'diffServDscpMarkTable has already its own single integer
(private)
index. The 'diffServCountActTable' needs to keep the equal indexing
scheme as
the 'diffServActionTable'

Hoping I explained it well enough otherwise I will expand it
futher with examples. Just let me know.

Harrie
0- Harrie Hazewinkel ---------------------------------------0
 mailto:[email-masked]            phone:+1-415-536-5221
0-----------------------------------------------------------0

---

From: Kwok Ho Chan <[email-masked]>
Date: Fri, 04 Aug 2000 10:34:52 -0400

Harrie:
Thanks!
As we spoke on the hallway of the Pittsburgh IETF, I think
the moving of the indexes (ifIndex, ifDirection) into a "datapath starts here"
table entries may fix some of the issues you raised.  I will take your
suggestions
and make sure the issues are resolved, and will be talking to you in more
detail next
week to confirm this.
Thank you very much.
-- Kwok --

---

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 07 Aug 2000 12:10:44 -0700

Hi all,

During the SNMPCONF interim meeting on friday
I made a picture of how the structure of the
DIFFSERV-MIB and the DIFFPOLICY-MIB.

Kwok as editor of the diffserv mib and others were interested
in having the pictures. They are now available at:

http://public.covalent.net/

Here you find 2 pictures.
	1) diffserv-mib.gif that represents the structure
	of pointers and links within the diffserv-mib.
	2) the diffpolicy-mib.gif that would represent a
	possible setup of the diff-serv mib for configuration.

With respect to the diff-policy-mib this will change a lot
especially since the indexing (which was broken) of the
diffserv-mib will be changed in the next release.

Hope this is useful for the diffserv-mib editors as well
the diff-policy-mib.

NOTE: it is possible that I made errors.

Harrie