CURRENT_MEETING_REPORT_ Reported by Steven Jackowski/Syzygy Communications Minutes of the Internet Stream Protocol V2 Working Group (ST2) Introduction The ST2 Working Group met in both morning and afternoon sessions on 3 April at the 32nd IETF meeting in Danvers, Massachusetts. Lou Berger chaired the meeting with Steve Jackowski acting as Scribe. Luca Delgrossi, the working group co-chair was unable to attend due to a new job. Because the protocol specifications have been submitted as an RFC, the primary objective of the meeting was to review and discuss the draft of the State Machine document as well as to determine the future direction of the group. During the meeting, Frank Kastenholtz introduced himself as one of the new Internet Area co-Directors. Sue Thompson is the other new co-Director. Agenda o Agenda Bashing o Status of Group o State Machines - Status - Detailed Discussion o Open Issues o Wrap-up Working Group Status The ST2 Working Group had two main chartered goals: 1. Protocol Specification 2. State Machines Over the mailing list, the group agreed to submit the ST protocol specification for publications as an Experimental RFC. The protocol specification, draft-ietf-st2-spec-04.fps,txtg, was submitted on 24 March. Publication is awaiting IESG action. The State Machine draft, draft-ietf-st2-state-00.fps,txtg, is in progress with a targeted completion of June. If the State Machine draft is indeed completed in this time frame, the working group may not meet in Stockholm. The intent is to publish the State Machine document as an Informational RFC. Detailed Review of the State Machine Draft The group began a detailed, section by section review of the State Machine draft and began to identify issues. This discussion was led by Murali Rajagopal, the author of the State Machine draft. Sections 2, 3 and General Issues Murali Rajagopal started his presentation of state machines by reviewing the current draft. He presented this main design change from previous drafts which is to use FIFO queues between state machines. He also reviewed the message/response table and a message direction table, which provide a good representation of protocol message relationships. Eric Crawley pointed out a discrepancy between the State Machine document and the protocol specification in that the State Machine document refers to `Origin Side' and `Target Side' while the protocol specification uses `upstream' and `downstream' respectively. It was agreed that the State Machine document would be updated to use the terms `previous hop' and `next hop' for neighbor dependent terms and `upstream' and `downstream' for general terms. Section 4: Origin State Machines It was agreed that references to a `State Machine per interface' would be changed to `State Machine per next hop.' This clarification is required because it is likely that there is more than one next hop per interface. After some discussion, it was agreed to add a reference to timeouts with respect to awaiting ACCEPTs or REFUSEs. A timeout in this circumstance is an implicit REFUSE. The issue of how the sending of data relates to the described states was discussed at some length. This issues is described in greater detail below. The group also discussed the issue of handling a REFUSE message from an unrelated target while in the middle of a sub-state machine? It was agreed that all sub-state machines must process REFUSEs from unrelated targets. Section 5: Router State Machines The group agreed that the Router State Machine needs clarification as to when data is permitted and which state machine (upstream or downstream) controls distribution of data when the multicast group is in transition. It was pointed out that both of the current Router State Machines may be needlessly complex: that states to handle REFUSE, ACCEPT, etc., may be unnecessary. Once in the Stream-established state, these messages are events that simply require an ACK. There should be no state transition. It was reiterated that JOIN state does not need to be kept by the router. This will be discussed off line and updated in the specification accordingly. Section 6: Target State Machine It was pointed out that there is an error in the draft, and ADD functionality should be removed from the Target State Machine. The morning session was adjourned after agreeing to use the afternoon session to hit the key issues raised in the morning. Review of Open Issues The afternoon session was used to begin to resolve the following issues which were identified in the morning session: o Establish how to handle sending of data after first accept. o Resolve where data is forwarded and where is it dropped. o Is `E' bit handling on Refuse (refuse of change but do not take down stream) included in the current diagrams? o Interaction with Local Resource Management is not considered. o How are Timeouts addressed? o How do we include Error Conditions or failure detection. o Do we need an API interface description? When Can We Send Data The issue of the relationship between when data forwarding is allowed and related to specific states was discussed at some length. It was agreed that there needs to be more definition of function within specific states. In particular, in which states is data transmission allowed. It was agreed that states could be eliminated in the Origin State diagram to allow existence of the stream and data transmission. It was agreed that data forwarding should not be explicitly linked to a state change, and that data forwarding would be separated from control state machines. This may also require a separate state machine for data forwarding which gets triggered on processing an ACCEPT message. There was much discussion on null streams and JOINs. It became clear that there needs to be a per-stream higher level view of the state for the Origin. That is, we need state for each stream which includes the possibility of null streams and JOINs. However, there still exists context on a per-next-hop basis. This whole topic is taken as an action item to be resolved in the next version of the draft. `E' Bit A general comment was made that the processing of the `E' bit in REFUSE messages must be added to all state diagrams. Local Resource Management (LRM) It was agreed that the state machines are missing references to LRM functions. While LRMs are not defined in the protocol specification, certain messages require processing by the LRM. These messages are: CONNECT, ACCEPT, CHANGE, REFUSE and DISCONNECT. Diagrams will be updated to show LRM interfaces on processing these messages. Other Items Several general points were made on: o Timeouts Timeout handling will be added in the next draft by Sharon Sergeant. o Failure detection State machines for failure processing need to be added. These are largely orthogonal to the control state machines. o API mapping It was agreed that we a mechanism to add API interfaces to state machines. This does not mean specifying an API, it will just describe the suggested API interactions with the state machine. This will be based on the service model description of in the protocol specification. In addition to simplification and consolidation of existing state machines, as well as inclusion of the state machines described above for Data Forwarding, Failure Detection, and APIs, there were two outstanding issues that must be resolved in the next draft with respect to the router state machines: 1. The handling of JOIN/JOIN REFUSE and upstream-oriented messages must be revisited. 2. The interfaces between origin and target sides of the router state machines must be specified in more detail. Action Items The next draft of State Machines is targeted for mid-May. Tim O'Malley and Steve Jackowski agreed to assist Murali with the preparation of new state machines for the next draft. Eric Crawley and Lou Berger will provide input and review these updates. The decision to meet in Stockholm will be based on the status of the State Machine draft at that point.