CURRENT_MEETING_REPORT_ Reported by Luca Delgrossi/IBM Minutes of the Internet Stream Protocol V2 Working Group (ST2) The ST2 Working Group met in two sessions. Prior to the first session, Craig Partridge of BBN gave a talk on his experiences with ST-II. Craig did one of the first ST-II implementations with Steven Pink at the Swedish Institute of Computer Science in 1992. Craig pointed out some of the weaker points of ST-II, including the fact that the specification (RFC 1190) forced the implementor to guess at what was intended in certain situations. Protocol complexity was also raised as an issue. The points raised all seemed consistent with the experience of the other implementors and certainly helped to motivate everyone prior to the start of the first working group meeting which was held immediately after the talk. The working group meeting began with a brief review of the goals of the working group, the milestones specified in the charter, and a review of the agenda for the two working group meetings planned for this week. IBM Heidelberg Transport System (HeiTS) Luca Delgrossi of the IBM European Networking Center presented an overview of the IBM HeiTS (Heidelberg Transport System) stack, which includes an ST-II implementation. HeiTS is strongly focused on providing guaranteed quality of service to applications, particularly multimedia applications. HeiTS uses its own FlowSpec which is significantly simpler than the RFC 1190 FlowSpec. In addition to implementing ST-II, HeiTS also provides a Resource Management Subsystem which handles resource reservation for CPU, [memory] buffers, and network and communication adapter resources. In addition, HeiTS will interface with a ``Central Resource Allocator'' to coordinate network resource reservations in a complex network environment. Luca ended his presentation by discussing some possible protocol extensions or modifications that could make ST-II a more scalable and useful protocol, including the ability for targets to initiate a connection by joining an existing stream at a router instead of communicating directly with the origin to join a stream. ``ST-II Testing and Evaluation'' Doris Roland from Houston Associates, Inc. (HAI) gave a presentation on ``ST-II Testing and Evaluation'' which discusses some testing that HAI is doing for ARPA and the Defense Simulation Internet (DSInet). The DSInet is an evolution of the Terrestrial Wideband Network (TWBnet) which runs ST-II at about half of the sites on the network. Houston Associates, Inc. provides support for users of the DSInet and is performing their testing independently of other testing being done by BBN, which is the contractor responsible for building and operating the DSInet. The DSInet runs simulation exercises and video conferencing using ST-II to carry the realtime traffic. The HAI test plan consists of multiple stages, each of increasing complexity. They are explicitly testing stream setup, bandwidth reservation, routing, data transfer, stream modification, multicasting, and stream teardown. Their ultimate goal is to run multiple simulation exercises over portions of the backbone to see how well the overall system functions. HAI Test Plan After Doris's presentation, the group discussed some of the details of the HAI test plan, which included the measurement of delay variance in the network. Since a relatively low upper delay bound was specified, group members wondered why delay variance needed to be measured. The final answer was that the buffer space on the end systems is limited and excessive delay variance can cause buffers to overflow. An additional discussion item was brought up when it was mentioned that Wellfleet had developed an ST-II router for ARPA and was going to be deploying it on the DSInet. The group wanted to know whether this would be made generally available in Wellfleet's routers, but the Wellfleet representative was not certain at this point, as they had only recently been informed that their routers would be used on the DSInet. ``Preliminary ST-II Evaluation'' The final formal presentation was made by Michael Patton of BBN on ``Preliminary ST-II Evaluation.'' This talk centered around work done by the DSI Network Engineering group at BBN under contract from ARPA. A brief overview of the DSInet was given, including a map showing most of the sites connected to the DSInet. The DSInet has nodes located throughout the US and as far away as Germany and Korea. It is an ``around the world network'' with over fifty sites connected presently. The DSInet architecture is built on a foundation of ``Wideband Packet Switches'' (BBN Butterfly's) connected to local BBN T/20V routers which handle routing of IP and ST-II. Local systems are connected to networks attached to the T/20V router. The testing done by BBN is being conducted in phases. The first phase was a simple connection of two Sun workstations on separate Ethernet's connected via a T/20V router. A traffic generator from SRI was used to provide the traffic and the bandwidth utilization was monitored to ensure that ST-II and IP were each running within their allocation limits. The traffic characteristics, network design, and end systems were changed in each phase to increase the stress on the network. Further testing is continuing to stress the network further. After a minor digression about IP multicast, the group moved on to a list of possible discussion topics. That list included: Lack of State Transitions (14) Routing (2) FlowSpec issues (1) Use of Class D addresses (4) Heterogeneous FlowSpecs (1) ST-II MIB (2) Timestamps and negotiation (0) ReverseCharge option (0) TargetList parameter (0) Point-to-Point option (0) Header changes (2) Full Duplex (1) Reason Codes (1) MTU discovery (0) Hello/Status/Notify/Stream Data Flow (1) Source routing (0) HID negotiation incompatibilities (4) ErroredPDU pointer (0) Groups of Streams use (8) Use over Ethernet/subnets (0) IP Encapsulation (1) Join/Leave Streams (6) Transport Protocol Interaction (e.g. RTP) (4) Subset implementation (2) Stream naming simplify (0) From here the group started to discuss various issues. It was decided, that in spite of IETF tradition, the group would vote on which topics people felt were most important to address, and the preferences are listed in parentheses in the list above. It should be noted that many topics that did not receive votes above were later discussed and it seems clear that many, if not all, will require the attention of the working group. A number of brief discussions followed the vote. o The size of the HID space (should it be bigger to accomodate >64K simultaneous streams through a single system?) o Whether timestamps should be removed since none of the implementors could figure out how to make them work (the group decided to remove timestamps) o Whether the TargetList parameter could be removed. It was generally felt that it could be but a mechanism for performing the function of the TargetList needs to be documented before removing it. o The ReverseCharge option, which is a FlowSpec issue and thus should be discussed when FlowSpec issues are addressed. o Point-to-point, on which there was no clear consensus. This will need to be discussed on the mailing list. o MTU discovery. No conclusion about what to do with this. It relates to how the upper layers can be signaled to fragment packets such that they can traverse the smallest link a stream crosses. o Use of ST-II over Ethernet. This is really a general subnet issue and will require a set of ``ST-II over ...'' much as there are ``IP over ..''. documents today that address how subnet-specific issues such as multicast address allocation are handled. o Data link layer multicast, which it was agreed could be handled in the ``ST-II over ...'' documents. o Source routing. This is used by some implementations, so it will need to be investigated further to determine whether it should remain. o HID space. If the header requires an extra byte to word-align it, we may bump the HID space to 24 or 32 bits, but we think 16 bits is sufficient. o Stream names, which have been an annoyance to many implementors. A poll will be taken of the other implementors (primarily BERKOM project members) to see what their consensus on the usefulness of stream names is. o The ErroredPDU error pointer. The group either needs to define exactly where the pointer goes or else eliminate it. It was felt that this should be discussed along with Reason Codes, so a final decision will be made after Reason Codes are sorted out. o SAP size. A proposal was made to limit SAP sizes to 2 bytes, but BBN has used 6 byte SAPs in at least one application, so more discussion will be required. o Priority bits and their use for supporting heterogeneous streams. This relates closely to the support of heterogeneous flowspecs and should be addressed at that time. The group would need to define how priority bits relate to delivering a partial stream to various receivers. o Use of ST over ATM, especially as it relates to ATM's ability to mark certain cells for dropping under conditions of overload on the network. The meeting ended with a discussion of what other people were using ST-II for. IBM will start shipping a multimedia server (Ultimedia Server/6000) that uses ST-II to provide realtime data delivery to clients. Other users had been mentioned previously (BBN and the ARPA DSInet). On Thursday the discussion turned to finding people willing to work on various issues, defining the scope of various problems, identifying people willing to work on writing the Internet-Drafts and the RFC, classifying protocol issues, and identifying work that needs to be completed prior to the Seattle IETF meeting. State Transition and State Definition Problem We started by discussing the State Transition and State Definition problem. Luca Delgrossi presented the state transition diagrams developed by IBM during implementation of the HeiTS stack. Luca agreed to make PostScript and ASCII versions of the state transition diagrams available via anonymous FTP so that others could review them. The PostScript versions should be available by November 19, while the ASCII versions might take a bit longer to create. People agreed that they needed time to study the state diagrams before volunteering to work on updating them, so a call for participation will be done over the mailing list. Groups of Streams Lou Berger discussed his ideas for the use of Groups of Streams. This could be used for associating independent streams (to allow ``channel switching'' while only allocating bandwidth for a small number of channels), bandwidth aggregation/sharing (for teleconferences), subnet multicast address sharing, identifying interdependence of streams, or sending hierarchically encoded data in multiple grouped streams. Lou, Skip Harboth, and Sybille Schaller from IBM in Heidelberg will look at defining Groups of Streams more fully and will then present a proposal to the mailing list. Join/Leave Stream Luca presented the Join/Leave stream idea as a way to allow targets to join a stream without having the source send a CONNECT message. This would save 1/2 RTT in the stream setup phase and would be accomplished by having the would-be recipient send a Join message toward the origin. As soon as the Join hit a router that was carrying the stream, that router would send a CONNECT back to the receiver and negotiation would continue ``normally,'' with the exception that the router would be the origin for that receiver instead of the original data sender. A second proposal was that a backward path would be created from the would-be receiver toward the origin. This caused a lot of concern about requiring duplicate state machines in systems to handle a reverse-connection and also because this flows backward from the way routes are traditionally built. There was no consensus on this idea. The group asked IBM to write this up more fully and present it to the mailing list for discussion. After the list determines that this is (or is not) something that should be pursued, volunteers will (or will not) be solicited. Future Plans The discussion moved on to who would edit and write the Internet-Drafts and the RFC. Luca and Steve DeJarnett agreed to work on this, and Lou Berger said he would be willing to help out. The editors plan to base the new drafts and RFC on RFC 1190, but expect that a substantial rewrite and reorganization will be required. The editors intend to make PostScript and ASCII text versions available for both the drafts and (hopefully) the RFC. Mark Pullen suggested that an interim meeting should take place in late January or early February to work on the Internet-Draft. Mark offered to host the meeting. Most people seemed to think this was a good idea and it will be suggested to the mailing list. Subjects that are likely to be discussed in the near future include: o HIDs with the possibility of removing the negotiation and just using globally-unique identifiers at each hop instead. o Groups of Streams, and how you might use them to aggregate streams for bandwidth sharing and multicast address allocation. o State Transition diagrams. Define them for the current protocol and then update them based on changes made by the working group. o Join/Leave streams. Further specify how this might work for receiver-initiated communication. [These minutes, while the product of discussions of the entire group, are quite possibly biased by the thoughts and interests of the author. I've attempted to eliminate some of that bias by asking others to review these notes but in the end they represent what I understood to have happened at the meetings.] Attendees Susie Armstrong susie@mentat.com William Barns barns@gateway.mitre.org Lou Berger lberger@bbn.com Stephen Casner casner@isi.edu Richard Colella colella@nist.gov Steve DeJarnett steve@ibmpa.awdpa.ibm.com Luca Delgrossi luca@ibmpa.awdpa.ibm.com Ed Ellesson ellesson@vnet.ibm.com Eugene Geer ewg@cc.bellcore.com Fengmin Gong gong@concert.net John Hanratty jhanratty@agile.com W.S. Harborth wharbort@ghost.darpa.mil Ken Hayward Ken.Hayward@bnr.ca Kathy Huber khuber@wellfleet.com David Jacobson dnjake@vnet.ibm.com Matthew Jonson jonson@ddn.af.mil Lee Kilpatrick leekil@bbn.com Byonghak Kim bhkim@cosmos.kaist.ac.kr Charles Kunzinger kunzinger@vnet.ibm.com Ted Kuo tik@vnet.ibm.com Thomas Maslen maslen@eng.sun.com Karen O'Donoghue kodonog@relay.nswc.navy.mil Zbigniew Opalka zopalka@agile.com Laura Pate pate@gateway.mitre.org Michael Patton map@bbn.com J. Mark Pullen mpullen@cs.gmu.edu Bala Rajagopalan braja@qsun.att.com Doris Roland droland@ghost.darpa.mil Hal Sandick sandick@vnet.ibm.com Henning Schulzrinne hgs@research.att.com Dallas Scott scott@fluky.mitre.org Michael See mikesee@vnet.ibm.com Vincent Shekher vin@sps.mot.com Ming Sheu msheu@vnet.ibm.com Michael Speer michael.speer@sun.com Michael St. Johns stjohns@arpa.mil George Swallow gswallow@bbn.com John Tavs tavs@vnet.ibm.com Matsuaki Terada tera@sdl.hitachi.co.jp Akihiro Tominaga tomy@sfc.wide.ad.jp Claudio Topolcic topolcic@cnri.reston.va.us Keisuke Uehara kei@cs.uec.ac.jp Jean Yao yao@cup.hp.com Shinichi Yoshida yoshida@sumitomo.com