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.
