CURRENT_MEETING_REPORT_ Reported by John Wroclawski/MIT Minutes of the Integrated Services Working Group (INTSERV) The Integrated Services Working Group (INTSERV) held two meetings at the San Jose IETF. The major objective of the meetings was to introduce and discuss a new ``reusable framework'' approach to providing quality of service control in the Internet. The key goal of this approach is to allow new services to be deployed in an evolutionary, market-driven manner, while maintaining backward compatibility and (re)using standard components. Agenda - First Session o Overview of reusable framework approach - Review of Toronto work items - Motivation for new approach - Framework components - Required changes to work items o Quality of service manager (QM) presentations - Basic principles and definition - Example application usage - Open discussion Framework The group began the first meeting with a brief presentation describing the framework approach and how it differs from the group's previous path. The framework approach is based on the belief that: o Different parts of the Internet will have different QoS management capabilities. o The end-to-end service quality seen by an application is based on a composition of the capabilities found along the communication path. o An effective service composition mechanism must explicitly recognise the decentralized administrative and management structure of the Internet. o The QoS capabilities available to an application will be variable and will evolve over time. As much as possible, applications needing QoS control should be decoupled from the details of a specific QoS service. o The best way to support this hegerogeneity is to develop a framework of reusable components, which can be employed to support a range of services, and will provide the common language which allows different services to deploy and evolve at different rates. John Wroclawski's presentation (see slides) discussed the goals of this new approach, described four components (the Quality of Service Manager, setup protocols, traffic specifiers, and service specification templates), and briefly described the impact of this approach on the work items discussed at the Toronto IETF. Quality of Service Manager Dave Clark began a discussion of the Quality of Service Manager, an abstraction layer designed to isolate applications from the specific details of services provided by an internet. Dave gave a general presentation (see slides) of the QM principles and architecture, its uses, and how it might be realised in practice. The purpose of the QM is to let the application negotiate with the network for the quality of service desired without needing to know the details of a specific service. Instead, the QM provides a single interface which allows an application to express its service requirements in general terms. The QM is then responsible for determining what QoS management capabilities are available on the application's communication path, and choosing the ones most suited to the application. Two things are gained by moving this knowledge of specific services from applications to the QM: o Heterogeneity within the Internet is better supported, because the QM can match application needs to the QoS capabilities available. Most applications will not need to be aware of the details of a specific QoS management capability. o New QoS capabilities can be more easily deployed within the Internet, because applications will not need to be modified to as new services become available. Several points about the QM deserve specific emphasis. To be successful, the QM's interactions with the application may need to be quite general, covering such areas as cost of service and user requirements, as well as more technical matters such as delay and bandwidth. The QM concept is thus somewhat more general than existing ``abstract service interfaces'' such as Q.2931's QoS parameters and the proposed Winsock 2 specification. Despite this generality, it may be true that a very few highly performance-critical applications will find the QM interface inadequate and instead depend on a specific QoS management service. This would be analogous to a current IP application that for some reason could only run over a single link layer protocol. Such applications are expected to be quite rare, but must be supported. Finally, the QM model is quite new and evolving fast. The group expects to have substantially more experience, including some implementation, at the next IETF meeting. Craig Partridge discussed a binding of the QM interface to Berkeley sockets. Craig's presentation described the mechanics of using socket options to implement the QM's negotiation with the application. Discussion during the presentation focussed on the merits of embedding the QM interface in sockets, and the expressiveness of the particular socket options chosen. Both of these presentations described early work, and the authors received significant feedback from the working group. The sense of the meeting was that the proposal was promising but required further development before it could be judged effectively. The meeting closed with a brief discussion of the overall value of the framework approach to providing integrated services. A show of hands revealed essentially complete consensus that the new approach was preferred to the alternative of mandating a single set of services throughout the Internet. Agenda - Second Session o Service specification requirements document - Presentation of preliminary draft document - Discussion o Flow specifiers - Does the group need to address flow spec format - Can existing work be used (RFC 1363, Winsock, ATM) o Initial deployment plan o Additional technical issues - Relationship to TCP/existing services - IPv6 Flow ID management - Token bucket filters Service Specification Requirements The group continued the discussion of framework components in the second meeting. Scott Shenker presented (see slides) his preliminary version of a service specification requirements Internet-Draft. The purpose of this document is to define the requirements and format for specifying a QoS control capability, or ``service.'' The proposed draft has two parts. The first specifies a template for defining services, including router behaviour, composition rules, and additional information. This specification provides information needed by several parties: o Router implementors use this information to implement packet scheduling, admission control, and related functions for the service. o Router implementors also use this information to determine what other services are related to this one, and whether this service can substitute for another service in an end-to-end composition. o QM implementors use this information to determine how this service can be used to provide the end-to-end behaviour needed by applications. o Setup protocol implementors use this information to determine what information to pass to the router when this service is requested. o Management agent implementors use this information to determine what information and control parameters the service makes available. The second portion of Scott's presentation gave three examples of the use of this template: a level-of-effort predictive service, a bounded delay predictive service, and a guaranteed delay service. Scott emphasized that he was not advocating any of these services, but was using them to motivate discussion about the format of his proposed template. The intention is that the template format become a standard, but that, for now, the example services are informational. The group agreed that this draft was a good base for continued work. Flow Specifiers Craig Partridge gave a presentation about traffic specifications (``flowspecs'') and whether these are a component reusable among many services or specific to a particular service. After some discussion, the group appeared to find some merit to common flowspecs, but believed that further concrete evidence of their usefulness was required. Further discussion centered on the use of RFC 1363 or the Windows Sockets version 2.0 specification as a possible starting point for experimental implementations. Deployment Discussion John Wroclawski presented a proposal for initial deployment of integrated service capabilities in the July 1995 timeframe. The proposal includes several components: o RSVP version 1, including - Advertising - Appropriate authorization model o A level-of-effort predictive service suitable for rate-adaptive and non-rate-adaptive applications, including - Scheduling model - Admission control - Policing - Demand-control feedback mechanisms o A ``QM friendly'' application interface - Assumes QM work is not complete, but tries not to be disruptive o Management and monitoring capabilities Discussion of the proposal focussed on the goal of supporting rate-adaptive applications. Several people questioned whether rate-adaptive applications required QoS management at all. Others suggested that it would be better to ignore rate-adaptive applications at this time in the interest of expediency. John agreed to consider the question further and continue the discussion on the mailing list. John asked about interest in a small implementors group to further this work. Several people expressed interest. Fred Baker agreed to coordinate a group to discuss network management issues, and organized a lunch meeting on this topic. The second meeting closed with a brief technical discussion about token bucket filters. Two other topics, the relationship of int-serv to TCP performance issues in the Internet, and the management of IPv6 Flow ID's, did not elicit significant interest from the group. Token bucket filters are widely proposed today as traffic descriptors and shapers, but recent work by Mark Garrett and Craig Partridge suggests some limitations. This is directly relevant to the flowspec discussion described above, and will need to be better understood in the future. Mark, Craig and others are writing a paper on the topic, and agreed to present it to the group when complete.