Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers

From: Fred Baker <[email-masked]>
Date: Thu, 27 Sep 2001 03:29:31 -0700

At 01:38 AM 9/27/2001, Juergen Schoenwaelder wrote:
>I think there is another option: Require that the agent keeps
>reference counters internally and that requests to destroy rows will
>result in an error if there are still pointers to this row.

Here is a proposed approach to that. Tell me if it works for you.

Section 4.3 is modified in this way:

>4.3.  Conceptual row creation and deletion
>
>A number of conceptual tables defined in this MIB use as an index an
>arbitrary integer value, unique across the scope of the agent. In order
>to help with multi-manager row-creation problems, a mechanism must be
>provided to allow a manager to obtain unique values for such an index
>and to ensure that, when used, the manager knows whether it got what it
>wanted or not.
>
>Typically, such a table has an associated NextFree variable e.g.
>diffServClfrNextFree which provides a suitable value for the index of
>the next row to be created e.g. diffServClfrElementClfrId. The value
>zero is used to indicate that the agent can configure no more entries.
>The table also has a columnar Status attribute with RowStatus syntax
>[6].
>
>Generally, if a manager attempts to create a row, the agent will create   |
>the row and return success. If the agent has insufficient resources or
>such a row already exists, then it returns an error. A manager must be
>prepared to try again in such circumstances, probably by re-reading the
>NextFree to obtain a new index value in case a second manager had got in
>between the first manager's read of the NextFree value and the first      |
>manager's row-creation attempt.
>
>To simplify management creation and deletion of rows in this MIB, the     |
>agent is expected assist in maintaining its consistency. It may           |
>accomplish this by maintaining internal usage counters for any row that   |
>might be pointed to by a RowPointer, or by any equivalent means.  When a  |
>RowPointer is created or written, and the row it points to does not       |
>exist, the SET returns an error. When a RowStatus variable is set to      |
>'destroy' but the usage counter is non-zero, the SET returns no error     |
>but the indicated row is left intact.                                     |
>
>The use of RowStatus is covered in more detail in [6].                    |

In addition, various RowStatus variables (all except 
diffServDataPathStatus) get the following description:

>        "The status of this conceptual row. All writable objects in this   |
>        row may be modified at any time. Setting this variable to          |
>        'destroy' when the MIB contains one or more RowPointers pointing   |
>        to it has no effect."

Is that what you mean? And is that a good approach for us?

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Sep 2001 12:47:47 +0200

>>>>> Fred Baker writes:

Fred> Here is a proposed approach to that. Tell me if it works for
Fred> you.

>but the indicated row is left intact.                                     |

Fred> Is that what you mean? And is that a good approach for us?

I think the agent should return an inconsistentValue error in both
cases. I also think that this is inline with RFC 2579 note (7) on page
10. Not returning an error means that the manager has to poll again
each time it tries to delete a row.

Otherwise, the text covers pretty much what I had in mind.

/js

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 Sep 2001 05:16:51 -0700

At 03:47 AM 9/27/2001, Juergen Schoenwaelder wrote:
>cases.

that works for me in the case where a RowPointer is set to point to a 
non-existent object.

I have a usability concern in the RowStatus case, however. Suppose that I 
wanted to remove a classifier. That classifier consists of:

         one classifier entry
         N classifier element entries
         N MultiField filter descriptions.

So the logical thing for me to do is send a single SET with 2*N+1 RowStatus 
variables, all set to "destroy".

Suppose, however, that N/2 of the MultiField filter descriptions were 
re-used by someone else. Since I don't know that, as I understand SNMP 
processing, each time I send the SET I will get back an error and a pointer 
to the offending VarBind. I will therefore send the SET N/2 times, getting 
back that error and removing the indicated RowStatus variable, and then 
finally send a SET that takes effect.

This seems to me a colossal waste. Wouldn't it be better to swallow those 
errors, and simply remove the rows that could be removed at the time?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Sep 2001 14:50:44 +0200

>>>>> Fred Baker writes:

Fred> I have a usability concern in the RowStatus case,
Fred> however. Suppose that I wanted to remove a classifier. That
Fred> classifier consists of:

Fred>          one classifier entry N classifier element entries N
Fred> MultiField filter descriptions.

Fred> So the logical thing for me to do is send a single SET with
Fred> 2*N+1 RowStatus variables, all set to "destroy".

Fred> Suppose, however, that N/2 of the MultiField filter descriptions
Fred> were re-used by someone else. Since I don't know that, as I
Fred> understand SNMP processing, each time I send the SET I will get
Fred> back an error and a pointer to the offending VarBind. I will
Fred> therefore send the SET N/2 times, getting back that error and
Fred> removing the indicated RowStatus variable, and then finally send
Fred> a SET that takes effect.

Fred> This seems to me a colossal waste. Wouldn't it be better to
Fred> swallow those errors, and simply remove the rows that could be
Fred> removed at the time?

Perhaps. I was concerned about rows that hang around without any other
rows pointing to them anymore and where the manager(s) think the row
has already been successfully deleted. This basically requires that
managers implement a kind of garbage collection mechanism which
destroys rows which have already been destroyed but still hang around
in the agent.

Another option: If a manager sends a destroy but the agent can not
remove the row since it still is being referenced, then it reports
success and sets a flag which causes the agent to destroy the row as
soon as the reference count comes down to 0. So it becomes the agent's
job to clean things up and the 'destroy' more or less becomes as
'release' operation.

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Sep 2001 09:29:05 -0400

It seems to me that this is a general SNMP problem that was introduced and 
ignored when row pointers were introduced into SNMP.  (Quite possibly 
properly ignored.  It may well be that the right answer is "do nothing".) 
As such, I really think it is NOT the diffserv working groups job to craft 
and introduce a solution to this problem.  The proposed solutions have 
signficant impact if used as a model for other MIBs, and I think that if 
this problem is to be address, EoS would be the place to discuss it, not 
diffserv.  This was not a fatal flaw in other MIBs that have row pointers, 
so I conclude that we have merely surfaced a general issue by putting more 
weight on an existing mechanism.

Yours,
Joel M. Halpern

>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Sep 2001 16:38:34 +0200

>>>>> Joel M Halpern writes:

Joel> The proposed solutions have signficant impact if used as a model
Joel> for other MIBs, and I think that if this problem is to be
Joel> address, EoS would be the place to discuss it, not diffserv.
Joel> This was not a fatal flaw in other MIBs that have row pointers,
Joel> so I conclude that we have merely surfaced a general issue by
Joel> putting more weight on an existing mechanism.

DiffServ makes extensive use of RowPointers so I think it is
appropriate to address the issue for the DiffServ MIB. This
does not mean that the DiffServ solution (whatever that will
be) must be adopted by other WGs.

Generalizing the problem and putting it into other WG charters will
not help us getting interoperable MIB implementations for DiffServ any
time soon. RMON is another classic example of a WG which had to
address several more fundamental SNMP issues just because there was no
general solution available when RMON needed them. I do not see this in
principle as a problem.

Fred is trying hard to come up with a good MIB and I think it would be
wrong to delay the forward progress in coming up with a robust MIB
definition which will hopefully lead to interoperable implementations
on agents and managers.

/js

---

From: "Andrew Smith" <[email-masked]>
Date: Thu, 27 Sep 2001 12:58:29 -0700

That may be true but overloading "RowStatus" and "RowPointer" with
multiple-reference semantics would be a confusing approach, I think - I'd
suggest this needs a new TC if we choose to do it.

But you wrote that "I was concerned about rows that hang around without any
other rows pointing to them anymore" but I think that the burden of deciding
if this is the case (and of deciding if it is then appropriate to delete the
offending row) should be on the "manager" not the "agent". We already have
language to define what happens if there is a dangling reference so there
should not be a need for the agent to keep reference counters, at least not
for the purposes of deciding when a "destroy" works or not - of course
agents *may* well use reference counters internally to decide e.g. when to
push/pull a filter entry to/from hardware.

My 2c.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Juergen Schoenwaelder
Sent: Thursday, September 27, 2001 7:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Diffserv] comments from Dave Perkins regarding RowPointers

/js

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Sep 2001 15:17:36 -0500

It seems to me that returning a fault on attempting to delete something
that has an outstanding reference is an implementation issue. I don't see
it as something that should be reflected in the MIB itself. And if it's
an implementation issue, it sounds like a SHOULD to be inserted somewhere
generic. As in
   SHOULD return an inconsistentValue error

Also as WG Chair I will object to this MIB being held up to resolve
a generic problem - whatever solution applies here SHOULD apply to
every MIB with row pointers.

   Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Sep 2001 11:56:34 +0200

>>>>> Brian E Carpenter writes:

Brian> Also as WG Chair I will object to this MIB being held up to
Brian> resolve a generic problem - whatever solution applies here
Brian> SHOULD apply to every MIB with row pointers.

I fail to parse that. Please explain.

/js

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Sep 2001 10:47:16 -0500

Juergen,

I mean we should not further delay this MIB, which is a year late.
If there is a generic problem with dangling row pointers, the O&M
area should go away and fix it separately, imho.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
Board Chairman, Internet Society http://www.isoc.org