CURRENT_MEETING_REPORT_ Reported by Steve Jackowski/Syzygy Communications Minutes of the Internet Stream Protocol V2 Working Group (ST2) This session of the IETF ST-II Working Group meeting was convened on 30 March 1994 at the Seattle Sheraton. Luca Delgrossi chaired the meeting and it was announced that Lou Berger would co-chair. The main goal of the meeting was to continue progress on the new RFCs for ST-II. In particular, ideas presented at the GMU meeting, and debated since, were to be finalized to be incorporated into the draft documents. The agenda for this meeting was as follows: o Review the results and discussion from the 9-10 February 1994 GMU meeting o Review the initial draft documents. o Present planned modifications/clarifications to ST-II for final approval. o Discuss and finalize ST-II service definitions. o Finalize both service and implementation state diagrams. o Attempt to reach consensus on the outstanding technical issues: - How to implement groups of streams. - Refine definition of the JOIN implementation. - Discuss problems of source routing - Standardize FlowSpec formats. o Identify open issues. o Establish an attack plan for resolving open issues and finalizing RFCs. The group then reviewed the discussions from the GMU meeting. The major topics included: o State diagrams for both the ST-II service and implementation. o Elimination of HIDs to simplify connection setup and implementation. o Elimination of options/parameters which are redundant or seldom used today. o The requirement for groups of streams. o Simplification of the process for stream joining by receivers. o The RFC structure: There will be three initial Internet-Drafts - Intro to ST-II - High Level Design - Protocol The current drafts of the new RFC documents were discussed. The documents are available via FTP at: ibminet.awdpa.ibm.com in pub/st. Comments were requested to be sent to the mail list by 15 April. Based on the GMU meeting and ongoing discussion since, several modifications and clarifications to ST-II were presented, discussed, and finalized. It was noted that RFC 1190 needed clarification on how ST-II fits from both a macroscopic (user application) and implementor's (with respect to other system resources) point of view. ST-II requires associated entities: Resource manager with access control, resource reservation, resource scheduling, routing functions, and regulation/policing/data enforcement are critical to a successful ST-II implementation. These co-requisites will be described in the new Introduction to ST-II document. ST-II service needs to be described via high level state diagrams to enable applications to properly use the service and for implementors to understand how applications will actually be used. In particular, clarification as to when data can be sent is crucial. That is, is it acceptable for data to be sent before a connection is completely established?. Implementor state diagrams/state machines and transitions are separate from the service level diagrams. They will actually describe internal state transitions for origin, router, and target ST-II agents. It was agreed to eliminate the full duplex connect. It was pointed out that though this was seldom used in most implementations, it was the only way to allow a target to initiate a JOIN to an existing stream. This capability will be preserved through the use of a much simpler explicit JOIN request to be discussed later. HID negotiation was eliminated because it can fail, and is complicated in multicast environments. Instead ST-II will use a stream ID (SID) as a globally unique identifier. This is composed of the origin IP address plus a unique ID. Use of SID will not only simplify the connection establishment, it means that the origin will be known for each data packet. This will have major implications in simplifying routing and error handling. Timestamps were eliminated and it was agreed to use a bit in the header to differentiate data from SCMP. There will still be unused bits in the header - originally drop priority. These may now be free or reused depending on final conclusions regarding use of sub-streams. It was agreed to eliminate the RVLID and SVLID in SCMP packets. This is a consequence of elimination HIDs. To simplify the CONNECT process with long target lists, it was agreed to add a fragmentation capability for SCMP packets. Data will not be segmented. The fragmentation feature will be written up and distributed to the list. For stream setup we must create a stream ID, invoke the routing function, and set up TargetList which is either empty, less than the MTU, or larger than MTU where fragmentation is used. Then make the reservation and propagate the CONNECT. Error_in_response is eliminated. How do we handle ERROR_IN_REQUEST? First, eliminate pointer to error. This is awkward. After some discussion, it was agreed to send back the errored PDU. As a consequence of these clarifications and modifications, ST-II has been significantly simplified. The following ST-II messages and associated parameters will be eliminated: Error in response HID APPROVE HID CHANGE HID CHANGE REQ FreeHIDs HID NAME RFlowSpec Rgroup RHID RNAME HID REJECT Timestamps FDX point to point Rev-charge The functionality message type, JOIN, has been added. JOIN The JOIN message is an additional SCMP message with a TargetList, Flowspec and user data. It will be used to simplify the addition of a target system to a pre-existing stream at the target's request. At connect time, there are four authorization levels that the stream origin can specify with respect to JOINs: 00 do not allow joins 01 ask the origin before allowing target to join. 10 okay to join but notify origin 11 okay to join (do not have to notify) In attempting to JOIN a stream, the target could specify a FlowSpec with resource requirements that are equal to, less, or greater than the original stream's requirement. If the JOINing target needs more than the current FlowSpec, it must first accept the current FlowSpec and then propose a change later. Note that this is not an enhancement. The previous RFC allowed joining through full duplex. That is, a full duplex session could be requested with the main stream FlowSpec set to zero, this created a reverse stream only: effectively an inefficient JOIN request by the receiver. This explicit implementation of JOIN simplifies this function. It is the best solution now that full duplex CONNECT is eliminated from the protocol. Service Model and Implementation State Machines The service model for application state information was accepted with some discussion about empty streams skipping the pending state. This resulted in some discussion about combining ADD and PENDing states. Although it is not necessarily optimal, the current model is sufficient. Implementors may reduce states as long as service is identical. Refer to state transition table for details, not just to the service model state diagram. Note that the diagram will be corrected to include DROPs only from the established state. The Origin state machine is complicated because of target status. The Target state machine is simple. The Router has two state machines. One for the origin side, one for the target side. These state machines will be updated by Murali by 15 April to reflect the results of the discussions and posted for review. We then continued with discussion of outstanding technical issues and this resulted in the bulk of the discussion for the meeting. Although the actual state diagrams seem to be solid a question was raised: should the states be kept on a per-target or per next-hop basis? This was tabled for more discussion on pros and cons. One topic was whether ACKs should be sent in response to a connect before an ACCEPT or REFUSE is generated. This is consistent with most SCMP messages but requires an additional state transition during session setup. Opinion was split so this topic was tabled for later discussion. Transmission of Data There was much discussion about when data can be sent. I.e., can data be sent before the stream is established, and if so is this an error condition, or should the data be handled if possible? The strongest arguments against are that the receiver(s) may not have resources, and the routers may have significant overhead and complex decision processes in deciding what to do with data for streams that are not established. Decision: No data will be sent unless an ACCEPT has been received on that path for that stream. Groups of Streams Groups of streams are required to allow resource sharing. Groups are mentioned in RFC 1190 but not well defined. As such there was discussion on implementation of groups. It was agreed that group processing would be performed. Key points about groups include: o Group membership is defined at stream creation time. o The group persists until the stream is deleted. o A stream may belong to multiple groups. A group is equal to a stream plus a relationship. Initial possible sharing relationships will include: o bandwidth sharing (mandatory) o fate o path o subnet addresses The last three should be done by an ST agent on a best-effort basis, and depend on the capabilities of ancillary modules like the MAC for multicast group sharing. A GROUP parameter will be added to the CONNECT packet. Routers are responsible for keeping group information. Format of the GROUP parameter will include a unique ID as well as the group requestor's IP address. This is based on the current group mechanism. There was concern over tying the group to a requester since the originator may leave the group. A timestamp will be a part of the group identifier to assure uniqueness. Each relationship is represented by a bitmap in the GROUP parameter. If bandwidth sharing is specified, an additional parameter is included to represent the maximum number of maximum bandwidth streams that can send simultaneously. For example, if audio were sent to multiple receivers, the total number of acceptable simultaneous audio streams is represented. Data Received from Multiple Previous Hops Simultaneously on a Single Stream It was pointed out that multiple copies of data can be sent on a stream in certain circumstances. This problem can occur when the data path is bifurcated (because of a temporary error), if there are multiple targets with different policies, or if source routing based on the target is used. The group decided to select a simple approach. The solution is to refuse the connection or to create an error message when it is detected that the same stream is received at an agent from two different network interfaces. This means that certain types of policies or source routing combination will not be supported. FlowSpec The group agreed to add FlowSpec version 0 to facilitate interoperability testing. Version 0 means that no FlowSpec checking is done. A new FlowSpec is proposed as the base standard. Version 7 will be structured as follows: QoS class will be added to offer guaranteed or predictive options. It is proposed that each negotiable parameter have two values: desired and min/max acceptable value. The desired is updated as the FlowSpec moves to reflect the best reservation that can be made by that node. Delay is handled specially. It includes both desired and maximum delay, current delay, and minimum delay to assist in jitter control. Current delay includes this agent's delay as well as propagation delay to the downstream node. Target nodes will add queuing delay to the applications. IP tunnelling count, hop count, and recovery timeout will be added to the ACCEPT and CONNECT packets, not placed in the FlowSpec as some suggested. Sub-streams Discussion of sub-streams was a hot issue that was temporarily suspended until all have read Luca's paper on filtering. ST-II over sub-net Ethertype is an issue. Current ST-II implementations use an unassigned Ethertype (0x5354 = ``ST''). Either an assigned type value should be used or, as specified in the RFC, IP's Ethertype should be used. Chairs will make a proposal whether Xerox should be contacted and an official type requested. Conclusion Because time was running out, and most of the technical issues were discussed, we assigned action items for short-term deliverables to the responsible parties: o State machines (Murali by 4/15) o Groups, JOIN and FlowSpec (Luca) o Fragmentation of SCMP (Lou) o Sub-streams (All ! Luca) o Review of drafts (All by 4/18) o Drafts for Toronto (Luca) We also listed most of the open issues which we have not had a chance to discuss in detail and assigned a few responsible parties to prepare proposals for later discussion. These included: o HID - SID (Charlie) o Sub-streams (Luca) o Hello/Status/Notify (Murali) o recovery o Routing o IP encapsulation o ST-II MIB o subnets o Preemption o Reason Codes With time running out, Luca brought the meeting to a close, noting that there was still much work to be done before the July meeting in Toronto. Attendees Edward Allen eallen@wellfleet.com Stephen Batsell batsell@itd.nrl.navy.mil Lou Berger lberger@bbn.com Carsten Bormann cabo@informatik.uni-bremen.de Ute Bormann ute@informatik.uni-bremen.de Michael Brescia brescia@bbn.com Stephen Casner casner@isi.edu Eric Crawley kaufman@scrc.symbolics.com Luca Delgrossi luca@ibmpa.awdpa.ibm.com Paul Goransson paulg@wellfleet.com Don Hoffman hoffman@eng.sun.com Kathy Huber khuber@wellfleet.com Phil Irey pirey@relay.nswc.navy.mil Steven Jackowski stevej@syzygycomm.com Charles Lynn clynn@bbn.com Joseph Pang pang@bodega.stanford.edu J. Mark Pullen mpullen@cs.gmu.edu Murali Rajagopal murali@mitre.org Sibylle Schaller schaller@ibmpa.awdpa.ibm.com Ming-Jye Sheu msheu@vnet.ibm.com Michael Speer michael.speer@sun.com Sally Tarquinio sallyt@gateway.mitre.org Claudio Topolcic topolcic@bbn.com