Editor's Note: Minutes received 12/7/92
CURRENT_MEETING_REPORT_
Reported by Henry Clark/OARnet
Minutes of the Operational Statistics Working Group (OPSTAT)
Agenda
o Review of Client-Server Specification.
o Resource Utilization Criteria.
o Milestones/Goals Review.
o Statistical MIB.
Client-Server Protocol
Bernhard reviewed the client-server paper sent to the mailing list
several weeks ago. The commands within the protocol include:
1) LOGIN <username> <password>
2) HELP <object>
3) LIST <object>
4) EXIT
5) SELECT <rtr> <intf> <variables> FROM <sdate> to <edate> AT <gran>
WITH <cond>
Discussion started with the SELECT statement. Should the variables
specified be an actual router / interface name or a symbolic name?
Should it be a list of variables or just a single variable?
Consensus was reached to make it consistent with the RFC storage
format document so that the select statement became:
SELECT <networkname> <routername> <linkname> <variables> FROM ...
Discussion then started on what the variable part should be. Should
it be a list of variables, and if so, in what format should it be
in? Again, we reached consensus to make it consistent with the RFC
so that the SELECT became:
SELECT <networkname> <routername> <linkname> TAG <tagname> FROM ...
Some discussion then centered around where the select processing
should be done. For example, should the conditionals be processed
on the server or client? We agreed to discuss this later in the
session.
The <sdate> and <edate> fields of the FROM and TO parts of the
SELECT were agreed to be in UTC, as in the RFC. Some questions were
brought up about how to handle the <gran> parameters. We agreed
that if the <gran> value didn't match the value in the database on
the server, the server should return an error. We also agreed to
discuss later an expanded version of the LIST command to determine
available granularities.
Discussion continued for a time about the conditional part (WITH)
for the SELECT statement. We agreed that under certain querying
conditions (such as "fetch all days with errors above X") great
economies could be realized about by processing the conditional on
the server versus downloading all data to the client and processing
it there. At other times, processing on the client would be a win.
We agreed to leave the conditional processing on the server noting
that the computations of conditions may be occasionally complex.
Discussion then turned to how to fetch multiple occurances of router
interface variables, such as SNMP get-next works. We agreed to
allow the SELECT format:
SELECT * * * TAG <tagname> FROM...
so that all instances of a particular interface, router, or network
could be retrieved with one select transaction.
We then debated whether we needed the keywords "min" and "max" in
the <cond> part of the select? We were unable to exactly define
what a minimum for a period of time meant, particularly when data
was aggregated to different values. We decided that the server
should not compute different granularities on the fly (i.e. if
different granularities exist, then we shouldn't try to make them
the "same").
Some discussion revolved around the SQL-ness of the select command.
We agreed not to make it more complex than it already was :-).
The HELP command was removed since the protocol was not designed to
be used directly from, say, telnet and other HELP commands (such as
in SMTP) weren't implemented widely.
Discussion continued on Section 3.2 (Net Names) of the draft
client-server document. We agreed that this section isn't
meaningful anymore (this defines an ascii file containing backbone
point-to-point links along with other information including
bandwidth) since this information is included in the data files in
the database.
More discussion resumed on the conditional part of the SELECT
statement (as defined in 4.4, as amended). We all felt that the
conditional should be kept as simple as possible, and felt that no
added complexity was needed at this time (no sql :-)).
In the draft document in Section 4.4 some mention is made of using
CMIP distinguished names. We all moaned in unison and agreed this
was a bad thing (tm).
After the break, discussion resumed on the syntax and semantics of
the LIST command. Originally, the LIST command was of the form:
LIST <objname>
In order to give it the added capabilities to list things like
available tags and characteristics of those tags so that the SELECT
statement can be formatted correctly, the format:
LIST <network> <router> <interface> <tag> <date>
was suggested. An alternate method of using the command by placing
"*" in certain fields would allow the retrieval of information about
a given object. The table below shows the information to be
displayed:
netname: display all routers
routername: display all interfaces
interface: display all tags
tag: display all variables within a tag
date: display all available dates for a tag
The output from such a list might be of the form:
<network> <router> <interface> <tag> <dates> [ <tag> <dates> ]
**** We agreed that this should be specified in more detail later.
Resource Utilization Criteria
The question has arisen before of the issues surrounding link
utilizations and when a link should be upgraded and how to determine
``fair'' usage of a link by multiple organizations.
In terms of monitoring link usage, some networks query routers very
frequently (as often as every 60 seconds) to detect peaks. Others try
to track IP src/dest address pairs to track traffic flows. Some
networks attempt to monitor usage at various points around their network
to capture traffic flows. Some mention was made of an accounting mib
such that traffic usage patterns could be withdrawn automatically via
MIB queries. Some queries were to be made to the Internet Accounting
Working Group to determine the relevance of their work to this topic.
There was an extended discussion on when to ``upgrade'' a link. When is
it full? Should a link always run at max utilization in order to get
maximum $$ from a link? Some mention was made of looking at the peak
values, the duration of the peak values, the number and distribution of
the peaks, and attempting to correspond the peak values to other events
on the router such as errors and packet drops.
Bernhard felt that this topic should be moved from the Operational
Statistics Working Group to another working group within the Operational
Area. This was to be taken up at the ORAD meeting later in the week.
Goals & Milestones/Statistical MIB
The Common Storage Format RFC was submitted to the RFC editor in early
November 1992. The initial re-examination of the client-server protocol
has been completed. After some lengthy discussion, we moved the
completion of the client-server Internet-Draft to the July 1993 IETF
(with continuing discussions on the mailing list and at the March 1993
IETF in Columbus) and the completion of the Statistical MIB
Internet-Draft to the March 1994 IETF with a first draft ready at the
November 1993 IETF. Included in the discussions of dates was a
discussion of the future SMP stuff and the get-bulk retrieval mechanisms
for retrieval of data via the MIB which are to be examined in the
future.
2
Attendees
Tony Bates
[email protected]
Rebecca Bostwick
[email protected]
J. Nevil Brownlee
[email protected]
Henry Clark
[email protected]
Michael Conn
[email protected]
John Curran
[email protected]
Hans Eriksson
[email protected]
Dennis Ferguson
[email protected]
Richard Fisher
[email protected]
Peter Ford
[email protected]
Phillip Gross
[email protected]
Robert Gutierrez
[email protected]
Eugene Hastings
[email protected]
Alisa Hata
[email protected]
Daniel Karrenberg
[email protected]
Mark Knopper
[email protected]
Daniel Long
[email protected]
Kim Long
[email protected]
Bill Manning
[email protected]
Dennis Morris
[email protected]
David O'Leary
[email protected]
Andrew Partan
[email protected]
Marsha Perrott
[email protected]
Bernhard Stockman
[email protected]
Marten Terpstra
[email protected]
Evan Wetstone
[email protected]
Chris Wheeler
[email protected]
Paul Zawada
[email protected]
3
