Subject: INTSERV WG minutes - 32nd IETF

From: John Wroclawski <[email-masked]>
Date: Fri, 21 Apr 1995 04:30:41 -0400

Minutes of the INTSERV WG, 32nd IETF, Danvers MA

The WG chairs gratefully thank Bobby Minnear and Garrett Wollman of
MIT for their detailed meeting notes.

The Integrated Services WG held two meetings at the 32nd IETF. The
overall charter of the working group is to develop technology and
standards needed to extend the Internet architecture to accommodate
"integrated services"; the ability to provide a range of network
services tuned to a broad set of application requirements including
hard real-time, multimedia, and elastic data traffic. The major goal
of the meetings was to discuss four documents, one describing a format
(template) for defining services in an integrated services network,
and three describing, in the template format, three services proposed
as candidates for eventual adoption in the Internet.

The first meeting began with reports from commercial developers of
internet integrated service technology.

Abel Weinrib (Intel) described the Intel Architecture Lab's mission to
make PC's a major player in the use and evolution of the Internet. He
described Intel's ongoing related activities, which include supporting
IP in the Proshare conferencing products and contributing heavily to
the Winsock 2 spec (sockets for Windows) which includes resource
management and real-time capabilities. He described his own group's
plans to implement PC host support for RSVP ("Resource Reservation
Protocol"; see RSVP WG documentation for more information) and
integrated services, and to ensure that demonstration applications are
available.

Don Hoffman (Sun) discussed Sun's internal experiments with RSVP and
LBL's Class-Based Queueing and RSVP over IP/ATM, and briefly described
Sun's prototype implementation of RSVP/CBQ for Solaris 2.x, which is
currently available for experimental use. Don's talk and subsequent
questions from the audience led to a useful discussion of market
demand and near-term requirements -

- The important management control right now is allocation of
aggregate bandwidth (1/2 link devoted to videoconferencing, say)
rather than control over individual traffic flows.

- Detailed administrative controls over who can reserve b/w are not 
yet important in his setting (lab / enterprise group networks).

- System management specifications, API's, defined interfaces to subnet
bandwidth management, and stable protocol specs are the things needed
soon.

Fred Baker (cisco systems) described cisco's internal mbone-like
capabilities and the use of audio and video communication technology
for their telecommuting employees. Fred reviewed cisco's announced
schedule for the commercial availability of related technology, which
includes:

- WFQ scheduling capability (very soon)
- PIM multicast routing (now)
- RSVP (end of 1995)

Steve Cooper (IEEE 802.1 liaison) presented a quick review of 802.1
activities related to intserv. 802.1 is working to define bandwidth
management capabilities for the 802 LLC layer, and requests comment
from our group in the near future. As part of the liason agreement,
802.1 has made available to intserv the initial documents describing
this activity, and a number of more detailed documents describing
proposed changes to the 802 MAC-level bridging specs. These documents
are currently in paper form; we will find some way to make them
available to interested people.

Steve also spoke briefly about a Canadian ATM testbed sponsored by
a telco-industry consortium. This is a large, relatively open project,
which is working closely with the IP and 802 communities, and is
interested in smooth interoperation of integrated services across
multiple network types. Access is available to interested experimenters.

The meeting then turned to discussion of the Service Template document
(internet draft "draft-ietf-intserv-svc-template-00.txt"). Scott
Shenker led the discussion, which was structured as a walk-through of
the document. The intent of the presentation was gather input for
continued refinement of the document, which will eventually become an
informational RFC. During the discussion the following major points
were raised:

- Advertisements: the document says that a service may specify either
mandatory or optional advertisements. Questions about the usefulness
of optional advertisements were raised. During the discussion it
became clear that a) allowing optional advertisements requires further
thought, and b) that in any even the document needs further
clarification in this area.

- Ordering relationships: The document discusses the need to define
ordering relationships between reservation requests, in order to be
able to compute an "upper bound" when merging several requests to
determine the actual amount of resources reserved. Several people
stated that the document was vague and incomplete in this
area. Discussion revolved around "how much" a service template should
specify - just ordering relationships; some behvioural definition of
the required "upper bound", or a specific algorithm for calculating
the upper bound. A core issue is that this calculation offers
opportunities for product targeting and competitive advantage, and
the desired goal for the document is to demand adequate but not
over-specification. The group agreed that the document needs to say
more, and the authors agreed to try and figure out what it should be.

- Evaluation criteria. This section describes the criteria
which should be used to evaluate a network element which claims to
provide the described service. Note that the adequate evaluation of integrated
service network elements requires not just conformance tests, but may
in fact lead to multiple measures of "goodness" or applicability for
various uses.

This section provoked a long discussion. Although no clear consensus
was reached, certain themes became evident:

- Both conformance and performance tests are likely to exist. It is
important to clearly distinguish between the two. It may be equally
important to put them in the same section of the document (which is
not the case in the current draft), so that vendors and customers will
be aware of both.

- Conformance tests are often best described as things which
should -not- happen under any circumstance; service template writers
may find this useful.

- Performance tests are made even trickier because there is no simple
worst-best scale; rather there are tradeoffs which lead to different
"best" answers for different situations. Over time it may be possible
to develop clear, well-defined ways of determining this information
and presenting it to customers, but we don't know how to do it now.

- Crisp, simple statements of expectations will take us a long way,
and should form the core of this section, even if more detailed
evaluation criteria are also included.

The meeting concluded that points raised in the discussion should be
addressed by a revised draft to be prepared by the authors and other
interested folks and circulated to the mailing list.

Discussion next turned to the Controlled Delay service document,
"draft-ietf-intserv-control-del-svc-00.txt". Craig Partridge led the
discussion of this document. He began by explaining that this service
was designed for applications such as VAT that could adapt to
differing network delays, and that supported the "clicker" model of
reservation. ("If you don't like the service you're getting, click the
button and it will get better"). Craig also reminded the meeting that
all of these documents are quite preliminary, and asked for active
feedback.

In the discussion the following issues received attention:

- Underspecification of service. At several points in the discussion,
it was pointed out that the desired behaviour of the service depended
on things which were not actually described in the template, such as
admission control policy. Each of these points was noted for future
revision of the document.

- Use of token bucket traffic specifiers. Various researchers,
including the authors of this document, have claimed in the past that
token buckets are not the optimal choice for traffic descriptors. The
question of why TB specs were used for this service was raised. Craig
responded that the TB description was adequate for this purpose and
that despite some efforts nothing clearly better was known at this
time.

- Wisdom of having both "delay" and "service level" target
specifications in the service. This appears to be somewhat confusing,
and some difference of opinion as to its usefulness was raised. A few
participants thought that neither actually captured the intent of the
service. This issue was noted as requiring more thought for the next
revision of the document.

- General usefulness of the service. Bruce Davie noted that the service
was actually quite useful, but that this usefulness was not made
apparent by the formulaic description of the template. This led to a
brief discussion of adding a tutorial section to the template
model. However, as the service templates are intended to become
standards-track documents, the sense of the meeting was that a
separate tutorial document would be more appropriate, and that the
writing of that document was an important work item.

The discussion was ended by the adjournment of the morning meeting.
Points raised in the discussion, as well as changes already planned by
the document authors, will be incorporated into a revised draft. This
draft will be circulated on the mailing list, and may be discussed at
an interim meeting of the WG, if appropriate. 

The afternoon meeting began with Scott Shenker presenting a second
service specification draft,
"draft-ietf-intserv-predictive-svc-00.txt".  This service offers a
"predictive" delay bound to real-time applications which wish to
specify a delay bound but can tolerate a very small level of bounding
failure; that is, packets taking longer than the bounded delay time to
arrive. The advantages of predictive service over the more traditional
"guaranteed" service described below are substantially better
attainable bounds and more efficient use of the network.

Several issues were raised during the discussion of this draft:

- Advertising. For this service, advertising is used to convey to
applications the end-to-end delay bounds they can expect to
obtain. The question raised was how to measure these bounds; maximum
instantaneous delay over some past interval, averaging function and
interval, or some other choice. It was noted that no single answer
will match all applications desiring to use the service. After some
discussion the general conclusion seems to be that a) more experience
is required to choose a truly good answer, and b) a useful, simple
answer would be to advertise maximum instantaneous delay over several
intervals.

- Traffic policing and merging. The service as currently defined calls
for traffic policing (not shaping) at entrance to the network and at
traffic flow merge points. The question of handling extra burstiness
caused by merging was raised. The two options are to add a traffic
shaping function at this point or to accept the increased burstiness,
which includes ensuring that the function which calculates merged
reservation traffic specifications takes it into account. This remains
a matter for further research.

- Specification of a precise value for the "very small level" of delay
bound failure. This discussion began with a question as to why any
bound failure at all should be accepted. Scott explained the
performance and network utilization advantages of allowing an
occasional bound failure. The discussion turned to whether the level
of bound failure could or should be specified by the service, rather
than being characterized as part of a router's performance
metrics. The general consensus was that the spec should provide some
guidance as to design goals, but that specific behaviour was best left
to the router designer.

As with the other documents, discussion of the predictive service
draft concluded with a list of changes needed for a revised draft.

Scott Shenker presented a third service specification draft,
"draft-ietf-intserv-guaranteed-svc-00.txt", which describes a
"guaranteed" service. Unlike the services presented previously, the
guaranteed service offers a mathematical guarantee of data delivery
within a specified delay, assuming that there is no hard failure of a
component in the network. Scott began by explaining that the draft
document was seriously broken due to a notation confusion between the
authors. With that caveat, the presentation followed the same
walk-through format.

No serious issues were raised during this discussion. The consensus of
the group was that the service is important and that a repaired
document was not expected to raise any difficult problems. 

Discussion of the service specification drafts having concluded, the
WG chairs raised the question of proceeding towards Proposed Standard
status for one or more of the service specification documents at the
next (Stockholm) IETF. Several points were discussed:

- Missing from the table is a candidate service for rate-adaptive
applications, which seem likely play a major role in any heterogeneous
integrated service network, particularly one combining best-effort and
reserved-resources delivery models. The chairs will try to elicit a
draft for such a service before the next meeting.

- The question of adequate simulation / experimentation with
predictive service was raised. It was reported that some experiments
have been conducted on Dartnet, and that more were planned before the
next meeting. 

Craig Partridge proposed the strategy of -> draft revision / email
discussion / group polling / presentation at Stockholm <- for
determining whether each document should move to proposed standard
status. Dave Clark raised the possibility of holding an interim
meeting. After some discussion it was agreed that, due to the
difficulty of scheduling a physical meeting, this would be done only
if it appeared that discussion on the mailing list was failing.

An open technical discussion then ensued, with several people raising
points about specific services. Most of the uncertainty focussed on
the predictive service, which, particularly in its admission control and
reservation merging strategy, is the least intuitive of the three. It
appears that at this time the group has not reached a general
consensus regarding the predictive service.

In the remaining time, the group heard several technical presentations
from the research community.

Lee Breslau (Xerox PARC) described his work to implement and test an
admission control algorithm based on measurement of current traffic,
rather than use of a worst-case specification. This algorithm, which
has been developed by several people at PARC and the University of
Southern California, is designed to give high network utilization for
a predictive service. Lee described the basic algorithm and plans to
deploy an experimental version on Dartnet. Questions from the audience
led to a discussion of the measurement intervals used, and the
probable need to measure the history of different traffic streams over
different intervals to adequately account for a range of application
behaviour. 

Mikael Degermark (University of Lulea) spoke about his simulation of a
model for managing advance reservations (reservations made days or
weeks before the network resources are required). Mikael described an
extension of measurement-based admission control to accommodate advance
reservations, and presented simulations which showed that his approach
held network utilization relatively constant as up to 50% of the
capacity was reserved in advance.

This presentation, goaded slightly by the chairs, led to a general
discussion of the need for advance reservations in the intserv
architecture. The need for preemptible reservations, which could be
canceled by those of higher priority, was also raised during this
discussion. Although no poll was taken, it appears that the need for
preemptible reservations is widely recognised, but that the
requirement for advance reservations is a subject for further
discussion.

John Zinky (BBN) spoke about providing QoS management capability for
CORBA objects. This work extends QoS management directly to
application level components, and is in fact a more general
restructuring of the pure client server model which provides several
new capabilities. Details are available at http://guava.bbn.com

Patricia Florissi (Columbia) presented a package which extends the
sockets interface to provide transport-independent QoS management and
monitoring services, including request and re-negotiation of
high-level QoS requirements, monitoring and signaling of QoS
violations, and run-time generation of Qos MIB's (essentially, an
SNMPv2 summary of the behaviour of each individual application).  Code
embodying this work is available at
ftp://ftp.columbia.cs.edu/pub/qual/qual.tar.Z

It then being 5:30PM, the meeting was adjourned.

The following documents will be available at the intserv ftp archive:

 - these minutes, slides of presentations mentioned above
ftp://mercury.lcs.mit.edu/pub/intserv/ietf32/*

 - internet-drafts
ftp://mercury.lcs.mit.edu/pub/intserv/drafts/*