Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/intserv/intserv-minutes-95apr.txt

Text File | 1995-05-27 | 17.9 KB | 392 lines

CURRENT_MEETING_REPORT_

Reported by John Wroclawski/MIT

Minutes of the Integrated Services Working Group (INTSERV)

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

The Integrated Services Working Group 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.


Reports From Commercial Developers

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 PCs 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 specification (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 Working Group 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 Queuing 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.


   o The important management control right now is allocation of
     aggregate bandwidth (e.g., half of a link devoted to
     videoconferencing) rather than control over individual traffic
     flows.

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

   o System management specifications, API's, defined interfaces to
     subnet bandwidth management, and stable protocol specifications 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:


   o WFQ scheduling capability (very soon)
   o PIM multicast routing (now)
   o 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 liaison 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 specifications.  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 Service Template Document

The meeting 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 to gather input for
continued refinement of the document, which will eventually become an
Informational RFC. During the discussion the following major points were
raised:


   o 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 event the document
     needs further clarification in this area.

   o 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 behavioral 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.

   o 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:


   o 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.

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

   o 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 it is not
     known how to do it now.

   o 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.



The Controlled Delay Service Document


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, and 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:


   o Underspecification of service.  At several points in the
     discussion, it was pointed out that the desired behavior 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.

   o 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 specifications 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.

   o 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.

   o 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 working group, if appropriate.



Specification of Predictive Quality of Service


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:


   o 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.

   o 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.

   o 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 specification should
     provide some guidance as to design goals, but that specific
     behavior 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.



Specification of Guaranteed Quality of Service

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.


Proceeding Toward Proposed Standard Status

Discussion of the service specification drafts having concluded, the
working group chairs raised the question of proceeding toward Proposed
Standard status for one or more of the service specification documents
at the next IETF in Stockholm.  Several points were discussed:


   o Missing from the table is a candidate service for rate-adaptive
     applications, which seem likely to 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.

   o 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:


   o draft revision
   o e-mail discussion
   o group polling
   o 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.


Technical Presentations

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 behavior.

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 preemptable 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
preemptable reservations is widely recognized, 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
behavior of each individual application).  Code embodying this work is
available at:


     ftp://ftp.columbia.cs.edu/pub/qual/qual.tar.Z


Available Documents

The following documents will be available at the INTSERV FTP archive:


   o These minutes and slides of presentations mentioned above
     ftp://mercury.lcs.mit.edu/pub/intserv/ietf32/*

   o Internet-Drafts
     ftp://mercury.lcs.mit.edu/pub/intserv/drafts/*