CURRENT_MEETING_REPORT_ Reported by Steven Jackowski/Syzygy Communications Minutes of the Internet Stream Protocol V2 Working Group (ST2) The ST2 Working Group met on Tuesday and Thursday. Luca Delgrossi and Lou Berger chaired the meetings with Steve Jackowski acting as scribe. The objective of these meetings was to resolve all outstanding issues in the revision to ST-II so that new Internet-Drafts could be completed by the end of September 1994. Tuesday The Tuesday meeting began with a review of working group actions to date. This included some substantial protocol simplification and the issuing of new drafts. The rest of the meeting was focused on reviewing the existing draft documents. In the latest revision, two of the drafts were combined. There are now two documents rather than three. They are Introduction to ST-II and ST Protocol Specification It was agreed that the Introduction document just required editing and no technical issues need to be resolved. So the group focused on review of the ST Protocol Specification (dated 24 July 94). The second draft includes many updated areas. Some areas still need to be written, which is the reason why the drafts have not been issued as Internet-Drafts. There are also some new areas. It was pointed out that the draft still needs a good introduction. The group discussed the name of the revised protocol. It was agreed that the new name would be ST-2+, and that it will be distinguished from ST-II by having a version number one greater than the current ST-II value. The rest of the meeting was spent reviewing the current draft. Key areas of change and clarification were highlighted. Areas discussed were: o User service description o Stream set-up o Data transfer o Stream modification o Stream tear-down o Stream set-up: exceptional cases o Failure detection and recovery o Groups of streams o Ancillary functions o FlowSpec o State machines User Service Description This section was updated per previously agreed upon changes. Key issues were when data can be sent and when messages may be processed. (Data will not be sent until at least one ACCEPT has been received by the origin.) It was agreed that drop messages will be added to the service model state machine to reflect the 'no change' of state in established, change, or add states. Stream Set-up This section was updated for clarity. The only change was that ACKs are required in response to CONNECT messages. The section will be updated to indicated that if a joining target cannot support minimum flowspec, it should refuse. Data Transfer This section was updated per previously agreed upon changes and mirrors the changes in the user service description. The additional topic of MTU was covered. MTU is now in the CONNECT and ACCEPT messages and is updated on a hop by hop basis. Maximum message size is obtained from the ACCEPT message. Stream Modification This section will be based on IBM's implementation. The basis of this section can be found in ibminet.awdpa.ibm.com:pub/st/st2-recv.ps. An open issue was identified that was discussed in the second session. It was also pointed out that the SID is missing in the JOIN packet format. Stream Tear-down No changes were made to this section. Stream Set-up: Exceptional Cases Sections on time-out handling and path convergence need to be updated. Time-out handling will be updated to include 2 time-out periods, one pre-ACK and one post, rather than one per message type. Path convergence has been removed for simplicity. Source Routing as an operational option will be dropped. Lastly it was agreed that Section 6.3 is in the wrong place and will be moved to stream setup section. Failure Detection and Recovery This section was updated for clarity. It was agreed that precedence will be the chosen word to replace StreamImportance, and that the section on recovery timeout needs to be clear about stream teardown. Stream preemption will also be clarified to allow intermediate nodes to optionally rebuild a stream after preemption. In this case, if successful, a REFUSE is not sent to the upstream node. Groups of Streams Previously agreed upon changes were documented. Ancillary Functions This section still needs to be updated. FlowSpec Previously agreed upon changes were documented. This included the definition of the Null FlowSpec for SCMP testing. The use of a uniform FlowSpec across single stream, and the introduction of QoS classes. Allocation implication of QoS classes were discussed in Thursday's session. This section will also be updated to cover FlowSpec reconciliation. State Machines The state machines were updated by Murali Rajagopal. They are available in postscript and were handed out in the meeting. Thursday The goal of the Thursday meeting was to resolve all major outstanding issues. The session began by listing all sections needing to be written or updated, but not containing any technical issues. Those sections are: 2.2.1 Empty target list 2.6 MTU discovery [new] 4.1 The origin adding new targets FlowSpec handling on stream expansion 4.2 A target joining a stream (import) 6.1 Setup failures Time-out handling 6.2 Further issues Path convergence 6.3.3 Join authorization (import) 7.1 Failure detection The rest of the meeting was spent reviewing issues to be resolved. The issues were: o SCMP fragmentation o CHANGE-REQUEST message o STATUS / HELLO messages o Groups of streams o FlowSpec o Sub-network usage o IP encapsulation / IP multicast o Sub-streams / drop priorities o Reason codes SCMP Fragmentation The issue discussed was handling of the case where SCMP messages are larger than the path MTU. Two alternatives were discussed: generic SCMP fragmentation and multiple messages and truncation. The group decided to maintain procedure of sending multiple messages and truncating long SCMP messages or parameters as currently specified in RFC1190. CHANGE-REQUEST Message This discussion centered around the issue of are CHANGE-REQUEST messages end-to-end messages or can they be generated by intermediate agents. It was agreed that as currently specified, CHANGE-REQUESTs are only end-to-end and can be supported out of band. Therefore this message will be eliminated. It was also agreed that if sub-streams were ever added this type of message may be needed by intermediate agents. STATUS/HELLO Messages Two separate issues were discussed. The first issue was if these messages should be combined. These messages share a very similar format but serve very different functions. It was agreed that these messages should be kept separate. The second issue discussed was the question of can HELLO be sent when no streams exist. Since HELLO is really designed to be a stream failure detection mechanism, it was decided to not allow HELLO message exchange when no streams exist. It was also pointed out that STATUS messages can be used to detect/poll neighbor ST agents. Groups of Stream The issue discussed was really if sub-set implementations are to be allowed. It was felt that sub-set implementations should not be included in the new spec, and that this was a major problem with RFC-1190. It was therefore agreed that support of groups of streams will be required. FlowSpec Two separate issues were discussed. The first issue was addressing the inability to specify an acceptable latency range. A proposal was put forward to add a latency range field. The origin would set maximum acceptable latency range. Each intermediated agent would add to minimum and maximum delay and check to see if maximum is exceeded. The possible latency range is maximum less minimum. This proposal was accepted. The second issue discussed was FlowSpec interpretation with predictive QoS. A proposal was put forward and was rejected. An alternative was accepted. The alternative was to use current size and rate fields as peak values, and to add new fields for average size and rate values. It was also agreed to investigate the viability of using other published FlowSpecs and not defining an ST specific FlowSpec. Sub-network Usage The issue discussed was the definition of expected resource and multicast address management services provided by sub-networks. It was agreed that all services are to be provided solely by each sub-network, and that sub-net issues are outside scope of document. References to sub-network issues will be eliminated from the document. It is expected that sub-network issues will be addressed in future documents, e.g. ST over ATM or ST over ethernet. IP Encapsulation/IP Multicast The definition of IP encapsulation of ST was reviewed. Some implications of RFC-1190 will be clarified in the new spec. A new field will also be added to count the number of IP encapsulated hops along a path. The spec will be clarified to state that the predictive capabilities are lost when IP encapsulation is used. The spec will also be updated to state that if the multicast parameter is used in the CONNECT message, the receiving agent must be able to receive on the specified address in order to accept the connection. Sub-streams/Drop Priorities Sub-streams and drop priorities are separate issues. It was agreed that drop priorities will be preserved. The sub-streams issue was that sub-streams have been brought up repeatedly in working group sessions, but no definition has yet been agreed upon. It was agreed that sub-streams will not be specified. The remaining bits will be left unspecified. These bits will not be set, not examined, and passed through by routers. This allows for possible future extensions to the protocol, even to support sub-streams. Reason Codes Reason codes still need to be reexamined and updated. The meeting concluded (about an 1 hour late) with a review of action items: o Investigate other FlowSpecs o Update introduction o Document finite state machine diagrams o Complete draft specification With no further business to discuss, the session was adjourned.