Application Response Time MIB BOF (artmib) Minutes
42nd IETF - Tuesday, August 25 at 1415-1515
Submitted by Chair: Jim McQuaid <mcquaidj@netscout.com>
Stated Goal:
Explore utility, feasibility of constructing a standard MIB for reporting on application
response time and to consider related issues arising out of this goal.
The one-hour BOF was attended by 56 people including AD Bert Wijnen. The chair
reviewed the BOF charter goals and some non-goals. In general the meeting stayed
focussed on things pertinent to BOF issues, namely, is there a need for a working group
and what would its work be? The question of the relation of this possible work to
existing working groups was identified. General discussion was deferred until after
the 3 presentations from the floor.
Steve Waldbusser gave an introductory presentation in which he stated that he felt work
in this area was very important to the growing focus in network management on
applications performance. He distinguished sharply between the needs of enterprises
(who want this kind of information) and the needs of ISPs and other network providers
(who typically have no business at the application layer of the problem). Steve also
characterized current approaches to measuring networked application response times
and spoke to the question of the IETF organizational issues. He described one approach
as a ?traffic monitoring? approach which he felt aligned closely with the RMONMIB
work. [Slides not available at this time]
Albin Warth of NetScout Systems briefly reviewed a MIB proposal from NetScout.
[Note: this document was erroneously posted as a work item of the RMONMIB wg
with the title draft-ietf-rmon2-artmib-00.txt. It is an independent submission, not an
RMON2 work item. It has been reposted as draft-warth-rmon2-artmib-00.txt] This
proposal is specifically an extension of the RMON2 MIB.
Russell Dietz of TEC presented an overview of the service level problem with a
measure of application response time as part, but only one part, of a solution. He also
stated that TEC had approached the problem with a combination of RMON2 and
METER MIB.
The discussion that demonstrated a critical mass of interst and turned up a significant
number of issues to be dealt with. Some of the issues are organizational and others are
technical. The chair summarized the issues at the end of the all-too-brief discussion
time as follows.
1. What is the real scope of this work?
The expression ?application response time? is misleading. ?Measures of the
network performance of networked-applications traffic? might be a better and more
complete description.
The question of measurements made at the transport layer and measurements made
at the application - specific transaction level is an open one. Both appear to have value.
2. Relation to other working groups
There was a consensus that this work, however finally defined, does not fall into
the IPPM area though it needs to be awareness of it. There wasa lot of sentiment
around its relation to RMON2 but Andy Bierman, chair of the RMONMIB wg
expressed his concern that the definition of application-specific verbs in the protocol
directory table was an enormous amount of work. Nevill Brownlee of RTFM also
spoke, but like Andy, did not express great enthusiasm for the work falling into his group.
3. Relation of a MIB to a definition of measurement
There was a general consensus that some method for making a measurement must be
defined as part of possible future work. Without a public definition for the metric, a public
definition of how to retrieve the information is of no value within the IETF community.
There must be at least one known method as a default, although the use of multiple (known)
methods would be reasonable and manageable most likely.
Outcome - Future Action
There appears to be sufficient interest in the area. It is likely, but not completely clear,
that a working group can be usefully organized. The questions raised in the BOF and
listed above must be answered better before a charter can be created. The first order
of business may be to create a definitional document as the BMWG has done.
The actions will be to discuss the scope of the problem, attempt to define it narrow
enough to support a feasible working group and broad enough to be useful for the goal.
The issue of organizational home remains unclear with some degree of consensus that
the RMON2 work provides at least part of the technical foundation. The discussions will
begin via notification to both the RMONMIB and RTFM lists. Hopefully a specific
list home can be found to reduce the possibly irrelevant traffic for those lists. Volunteers
to host the list are hereby solicited.
None received.