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.