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/*