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.