CURRENT_MEETING_REPORT_ Reported by Scott Shenker/Xerox Corporation Minutes of the Integrated Services Working Group (INTSERV) Agenda o Introduction o Work items and schedule o Service model presentation o Outreach o Next time o Latency Introduction The chair noted that this group is proposing a particular architectural approach, based on explicit reservations and explicit resource allocation. This is not the only approach; e.g., there are some who advocate only using fair queueing at the switches and making all applications sufficiently adaptive. A comparison of various schemes will be required when more is known about these other schemes. This discussion may occur in this working group, or perhaps in some other forum. Work Items and Schedule The first open work item is the preparation of a new Internet-Draft which would describe the service model in a somewhat more straightforward manner. A draft of this document will be distributed before the next meeting. Following the presentation, there was a discussion of the relationship among the roles of the application, the IP layer and the subnet layer in accomplishing explicit services. Service Model Presentation There was a presentation of the overall service model. This description adds some context, and some new services, to the previous proposal of ``ASAP (best-effort), predictive and guaranteed'' services. The presentation is based on a taxonomy of service requirements in the dimensions of bandwidth, delay and loss. Each of these can be either controlled (by the network) or uncontrolled. The cross-product of all these gives a space of services, which can be mapped to specific application needs. The group first explores the space of controlled and uncontrolled delay and bandwidth. In each category, the group first discusses a few motivating applications with these service requirements, and then describe a service that meets these requirements. 1. Uncontrolled delay and uncontrolled (variable) bandwidth Examples of applications which need such service are elastic applications, such as TELNET and FTP. They can gracefully adapt to variable per-packet delays. The appropriate service for this class is ASAP service. 2. Uncontrolled delay and controlled bandwidth An example of an application which needs this kind of service is an FTP that must complete by some overall time. It can still adapt to variable delay and bandwidth, but needs a minimum available bandwidth. The group proposes a service called ``assured ASAP'' which provides exactly that. It requires admission control, since a quantitative guarantee is made. 3. Controlled delay and bandwidth The standard real-time applications have these service requirements. They require a per-packet bound on delay, and have an intrinsic bandwidth requirement (and so need controlled bandwidth). They can be either tolerant or intolerant of occasional violations of the delay bounds. For this class of applications, the guaranteed and predictive services are proposed. Guaranteed service provides a worst-case bound, whereas predictive service provides only a fairly reliable bound. 4. Controlled delay, uncontrolled bandwidth An example with these service needs is variable quality real-time applications, which need a per-packet delay bound, but can operate at different throughput rates. The group proposes a service, called variable bandwidth predictive (VBP), which gives predictive per-packet delay bounds and gives variable amounts of bandwidth. There are several design issues for this service. o How is the bandwidth varied? It is assumed that the network will drop what it cannot handle, and the application supplies a drop preference to rank-order the packets under overload situations. o Does the flow specify the traffic characteristics of each layer? It can be done either way, but as of now our preference is to shape and control each layer. o What is the dropping algorithm? The router could drop to a uniform preference level, or a level could be set for each flow. It could also drop based on very short-term queue occupancy. At our next meeting, the group will discuss this service class more extensively. The end result are these four classes of service requirements, and four separate service offerings (considering predictive a special case of VBP). What happens when loss is added? In all but the one class of VBP, there is minimal tolerance of loss. In that class, there is broad tolerance of loss. So adding loss, as a practical matter, does not extend the state space. There were several questions from the floor at this point. It was observed that there may be examples of loss-tolerant ASAP packets, such as idempotent status messages. It was also noted that some variable bandwidth applications would not like to lose packets. Since the only response inside the network is to drop packets, source end-to-end adaptation is a tool in this case. A question was asked as to whether meeting these service requirements should be viewed as a distributed scheduling problem. This is addressed in our view of router requirements: packet scheduling is viewed as local to each node. The application of stock trading was offered as another example of service needs, and a detailed description of how the service model would apply to those needs ensued. A question was raised about whether the service model presented is actually a classification of applications rather than a service model. Also, it was asked if dropping (i.e., having drop preference indication) breaks the model of flows, since the term ``flows'' has typically been used to refer to a set of packets which should receive similar treatment. Chuck Davin agreed to send a message detailing his other comments. There was a lengthy discussion about how ASAP service, which has no traffic characterization, can be a commercially viable service. Some indicated that the definition of ASAP service should contain performance specifications, such as loss rates. Others felt that such issues should be addressed at the contractual and regulatory levels, not by the service model. Wiltel was offered as an example, which offers a four month money-back guarantee but does not specify the level of service. Returning to the talk, it was observed that for services that control delay, a distinction is made between the traffic characteristics, the TSpec, and the quality of service specification, the QSpec, which is what the network is asked to do. The talk next addressed what the switches need to do in order to deliver those services. That is, what do the switches need to do on a per-hop basis in order to deliver the desired end-to-end service. For the guaranteed service, the per-hop service behavior based on the Weighted Fair Queuing (WFQ) fluid model was described, with a parameterized error bound that can recognize different queueing schemes. See the slides for the formalization. Predictive service requires the switches to provide bounded delay service at each hop. These per-hop requirements will also apply, perhaps in a modified form, to subnets. There are many legacy subnets which do not conform to the requirements outlined above (e.g., all Ethernets). This is viewed as a serious transition problem: how to use the service model in the presence of such nonconformant subnets and routers. The group proposed the use of a reliability measure to deal with nonconformant subnets and routers. The next discussion is a summary of the reservation interface. The issue is which module does the translation between the local (per-hop) behavior and global (end-to-end) service. One model is that the receiver specifies the desired end-to-end QoS. The other is that the network characterizes its range of offered services, and the receiver picks the best match. A more detailed discussion will occur at the RSVP Working Group. The last issue discussed was multicast. Multicast has two opposing goals. One, use a shared tree. Two, accommodate heterogeneous QoS requests from receivers. So when can two service requests be merged into a shared tree? Merging can occur as long as neither receiver suffers as a result. There are several forms of heterogeneity, including bandwidth and predictive versus guaranteed. The issue of merging guaranteed and predictive requests is of particular relevance. In a question from the floor, it was observed that these problems of merging heterogeneous requests largely disappears if the space of possible QoSs is made much sparser. There was also a lengthy discussion of how the ATM service offerings map into the service model described here. Packet Latency The meeting moved to a short presentation on the problem of bounding end-to-end latency. It was noted that today's Internet makes no commitments whatsoever about latency, and that for any integrated services architecture to work, the basic structure (links, subnets) of the net will have to limit latency to some degree. This requirement is independent of resource reservation, scheduling architectures, and the like, which cannot compensate for lack of functionality in the underlying components. It was further noted that the correct measure of latency is time, not packet size. Several questions were raised: o Should there be some sort of Internet ``standard'' for link latency, or should we count on QoS routing to find paths with appropriate latency? o What are appropriate target numbers for latency control? Does the possibility of supporting cheap latency-sensitive devices (set-top boxes, telephones, etc.) affect this requirement? o Should we count on link level mechanisms (link-level fragmentation, preemptive link-level protocols) to control latency, or is something required at the IP level? o Are there specific issues within the IP6 process which affect this problem (e.g., proposals to support ``jumbograms'')? Outreach There are several other communities addressing the same QoS issues under consideration in this working group. They include the 802 community and the ATM community. It was noted that the group is in various forms of contact with these bodies and is attempting to stay abreast of their progress. The group received a short presentation from John Grinham on the action of the 802 subgroup describing the work for multi-media LANs. Drew Perkins noted that he is the liaison from the ATM Forum. Next Time The meeting concluded with a short discussion of the agenda for the next IETF. The primary work item is expected to be detailed discussion of an Internet-Draft specifying the proposed service model.