Subject: [Diffserv] Counters in the classifier

From: Fred Baker <[email-masked]>
Date: Wed, 13 Dec 2000 10:19:46 -0800

I need to discuss with the working group the outcome of the discussion of 
Bob Moore's counter in the classifier. I believe that the working group 
came to an inappropriate decision, and I want to present my case. Yes, this 
should have happened in the working group meeting; I wound up wrapped 
around a Secretariat-shaped axle a good part of Monday, and made only a few 
minutes of that meeting.

First, IMHO, any discussion, anywhere, of a programmable counter is 
nonsense. In software, the difference between

	pointer = table->pointer_to_chounter;
	if (NULL != pointer) {
		pointer->packets ++;
		pointer->octets += packet->length;
	}

and

	table->counter.packets++;
	table->counter.octets += packet->length;

is three things: the indirection of the counter, and the pipeline stall in 
the branch, and several extra instructions. When you are trying to go 
quickly (say "OC-n"), each of these is important.

The corollary in hardware is that one rarely builds indirections and such 
there; you can define memory for a register set, link them together, and 
provide optional adders, but reality is that it is less silicon, and 
therefore cheaper and less complex, to simply implement the register.

As a result, any discussion of an optional counter is not an option as to 
whether it will be counted - it is cheaper, simpler, and faster to 
implement the counter. This is an option of whether to display it.

There is an additional cost, also - a round trip. I can't tell to read 
counter foo about classifier bar unless I know that counter foo and 
classifier bar are related. If I can read the classifier and get the 
counter with it, that is one SNMP GET. If I read a rowpointer and then have 
to again read to get the counters, that's two round trips. That may not be 
important conceptually, but operationally, when debugging a device across 
the network and knowing that my classifier is potentially not doing the 
right thing and trying to figure out what it is doing, this is a lot more 
than "so turn on classifiers for the various options and see which one 
counts". It is "turn on classifiers for the various options, attach 
counters to them, and then to see which one counts go read the individual 
counters back." It may mean nothing to a vendor, but to an operator whose 
primary job is making the PCs (which outnumber routers 40:1) work, and is 
now doing his secondary job of making the router work, and by the way has 
other pressing demands, it is unnecessary complexity, time, and so on. Go 
buy Randy Bush a drink some time and get him to explain what his problem 
with diff-serv, SNMP, policy, MPLS, and a list of others things is: the 
discussion will revolve around "simpleness is next to godliness" with a 
liberal dose of "this is just plain not simple."

I'll go further. Every counter costs something, and what is above is two 
counters. We have had a rule in MIB design for at least the past 15 years 
(RFC 1493 includes a short discussion of this) that we try to avoid having 
more than one counter in any data path, and we make an exception for normal 
data throughput because there is a strong need to know both octets and 
packets arriving and departing on an interface. Any extra counter gets a 
strong push back from network managers, because they want to know what they 
are supposed to do when it counts. What this counter is for is debugging 
classifiers; you want to know whether something is arriving, and then see 
what happens to it later. I understand packet counters here, but I don't 
understand an octet counter. If you argue it based on rates, that's what 
the meter is for later in the TCB, and the rate through one classification 
doesn't necessarily correlate with the aggregate being handed to that meter.

What I see here is a pretty expensive piece of technology with no obvious 
benefit. I see extra complexity (in the indirections) that costs more than 
it produces in benefit. I predict partial implementations or failure to 
implement. Both are bad. You just want a packet counter in the classifier 
and be done with it. Going with an indirect dual counter to determine 
whether a classifier is finding anything to classify is creeping elegance 
at its worst.

I can make the same argument for the counter action itself; there is no 
general need for the octet counter, and it is something you are always 
going to configure, at least operationally. But I'm not going to push that, 
as we have had that discussion in the past.

The remaining concern is for people with diffserv implementations who don't 
have this counter. For the record, in some of my products, I'm one of them; 
this is not a position where I am driving vendor interest. But in other of 
my products, I have a counter on every access list (a form of classifier), 
which is there to enable the network operator to debug his access lists. It 
is my understanding that this is essentially what this proposed counter is 
for. I can tell you that, to my knowledge, no customer has ever asked for 
rates on the classifiers themselves; they have asked for rates in other 
contexts, but not bit or byte rates on access-list hits. "matching packet" 
counters seem to be quite adequate for this job. In the diffserv 
architecture, if we *do* need a meter for an SLA, it is not the classifier 
we will do that on, but on a meter or an action.

So this is my proposal. Kwok and I are editing the MIB this morning, with a 
view to this outcome, Andrew's comments, and some comments from Bert 
relating to TCs (want to pull them together into a separate module and do 
some minor tweaks). We will put in a packet counter in the classifier, and 
the chairs can tell us we did it wrong.

Your comments, please.

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 13 Dec 2000 14:26:31 -0800

Fred Baker wrote:
...
> the chairs can tell us we did it wrong.

Fred, I think what you are saying reflects what we talked
about before Monday's meeting: you have to set up a classifier
if you want to count (a particular DSCP for example). If
this is so, I certainly support that and thought we emerged
from that meeting with out any real case made for anything
else.

	Kathie

---

From: Andrew Smith <[email-masked]>
Date: Wed, 13 Dec 2000 15:54:45 -0800

This does, again, beg the question of having even more overlap with what the 
DSMON MIB (in the RMON WG) does.

I'm also a bit confused as to whether Fred's proposal *replaces* the existing 
"counter action" material in the MIB or is in addition to it. And is this 
addition/change expected to be rolled back into the Model draft also?

Andrew

Kathleen Nichols wrote:

> ....

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Dec 2000 18:46:19 -0600

I would prefer that the model is not that specific about how counters
are implemented, but if it is, then it needs to be consistent.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Dec 2000 12:30:49 -0800

At 03:54 PM 12/13/00 -0800, Andrew Smith wrote:
>I'm also a bit confused as to whether Fred's proposal *replaces* the 
>existing "counter action" material in the MIB or is in addition to it. And 
>is this addition/change expected to be rolled back into the Model draft also?

it is in addition, and it need not be in the model. it is a debug tool for 
the classifier; the count action is an accounting tool of sorts for the SLA.

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 15 Dec 2000 13:02:19 -0500

This is in DSMIB-07 right now, containing only the packet counter as
we agreed, in diffServClfrElementTable entry.
Speak now or hold your peace :).
-- Kwok --

At 02:26 PM 12/13/00 -0800, Kathleen Nichols wrote:
>Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

From: Andrew Smith <[email-masked]>
Date: Fri, 15 Dec 2000 18:32:49 -0800

And the intent is for implementation to be optional for RFC 
conformance/compliance purposes, correct? (of course it might become mandatory 
for commercial compliance :-))

Andrew

Fred Baker wrote:

>> existing "counter action" material in the MIB or is in addition to it. 
>> And is this addition/change expected to be rolled back into the Model 
>> draft also?
> 
> 
> it is in addition, and it need not be in the model. it is a debug tool 
> for the classifier; the count action is an accounting tool of sorts for 
> the SLA.
> 
> 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Dec 2000 00:39:07 -0800

At 06:32 PM 12/15/00 -0800, Andrew Smith wrote:
>conformance/compliance purposes, correct? (of course it might become 
>mandatory for commercial compliance :-))

Nope. I don't do optional variables. It just means that many current 
implementations (including some of mine) are not quite compliant.

---

From: Andrew Smith <[email-masked]>
Date: Tue, 19 Dec 2000 08:42:06 -0800

I'd object strongly to this change then - I'd like to see quite a lot more 
support for this idea before declaring WG consensus on this change. Making 
"debug counters" a mandatory part of a MIB like this is not a good way to do 
standards.

Andrew

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Dec 2000 09:56:21 -0800

At 08:42 AM 12/19/00 -0800, Andrew Smith wrote:
>"debug counters" a mandatory part of a MIB like this is not a good way to 
>do standards.

I am, therefore, looking for supporting or negating commentary from the list.

My reason for not doing "optional", by the way, is historical.

First, a design guideline we have always followed with SNMP MIBs has been 
to avoid optional objects - maybe you provide a read-only and a read-write 
implementation option, or you say that a MIB covers several classes of 
systems, and if you are doing a system of class A then you need groups {A}, 
but that would rarely apply to individual objects.

Second, a large part of the problem with OSI protocols was the number of 
options. Options were used in that design process as a way to gain 
consensus - if I don't have to do it, I will be less inclined to vote "no". 
However, it very quickly became difficult to come up with a subset of any 
given protocol wherein any two vendors were interoperable. This was OSI's 
Achilles Heel. That's not where we want to go with IP standards.

Third, implementing this using a redirection to an optional object, as was 
proposed in the working group meeting, has the ills I mentioned in a 
previous email. It might make for working group consensus on the basis of 
"I don't actually have to implement it", but it makes for an operational 
headache beyond interoperability. At the end of the day, we're not building 
this for the working group, we're building it for the operators. We need to 
give them a usable product.

Fourth, if something is truly optional, then it is not truly needed, and 
another design guideline for SNMP MIBs has always been to leave out that 
which is unnecessary. If it is truly optional, then it doesn't belong in 
the MIB.

So, I don't care whether it is in or out. Somebody wanted it and argued for 
it, and the working group decided to accept it. I understand, I think, why 
they want it, and I buy the argument. If we can pick one - it is needed and 
should be in, or it is not needed and should be out - I'm happy. I just 
want a product the network operators can use when we're done.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Dec 2000 13:02:52 -0600

Here are the raw notes from the discussion in San Diego:

> MIB issues:
> 
> *** Issue: add separate DSCP counters
> (pros, cons on Kwok's slide)
> 
> Open questions
> - add DSCP counter table (proposal: no)
> - Add counter to ClfgElementTable entry
> 
> 1st question - call for opinions. none strongly in favor, no discussion.
> 
> 2nd question - add counter. call for opinions, scattered support for each, no
> loud noises. Proposes to go to list, wait three days for input.
> 
> Brian - please lets put a specific resolution in the documents.
> 
> Walter - worries that in some environments it would be impossible to have
> counter in classifier. Thus wants counter to be optional.
> 
> ??? - yes please
> 
> Kwok - OK - pointer in table, reuse counter.
> 

Since then Fred has argued against using pointers, and we certainly don't have
consensus on compulsory counters, or on optional coounters. I feel that the
only reasonable resolution at this point is to leave it out for future (or
proprietary) extension.

  Brian

---

From: Steve Blake <[email-masked]>
Date: Tue, 19 Dec 2000 13:49:10 -0500

> I am, therefore, looking for supporting or negating commentary from the list.

I am opposed to adding counters to the classifier.  If an implementor
wants to instrument their data path in that way, it is already possible
using one or more counter actions.  Built-in classifier counters would be
inconsistent with the prevailing style of the MIB.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                  (919)472-9913

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Dec 2000 17:49:24 -0800

>only reasonable resolution at this point is to leave it out for future (or

works for me