Internet Standards/CD1.mdf/INET/IETF/ST2/94MAR.MIN

Text File | 1994-06-07 | 14.2 KB | 403 lines

CURRENT_MEETING_REPORT_



Reported by Steve Jackowski/Syzygy Communications

Minutes of the Internet Stream Protocol V2 Working Group (ST2)

This session of the IETF ST-II Working Group meeting was convened on 30
March 1994 at the Seattle Sheraton.  Luca Delgrossi chaired the meeting
and it was announced that Lou Berger would co-chair.

The main goal of the meeting was to continue progress on the new RFCs
for ST-II. In particular, ideas presented at the GMU meeting, and
debated since, were to be finalized to be incorporated into the draft
documents.

The agenda for this meeting was as follows:


   o Review the results and discussion from the 9-10 February 1994 GMU
     meeting

   o Review the initial draft documents.

   o Present planned modifications/clarifications to ST-II for final
     approval.

   o Discuss and finalize ST-II service definitions.

   o Finalize both service and implementation state diagrams.

   o Attempt to reach consensus on the outstanding technical issues:

      -  How to implement groups of streams.
      -  Refine definition of the JOIN implementation.
      -  Discuss problems of source routing
      -  Standardize FlowSpec formats.

   o Identify open issues.

   o Establish an attack plan for resolving open issues and finalizing
     RFCs.


The group then reviewed the discussions from the GMU meeting.  The major
topics included:


   o State diagrams for both the ST-II service and implementation.

   o Elimination of HIDs to simplify connection setup and
     implementation.

   o Elimination of options/parameters which are redundant or seldom
     used today.

   o The requirement for groups of streams.

   o Simplification of the process for stream joining by receivers.

   o The RFC structure:  There will be three initial Internet-Drafts
      -  Intro to ST-II
      -  High Level Design
      -  Protocol


The current drafts of the new RFC documents were discussed.  The
documents are available via FTP at:  ibminet.awdpa.ibm.com in pub/st.

Comments were requested to be sent to the mail list by 15 April.

Based on the GMU meeting and ongoing discussion since, several
modifications and clarifications to ST-II were presented, discussed, and
finalized.

It was noted that RFC 1190 needed clarification on how ST-II fits from
both a macroscopic (user application) and implementor's (with respect to
other system resources) point of view.  ST-II requires associated
entities:  Resource manager with access control, resource reservation,
resource scheduling, routing functions, and regulation/policing/data
enforcement are critical to a successful ST-II implementation.  These
co-requisites will be described in the new Introduction to ST-II
document.

ST-II service needs to be described via high level state diagrams to
enable applications to properly use the service and for implementors to
understand how applications will actually be used.  In particular,
clarification as to when data can be sent is crucial.  That is, is it
acceptable for data to be sent before a connection is completely
established?.

Implementor state diagrams/state machines and transitions are separate
from the service level diagrams.  They will actually describe internal
state transitions for origin, router, and target ST-II agents.

It was agreed to eliminate the full duplex connect.  It was pointed out
that though this was seldom used in most implementations, it was the
only way to allow a target to initiate a JOIN to an existing stream.
This capability will be preserved through the use of a much simpler
explicit JOIN request to be discussed later.

HID negotiation was eliminated because it can fail, and is complicated
in multicast environments.  Instead ST-II will use a stream ID (SID) as
a globally unique identifier.  This is composed of the origin IP address
plus a unique ID. Use of SID will not only simplify the connection
establishment, it means that the origin will be known for each data
packet.  This will have major implications in simplifying routing and
error handling.

Timestamps were eliminated and it was agreed to use a bit in the header
to differentiate data from SCMP. There will still be unused bits in the
header - originally drop priority.  These may now be free or reused
depending on final conclusions regarding use of sub-streams.

It was agreed to eliminate the RVLID and SVLID in SCMP packets.  This is
a consequence of elimination HIDs.

To simplify the CONNECT process with long target lists, it was agreed to
add a fragmentation capability for SCMP packets.  Data will not be
segmented.  The fragmentation feature will be written up and distributed
to the list.

For stream setup we must create a stream ID, invoke the routing
function, and set up TargetList which is either empty, less than the
MTU, or larger than MTU where fragmentation is used.  Then make the
reservation and propagate the CONNECT.

Error_in_response is eliminated.

How do we handle ERROR_IN_REQUEST? First, eliminate pointer to error.
This is awkward.  After some discussion, it was agreed to send back the
errored PDU.

As a consequence of these clarifications and modifications, ST-II has
been significantly simplified.  The following ST-II messages and
associated parameters will be eliminated:


     Error in response
     HID APPROVE
     HID CHANGE
     HID CHANGE REQ
     FreeHIDs
     HID
     NAME
     RFlowSpec
     Rgroup
     RHID
     RNAME
     HID REJECT
     Timestamps
     FDX
     point to point
     Rev-charge


The functionality message type, JOIN, has been added.


JOIN

The JOIN message is an additional SCMP message with a TargetList,
Flowspec and user data.  It will be used to simplify the addition of a
target system to a pre-existing stream at the target's request.

At connect time, there are four authorization levels that the stream
origin can specify with respect to JOINs:


     00 do not allow joins
     01 ask the origin before allowing target to join.
     10 okay to join but notify origin
     11 okay to join (do not have to notify)


In attempting to JOIN a stream, the target could specify a FlowSpec with
resource requirements that are equal to, less, or greater than the
original stream's requirement.  If the JOINing target needs more than
the current FlowSpec, it must first accept the current FlowSpec and then
propose a change later.

Note that this is not an enhancement.  The previous RFC allowed joining
through full duplex.  That is, a full duplex session could be requested
with the main stream FlowSpec set to zero, this created a reverse stream
only:  effectively an inefficient JOIN request by the receiver.

This explicit implementation of JOIN simplifies this function.  It is
the best solution now that full duplex CONNECT is eliminated from the
protocol.


Service Model and Implementation State Machines

The service model for application state information was accepted with
some discussion about empty streams skipping the pending state.  This
resulted in some discussion about combining ADD and PENDing states.
Although it is not necessarily optimal, the current model is sufficient.
Implementors may reduce states as long as service is identical.  Refer
to state transition table for details, not just to the service model
state diagram.  Note that the diagram will be corrected to include DROPs
only from the established state.

The Origin state machine is complicated because of target status.  The
Target state machine is simple.  The Router has two state machines.  One
for the origin side, one for the target side.

These state machines will be updated by Murali by 15 April to reflect
the results of the discussions and posted for review.

We then continued with discussion of outstanding technical issues and
this resulted in the bulk of the discussion for the meeting.

Although the actual state diagrams seem to be solid a question was
raised:  should the states be kept on a per-target or per next-hop
basis?  This was tabled for more discussion on pros and cons.

One topic was whether ACKs should be sent in response to a connect
before an ACCEPT or REFUSE is generated.  This is consistent with most
SCMP messages but requires an additional state transition during session
setup.  Opinion was split so this topic was tabled for later discussion.


Transmission of Data

There was much discussion about when data can be sent.  I.e., can data
be sent before the stream is established, and if so is this an error
condition, or should the data be handled if possible?

The strongest arguments against are that the receiver(s) may not have
resources, and the routers may have significant overhead and complex
decision processes in deciding what to do with data for streams that are
not established.

Decision:  No data will be sent unless an ACCEPT has been received on
that path for that stream.



Groups of Streams

Groups of streams are required to allow resource sharing.  Groups are
mentioned in RFC 1190 but not well defined.  As such there was
discussion on implementation of groups.  It was agreed that group
processing would be performed.  Key points about groups include:


   o Group membership is defined at stream creation time.
   o The group persists until the stream is deleted.
   o A stream may belong to multiple groups.


A group is equal to a stream plus a relationship.

Initial possible sharing relationships will include:


   o bandwidth sharing (mandatory)
   o fate
   o path
   o subnet addresses


The last three should be done by an ST agent on a best-effort basis, and
depend on the capabilities of ancillary modules like the MAC for
multicast group sharing.

A GROUP parameter will be added to the CONNECT packet.  Routers are
responsible for keeping group information.

Format of the GROUP parameter will include a unique ID as well as the
group requestor's IP address.  This is based on the current group
mechanism.

There was concern over tying the group to a requester since the
originator may leave the group.  A timestamp will be a part of the group
identifier to assure uniqueness.  Each relationship is represented by a
bitmap in the GROUP parameter.  If bandwidth sharing is specified, an
additional parameter is included to represent the maximum number of
maximum bandwidth streams that can send simultaneously.  For example, if
audio were sent to multiple receivers, the total number of acceptable
simultaneous audio streams is represented.


Data Received from Multiple Previous Hops Simultaneously on a Single
Stream

It was pointed out that multiple copies of data can be sent on a stream
in certain circumstances.  This problem can occur when the data path is
bifurcated (because of a temporary error), if there are multiple targets
with different policies, or if source routing based on the target is
used.

The group decided to select a simple approach.  The solution is to
refuse the connection or to create an error message when it is detected
that the same stream is received at an agent from two different network
interfaces.  This means that certain types of policies or source routing
combination will not be supported.


FlowSpec

The group agreed to add FlowSpec version 0 to facilitate
interoperability testing.  Version 0 means that no FlowSpec checking is
done.  A new FlowSpec is proposed as the base standard.  Version 7 will
be structured as follows:

QoS class will be added to offer guaranteed or predictive options.

It is proposed that each negotiable parameter have two values:  desired
and min/max acceptable value.  The desired is updated as the FlowSpec
moves to reflect the best reservation that can be made by that node.

Delay is handled specially.  It includes both desired and maximum delay,
current delay, and minimum delay to assist in jitter control.  Current
delay includes this agent's delay as well as propagation delay to the
downstream node.  Target nodes will add queuing delay to the
applications.

IP tunnelling count, hop count, and recovery timeout will be added to
the ACCEPT and CONNECT packets, not placed in the FlowSpec as some
suggested.


Sub-streams

Discussion of sub-streams was a hot issue that was temporarily suspended
until all have read Luca's paper on filtering.


ST-II over sub-net

Ethertype is an issue.  Current ST-II implementations use an unassigned
Ethertype (0x5354 = ``ST''). Either an assigned type value should be
used or, as specified in the RFC, IP's Ethertype should be used.  Chairs
will make a proposal whether Xerox should be contacted and an official
type requested.


Conclusion

Because time was running out, and most of the technical issues were
discussed, we assigned action items for short-term deliverables to the
responsible parties:


   o State machines (Murali by 4/15)
   o Groups, JOIN and FlowSpec (Luca)
   o Fragmentation of SCMP (Lou)
   o Sub-streams (All ! Luca)
   o Review of drafts (All by 4/18)
   o Drafts for Toronto (Luca)


We also listed most of the open issues which we have not had a chance to
discuss in detail and assigned a few responsible parties to prepare
proposals for later discussion.  These included:


   o HID - SID (Charlie)
   o Sub-streams (Luca)
   o Hello/Status/Notify (Murali)
   o recovery
   o Routing
   o IP encapsulation
   o ST-II MIB
   o subnets
   o Preemption
   o Reason Codes


With time running out, Luca brought the meeting to a close, noting that
there was still much work to be done before the July meeting in Toronto.


Attendees

Edward Allen             [e-mail]
Stephen Batsell          [e-mail]
Lou Berger               [e-mail]
Carsten Bormann          [e-mail]
Ute Bormann              [e-mail]
Michael Brescia          [e-mail]
Stephen Casner           [e-mail]
Eric Crawley             [e-mail]
Luca Delgrossi           [e-mail]
Paul Goransson           [e-mail]
Don Hoffman              [e-mail]
Kathy Huber              [e-mail]
Phil Irey                [e-mail]
Steven Jackowski         [e-mail]
Charles Lynn             [e-mail]
Joseph Pang              [e-mail]
J. Mark Pullen           [e-mail]
Murali Rajagopal         [e-mail]
Sibylle Schaller         [e-mail]
Ming-Jye Sheu            [e-mail]
Michael Speer            [e-mail]
Sally Tarquinio          [e-mail]
Claudio Topolcic         [e-mail]