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.