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 2) HELP 3) LIST 4) EXIT 5) SELECT FROM to AT WITH 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 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 TAG 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 and 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 parameters. We agreed that if the 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 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 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 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 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: [ ] **** 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 t.bates@nosc.ja.net Rebecca Bostwick bostwick@es.net J. Nevil Brownlee nevil@aukuni.ac.uz Henry Clark henryc@oar.net Michael Conn 4387451@mcimail.com John Curran jcurran@bbn.com Hans Eriksson hans@sics.se Dennis Ferguson dennis@ans.net Richard Fisher rfisher@cdhf1.gsfc.nasa.gov Peter Ford peter@goshawk.lanl.gov Phillip Gross pgross@nis.ans.net Robert Gutierrez gutierre@nsipo.nasa.gov Eugene Hastings hastings@psc.edu Alisa Hata hata@cac.washington.edu Daniel Karrenberg daniel@ripe.net Mark Knopper mak@merit.edu Daniel Long long@nic.near.net Kim Long klong@sura.net Bill Manning bmanning@sesqui.net Dennis Morris morrisd@imo-uvax.disa.mil David O'Leary doleary@cisco.com Andrew Partan asp@uunet.uu.net Marsha Perrott mlp+@andrew.cmu.edu Bernhard Stockman boss@ebone.net Marten Terpstra marten@ripe.net Evan Wetstone evan@rice.edu Chris Wheeler cwheeler@cac.washington.edu Paul Zawada Zawada@ncsa.uiuc.edu 3