Subject: December IETF Minutes

From: John Wroclawski <[email-masked]>
Date: Thu, 5 Jan 1995 17:12:13 -0500

CURRENT MEETING REPORT
INTEGRATED SERVICES WG

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 compatability 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

o Framework

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

  -- different parts of the Internet will have different QoS
     management capabilities.

  -- The end to end service quality seen by an application is based on
     a composition of the capabilities found along the communication
     path.

  -- An effective service composition mechanism must explicitly
     recognise the decentralized administrative and management
     structure of the Internet.

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

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

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

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

  -- 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 analagous 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 WG. 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 concensus 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 we use existing work (RFC1363, Winsock, ATM)

	o Initial Deployment Plan

	o Additional Technical Issues
	   -- Relationship to TCP / existing services
	   -- IPv6 Flow ID management
	   -- Token Bucket Filters

o Service Specification Requirements

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

  -- Router implementors use this information to implement packet
     scheduling, admission control, and related functions for the service.

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

  -- QM implementors use this information to determine how this
     service can be used to provide the end-to-end behaviour needed by
     applications.

  -- Setup protocol implementors use this information to determine
     what information to pass to the router when this service is requested.

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

o 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 RFC1363 or the
Windows Sockets version 2.0 spec as a possible starting point for
experimental implementations.

o Deployment Discussion

John Wroclawski presented a proposal for initial deployment of
integrated service capabilities in the July '95 timeframe. The
proposal includes several components

  -- RSVP version 1, including
	- advertising
	- appropriate authorization model

  -- 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
	
  -- A "QM friendly" application interface
	- assumes QM work is not complete, but tries not to be disruptive

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