Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/intserv/intserv-minutes-95jul.txt

Text File | 1995-10-18 | 8KB | 184 lines

CURRENT_MEETING_REPORT_

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.