Subject: Re: Collaborative work (acct/meas for charging)

From: Nevil Brownlee <[email-masked]>
Date: Thu, 4 May 2000 12:30:41 -0700 (PDT)

Hello Marcelo:

[ ... following up on an earlier suggestion about defining an interface
  for changing a running ruleset on an RTFM meter ... ]

> 	I think we could start defining two interfaces (Reader and Manager). See
> my other email. I think this is a strong argument to carry this work in the
> RTFM working group. What do you think?

I've had a chance to think about this a bit more carefully.  I agree it's
a good work item with which to re-activate the RTFM WG.  It would also
fit in quite well with some work being done by Tanja Zseby at GMD Fokus
(have a look at http://pam2000.cs.waikato.ac.nz/pdf_papers/P005.pdf).

However, it isn't going to be all that easy to define these interfaces in
a way which fits neatly into the SNMP Meter MIB (RFC 2720).  The way the
MIB is written now, to download  a ruleset you have to 
<quote>    - Locate an open slot in the RuleSetInfoTable.
           - Create a RuleSetInfoEntry by setting the status for this
               open slot to createAndWait(5).
           - Set flowRuleInfoSize and flowRuleInfoName as required.
           - Download the rules into the row's rule table.
           - Set flowRuleInfoStatus to active(1).   </quote>

Once the ruleset is safely installed on the meter you can start a task
to use it (by creating a row in the Manager Info Table), at which point
it's an  'running' ruleset.  After that you can't make it inactive, or
change it, until all the tasks using it terminate.  Once the ruleset is
inactive you can mark it inactive in the Rule Info Table, then change
row within it.

However, that's how it is right now.  As I understand it, what you
want to do is to introduce a new status for a ruleset, in which it
can be modified even if it's running.  That could be done by introducing
a new object in the RuleInfoTable to indicate that the ruleset is
'modifiable' by the manager which created it.

The next issue is, what kinds of modification could be allowed?
Right now the MIB says 
<quote>
-- Although an individual rule within a RuleSet could be modified,
-- it is much safer to simply download a complete new RuleSet.
</quote>
The meter makes no attempt to verify that any ruleset is valid, in the
sense that it actually does something useful - that's left to the RTFM
manager, SRL compiler and/or person creating the ruleset.

I can see two ways to handle this.  To change rulest (x), 

A) Download a complete new ruleset (y) incorporating all required changes,
   then change the Manager Info Table (in one operation) so that all
   refernces to (x) refer to (y) instead. 

or

B) Download information about the rows to be changed, then have a single
   operation which makes all the changes.

(B) would require significant changes to the Meter.  Also one would
   need to create rulesets in which individual rows could be changed
   without changing the logical execution paths through the ruleset.
   For example one could have a ruleset with large sections which
   test, say, DestPeerAddress, with the same mask for a set of
   specified addresses.  One could make those sections bigger than
   needed (with carefully-chosen dummy entries), then overwrite them
   later.  Great care would be needed to do it right.

(B) is much safer and simpler, but it could be expensive downloading
   a whole ruleset if only one or two rows are to be changed.

Also, the manager will need to inform the reader(s) collecting data from
the changed ruleset, so that their data files have some marker within
them to record when the changes happened ...

So, how often do we want to be able to make such changes?  Every hour,
every 10 minutes, or what?  And roughly how many rules within the set are
likely to be altered on each change?  

As I said, this is going to take a lot of careful thinking to get it
right.  Still, it certainly would be useful, so let's get started.
If we can discuss it for a while on the list, we (you and I) can
write a draft explaining what's needed and how it could be done -
that's what we need next.

Cheers, Nevil

-------------------------------------------------------------
   Nevil Brownlee                     Visiting Researcher
   Phone: (858) 822 0893                 CAIDA, San Diego

---

From: Marcelo Pias <[email-masked]>
Date: Thu, 11 May 2000 18:23:46 -0300

Hello All,

	I had some time to think carefully about this interface. First, I'd like
to comment the email below.

>inactive you can mark it inactive in the Rule Info Table, then change

The Meter finds that a ruleset is not being used anymore checking the
fields CurrentRuleSet and StandbyRuleSet in the flowManagerInfoTable  for
the manager that owns the ruleset. If these fields contain 0, the ruleset
is not in use. Is that correct?

>can be modified even if it's running. 

Correct! Further, I want to define generic operations to make this changes
on the fly.

 That could be done by introducing
>'modifiable' by the manager which created it.

Right. I'd suggest two modifications in the Meter MIB. One is the addition,
as you said, of a new attribute in the flowRuleInfoIndex:

1) flowRuleInfoChangeable - to indicate whether this ruleset can be changed
by its owner or not.

	The second would be the creation of a new status for the
flowRuleInfoStatus. This is to indicate that a ruleset is being modified by
its owner (Manager):

2) flowRuleInfoStatus - activate,...., "CHANGING"

	Although we could assume any ruleset to be changeable and cut off the item
1 above. I'm not sure about this yet...
 
>manager, SRL compiler and/or person creating the ruleset.

That's very good. Actually, we could push as much as possible the
intelligence to the Manager and Reader Interfaces implementation and leave
the Meter with minor modification.

>   a whole ruleset if only one or two rows are to be changed.

I'd say that we could leave this decision to the Manager Interface
implementation. Maybe, the Meter could provide some meta data (attributes
from RuleSetInfoEntry) about a specific RuleSet.

Suppose we have defined an operation in the Manager Interface called
addRule which is responsible to add a new rule within a ruleset. For
instance, if the implementation of this operation decides it should upload
a new ruleset as the number of changes to be made whithin the ruleset are
close to the total number of rules, it could choose the option B. 

On the other hand, if the change is in a few rules of the ruleset, the
addRule implementation can choose the mechanism A.

What I'm proposing is a separation of the Manager interface from its
implementation. 

>likely to be altered on each change?  

	We could offer changes within rulesets very often although a minimum time
interval since last modification may be specified. And also, we could
provide any number of changes within the ruleset through this interface.
It'll be a task for the Interface implementation to use A or B mechanisms
to accomplish this modification according to relation between number of
changes and total of rules.

>that's what we need next.

That's fine. After some discussion in the list, we could start writing the
requirements. My other email explain some ideas.

I would appreciate comments on this email.

Cheers. Marcelo

-------------------------------------------------------------------
   Marcelo Pias, PhD Student funded by British Telecom Labs
   University College London (UCL), Department of Computer Science 
   URL: http://www.cs.ucl.ac.uk/staff/M.Pias/
-------------------------------------------------------------------