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 on 6 and 7 December 1994 at the 31st IETF meeting in San Jose, California. Lou Berger chaired the meeting with Steve Jackowski acting as Scribe. Luca Delgrossi, the working group co-chair, was unable to attend. The objective of the meeting was to finalize all outstanding issues with the current Internet-Draft to prepare it for submission as an RFC, and to set the direction for the rest of the working group's activities. Lou first introduced the group's Area Director, Stev Knowles, who had a few comments for the group. Steve indicated that the IESG is not looking favorably on certain press statements about ST or ST-2+. The primary point was that some press has indicated that ST-2 is a new Internet Standard. As stated in the working group's charter, ST is on the experimental track and will not be a ``Internet Standard.'' Stev requested that those involved with ST make sure that they, and their respective organizations, properly represent the work on ST in the IETF. Agenda The agenda for the rest of sessions was: o Agenda bashing o Status of draft o Overview of changes o Detailed review of draft o Discussion on open issues o Wrap up Status of the Draft The current draft is draft-ietf-st2-spec-01.fps, txtg. It is the second draft issued since the Toronto meeting. The next version is in progress and will be issued in January. It is expected that this will be a complete draft. Originally, the working group had planned to produce three RFCs: 1. Introduction to ST technology 2. Design of ST2 protocol 3. Protocol message formats At the Toronto meeting it was agreed to merge the message formats into the Design document. In this meeting it was agreed to consolidate the key portions of the Stand-alone Introduction with the Introduction of the Design Document (Section 1). Thus, the main output of this working group will be published as one document. Since the State Diagrams section has not been reviewed to the same level as the rest of the draft, it was agreed that the diagrams will be finalized and published separately. Overview of Changes An overview on changes in the draft since Toronto was given. A list of sections that had been updated or written was review. The group also reviewed which sections still need updating. Detailed Review of Draft Moving on to other sections of the current document, the group reviewed changes to the current Internet-Draft section by section and discussed and resolved any outstanding issues: Section 1 The merge of the introduction draft into Section 1 is still in progress. The current draft now has an introductory section, but it is not yet complete. Section 2 There were no changes to Section 2. Section 3 SCMP Functional Description (3) needs an introduction of types of streams and impact on states. This section may also serve as a place for examples of applications using the various types of streams such as when different levels of Join authorization are used. In Section 3.1.4.1, text will be updated to indicate that excess resources should be released when processing ACCEPT. In 3.2.2 and 3.4.2, Join Authorization was introduced based on the IBM implementation. Their implementation included a level that the group agreed (at GMU) could be implemented by using an out-of-band message. This level, known as `Ask Origin' will be deleted from the next version of the draft. It was also pointed out that state is a critical aspect of the Join authorization. That is, if the origin is not notified of the Join, state information is not complete, and recovery is not possible. An issue related to join level 2 (OK, do not notify origin) was discussed next. The issue is that with level 2 streams an origin may not be able to disconnect specific targets because full state is not maintained in all ST agents. A method to support this type of disconnect was proposed at GMU by one of the attending students. The method is to flood the disconnect to all next hop agents when the join level is 2 and the specified target is unknown. The group unanimously agreed that this solution provides uniformity at the application level and therefor should be used. Two issues were discussed relating to Section 3.4.2. The first was that the Join FlowSpec is not needed and references will be removed from the document. The second issue was that a JOIN-REJECT message type had been discussed but was not in the latest draft. It was agreed that this message should still be added. In Section 3.4.4 a description of Refuse handling under different join levels will be added. The next issue related to Section 3.4.5. The issue is that while processing a CHANGE message, an agent may interrupt the flow of data. It was agreed that this is not preferred behavior, and that by default the processing of a CHANGE message should not interrupt data delivery. This implies that CHANGE messages that require interruption of data flow to satisfy the request must be rejected. It was also agreed that an `interruptible' flag will be added to the change message that indicates its is acceptable to interrupt data flow while processing the change request. Section 4 Two issues were discussed related to Sections 4.1.1 and 4.1.2. The first issue was that the handling of the case of where a CONNECT message is acknowledged but an ACCEPT is never received. This case needs to be added. The second issue is that these sections still need to be made consistent with Section 7.3. In Section 4.2.2, there is an issue with path convergence in the case of a `diamond' or loop topology: It is possible that a given agent will receive two connects for the same stream from two different previous hop agents. This problem has been seen in operational networks using ST. Lou proposed that this case can be handled by having the agent at the point of convergence send a refuse with a reason code of `path convergence' and include the target address of a valid target on the pre-existing stream to be used as a `hint target.' Each upstream agent receiving the REFUSE will check to see if the listed `hint target' exists in the agents stream state. If the `hint target' is not known, the REFUSE is propagated upstream. If the `hint target' is known, then the agent is the agent that split the stream. This agent can then use the next hop of the `hint target' as the next hop for the new target. This method handles the `stream-divergence' for all cases for full state streams. For streams that do not have full state maintained (join type `OK') this solution may not succeed. The group accepted the proposal. Section 5 Two issues were discussed related to Section 5.2. The first issue was that it is not always clear when recovery should be attempted. It was agreed to add a NoRecovery flag to the Refuse message, and that agents set the flag when they wish to indicate that recovery is not possible or has been tried too many times. The second issue is that the current draft has an error related to stream tear-down at the target. It was agreed to have the application tear down streams that have errors; they should not wait for a possible recovery. Section 6 Section 6 needs a minor update: in Section 6.1, GroupID and GroupName fields need to be fully specified. Section 7 A minor update is needed in Section 7.1. The stream ID generation function needs to be specified. This is basically the same as group name generation function. In Section 7.3 two variable names must be defined. Section 7.5 needs to be completed. This is a very simple section that will recommend discarding of lower priority traffic in the event of network congestion. One of the readers of the current draft pointed out that the draft does not cover handling of the case where next hop agents can not handle the indicated IP multicast address. Section 7.7 will be updated that when the next hop cannot handle a given IP multicast address (on IP encapsulated segments), the next hop agent should send a Refuse with appropriate reason code. A question was raised as to whether an IP multicast address could be included in a standard targetlist. It was pointed out that this would require significant state changes for the origin agents. Section 9 State machines need to be reviewed and updated. They will be published separately. Murali Rajagopal, the author of the state diagrams, gave a brief introduction to the state diagrams and agreed to coordinate the publishing of the state diagram document. One of the participants mentioned that he has a contractor that will be modeling both the RFC 1190 and current versions of ST. He agreed to make the results of this work available to the group. This should be very helpful in validating the new version. Section 10 Three issues were discussed related to Section 10. The first issue was that the SID, which is currently split in the ST header, needs to be made contiguous. The second issue is that in Section 10.3.2, the IPHops field will be added to the FlowSpec. The last issue is that reason codes will be reviewed via the mailing list. Section 11 It was pointed out that a number of changes that had been discussed during the sessions would require minor changes to the packet formats listed in Section 11. Additionally, one new issue was raised. The ErroredPDU parameter is only used in the ERROR message. Since this parameter is used by only one message, this parameter will be combined with the error message. Section 12 A list of suggested protocol constants needs to be created. Discussion on Open Issues The group discussed the idea of making the ST header compatible with the IP header. It was agreed that there were no real technical advantages to this as IP processing would have to be done in any case at ST-IP boundary agents. It was agreed that a delta between RFC 1190 and ST-2+ would be added to the current document. Steve Batsell will complete this and submit it to the chairs. Mark Pullen suggested the possibility of having one of his grad students create an implementation of ST-2+ if he could start with a solid version of ST. Steve Jackowski stated that he would explore the possibility of getting Mark a copy of Syzygy's code as a base. Lou Berger agreed to pass the FlowSpec by Craig Partridge for comments. Wrap Up A final version of the Internet-Draft will be published for review in mid January. Once review is complete the draft will be submitted to be published as an RFC. The next pass at a State Diagrams will be made available by January 1995. The target completion date of the state diagrams draft is March 1995. It is expected that the state diagram draft will be reviewed at the next IETF, and then the draft will be updated and submitted to be published as an RFC. Once state diagrams are complete the working group's efforts will be complete.