Reported by Craig Partridge/Bolt Beranek and Newman
Minutes of the Integrated Services Working Group (INTSERV)
The Template Document
John Wroclawski gave a brief overview of the integrated services work
and presented the template document. There were several comments on the
template:
o Bob Braden suggested that ``resulting service'' should be moved
earlier in the templates (rather than having to read to the end of
the documents to find out what all the text is actually going to
result in).
o There was some discussion about where OPWA fits in---is it part of
the service model (Bob Braden's opinion), part of the reservation
model (several INTSERV people's opinion), or neither? In any case,
where does it get specified, if at all?
o There needs to be a piece of text somewhere describing the token
bucket in precise terms; at present we only seem to have
non-existent references.
o On the subject of data formats, there was some debate about why we
need both an abstract definition and a specific representation.
The answer was so that those protocols that wanted to use some
other representation could use the abstract definition to figure
out what to do.
o Questions were raised about merging composition functions at merge
points (no resolutions---just that the documents currently only
think in terms of single flows end-to-end).
The Guaranteed Service Document
Craig Partridge presented the guaranteed service document (observing
that despite his travels, he believed he was currently up-to-date on the
e-mail). Most of the comments were written down on the slides as
explicit modifications to the specification (and thus will be reflected
in the revised draft). Some key points that were raised:
o The PDU size used by the flow matters---one has to compute
link-level overheads, and the frequency with which link-level
headers occur is based on PDU size. After discussions about
whether to try complex characterizations of the PDU size range, we
decided to use the simple approach---just specify the minimum size.
Walter Milliken notes that some equipment is packet-rate limited,
and by only specifying the minimum size will they be caused to
overestimate the maximum packet rate---the group decided to live
with that problem.
o The document currently only talks about queuing delay and does not
describe how propagation delay through links (which may be ATM
subnets and thus have to be represented as service elements) is to
be accounted for. This is to be fixed.
o The range of rates was wrong (and wrapped up with the notion of
policing in bizarre ways). So the range is to be changed to allow
for as little as one byte per second and the policing text is to be
improved.
o The possibility of including a priority in the TSpec was discussed
but the group was not sure that this bought any advantages and it
did have clear disadvantages (such as forcing us to support
priorities in any queuing scheme we put into any router).
o There was a discussion of what floating point format to use in the
TSpec and the agreement was to use IEEE representation (and stop
trying to develop our own).
Predictive Service
Lee Breslau gave a short talk on predictive service, showing graphs from
experiments which showed predictive service generally maintained delay
within bounds quite well, and had rare but extended excursions above the
delay bound.
Controlled Delay
After lunch, John Wroclawski presented the controlled delay draft.
Again key comments are summarized:
o The draft was unclear about the loss model. Does controlled delay
deliver all packets, but some late? Is low loss both queue loss
and being late? Is loss advertised?
o The issue of substitution of controlled delay with guaranteed
service raises the issue of guaranteed having added the packet size
to the TSpec. Answer, nice to match guaranteed and controlled
delay.
o There was a discussion about exported information. We're exporting
nine numbers, measured over intervals as short as a second. It was
clear that we'd like some detailed information about short term
behavior but that we're also collecting the wrong information
(namely worst case delay, when what we want is closer to the delay
within which 99% of all packets arrive).
Lixia Zhang presented an alternative controlled delay service suggested
by her and Sally Floyd. The differences between it and the proposed
service was that that new service would have only one level of queuing
and no advertising. The room generally preferred having multiple levels
of queuing available, even if some implementations only use one level of
queue (which is permitted by the specification).
Policing
Bruce Davie spoke on policing. He made several important points.
o Policing needs to be done at both source merge points and at `split
points' (places where the multicast tree splits) when the
reservation downstream from the split point is less than at the
split point.
o Policing by dropping has the potential to disrupt the service of
receivers who may have been receiving adequate service prior to the
installation of a reservation. This suggests that alternate
approaches should be sought. These include marking non-conforming
packets, reshaping to restore conformance, and relegating
non-conforming packets back to best effort. While reshaping in
general adds delay, Craig pointed out that for guaranteed, one can
show that the delay added is still within promised delay, and it
was decided to require reshaping for guaranteed.
o Policing at points other than the network edges needs to be done
carefully, since traffic may become more bursty as it passes
through network elements. Thus, using a token bucket filter that
was specified at the edge is not an acceptable way to do policing.
o Since the burstiness of a flow changes as it traverses the network
may change but its average rate does not, it might be desirable to
police based on the token bucket at the edges and to police on rate
only at merge and split points. Bruce is still working on the math
for this idea.
o More work is needed on the marking and relegation to best effort
approaches.
The Proposed Flow Specification
John Wroclawski spoke about the proposed flow specification. There was
general agreement that it looked good. On the only major issues, the
vote was for self-parsing formats and for zero-based length.
There was then some brief discussion about where to go next.
o It was felt desirable to progress controlled delay and guaranteed
at the same time.
o Guaranteed (once changes made during the meeting where applied)
seemed ready to go to Proposed Standard, with a brief comment
period on the list to ensure that changes were made correctly.
o Controlled Delay is in slightly less ready state, particularly
related to the issues of loss vs. late delivery vs. discard and
advertising parameters. The plan was to send out a revised version
to the list soon and if there prove to be lingering issues, call an
interim working group meeting (probably at SIGCOMM).
o The group felt the flow specification document was sufficient,
simple and close to the right form that it too could go on the
standards track after a comment period on the working group list.
