CURRENT_MEETING_REPORT_
Reported by Luca Delgrossi/IBM
Minutes of the Internet Stream Protocol V2 Working Group (ST2)
The ST2 Working Group met in two sessions. Prior to the first session,
Craig Partridge of BBN gave a talk on his experiences with ST-II. Craig
did one of the first ST-II implementations with Steven Pink at the
Swedish Institute of Computer Science in 1992.
Craig pointed out some of the weaker points of ST-II, including the fact
that the specification (RFC 1190) forced the implementor to guess at
what was intended in certain situations. Protocol complexity was also
raised as an issue. The points raised all seemed consistent with the
experience of the other implementors and certainly helped to motivate
everyone prior to the start of the first working group meeting which was
held immediately after the talk.
The working group meeting began with a brief review of the goals of the
working group, the milestones specified in the charter, and a review of
the agenda for the two working group meetings planned for this week.
IBM Heidelberg Transport System (HeiTS)
Luca Delgrossi of the IBM European Networking Center presented an
overview of the IBM HeiTS (Heidelberg Transport System) stack, which
includes an ST-II implementation. HeiTS is strongly focused on
providing guaranteed quality of service to applications, particularly
multimedia applications. HeiTS uses its own FlowSpec which is
significantly simpler than the RFC 1190 FlowSpec. In addition to
implementing ST-II, HeiTS also provides a Resource Management Subsystem
which handles resource reservation for CPU, [memory] buffers, and
network and communication adapter resources. In addition, HeiTS will
interface with a ``Central Resource Allocator'' to coordinate network
resource reservations in a complex network environment. Luca ended his
presentation by discussing some possible protocol extensions or
modifications that could make ST-II a more scalable and useful protocol,
including the ability for targets to initiate a connection by joining an
existing stream at a router instead of communicating directly with the
origin to join a stream.
``ST-II Testing and Evaluation''
Doris Roland from Houston Associates, Inc. (HAI) gave a presentation on
``ST-II Testing and Evaluation'' which discusses some testing that HAI
is doing for ARPA and the Defense Simulation Internet (DSInet). The
DSInet is an evolution of the Terrestrial Wideband Network (TWBnet)
which runs ST-II at about half of the sites on the network. Houston
Associates, Inc. provides support for users of the DSInet and is
performing their testing independently of other testing being done by
BBN, which is the contractor responsible for building and operating the
DSInet. The DSInet runs simulation exercises and video conferencing
using ST-II to carry the realtime traffic. The HAI test plan consists
of multiple stages, each of increasing complexity. They are explicitly
testing stream setup, bandwidth reservation, routing, data transfer,
stream modification, multicasting, and stream teardown. Their ultimate
goal is to run multiple simulation exercises over portions of the
backbone to see how well the overall system functions.
HAI Test Plan
After Doris's presentation, the group discussed some of the details of
the HAI test plan, which included the measurement of delay variance in
the network. Since a relatively low upper delay bound was specified,
group members wondered why delay variance needed to be measured. The
final answer was that the buffer space on the end systems is limited and
excessive delay variance can cause buffers to overflow. An additional
discussion item was brought up when it was mentioned that Wellfleet had
developed an ST-II router for ARPA and was going to be deploying it on
the DSInet. The group wanted to know whether this would be made
generally available in Wellfleet's routers, but the Wellfleet
representative was not certain at this point, as they had only recently
been informed that their routers would be used on the DSInet.
``Preliminary ST-II Evaluation''
The final formal presentation was made by Michael Patton of BBN on
``Preliminary ST-II Evaluation.'' This talk centered around work done
by the DSI Network Engineering group at BBN under contract from ARPA. A
brief overview of the DSInet was given, including a map showing most of
the sites connected to the DSInet. The DSInet has nodes located
throughout the US and as far away as Germany and Korea. It is an
``around the world network'' with over fifty sites connected presently.
The DSInet architecture is built on a foundation of ``Wideband Packet
Switches'' (BBN Butterfly's) connected to local BBN T/20V routers which
handle routing of IP and ST-II. Local systems are connected to networks
attached to the T/20V router. The testing done by BBN is being
conducted in phases. The first phase was a simple connection of two Sun
workstations on separate Ethernet's connected via a T/20V router. A
traffic generator from SRI was used to provide the traffic and the
bandwidth utilization was monitored to ensure that ST-II and IP were
each running within their allocation limits. The traffic
characteristics, network design, and end systems were changed in each
phase to increase the stress on the network. Further testing is
continuing to stress the network further.
After a minor digression about IP multicast, the group moved on to a
list of possible discussion topics. That list included:
Lack of State Transitions (14) Routing (2)
FlowSpec issues (1) Use of Class D addresses (4)
Heterogeneous FlowSpecs (1) ST-II MIB (2)
Timestamps and negotiation (0) ReverseCharge option (0)
TargetList parameter (0) Point-to-Point option (0)
Header changes (2) Full Duplex (1)
Reason Codes (1) MTU discovery (0)
Hello/Status/Notify/Stream Data Flow (1) Source routing (0)
HID negotiation incompatibilities (4) ErroredPDU pointer (0)
Groups of Streams use (8) Use over Ethernet/subnets (0)
IP Encapsulation (1) Join/Leave Streams (6)
Transport Protocol Interaction (e.g. RTP) (4) Subset implementation (2)
Stream naming simplify (0)
From here the group started to discuss various issues. It was decided,
that in spite of IETF tradition, the group would vote on which topics
people felt were most important to address, and the preferences are
listed in parentheses in the list above. It should be noted that many
topics that did not receive votes above were later discussed and it
seems clear that many, if not all, will require the attention of the
working group.
A number of brief discussions followed the vote.
o The size of the HID space (should it be bigger to accomodate >64K
simultaneous streams through a single system?)
o Whether timestamps should be removed since none of the implementors
could figure out how to make them work (the group decided to remove
timestamps)
o Whether the TargetList parameter could be removed. It was
generally felt that it could be but a mechanism for performing the
function of the TargetList needs to be documented before removing
it.
o The ReverseCharge option, which is a FlowSpec issue and thus should
be discussed when FlowSpec issues are addressed.
o Point-to-point, on which there was no clear consensus. This will
need to be discussed on the mailing list.
o MTU discovery. No conclusion about what to do with this. It
relates to how the upper layers can be signaled to fragment packets
such that they can traverse the smallest link a stream crosses.
o Use of ST-II over Ethernet. This is really a general subnet issue
and will require a set of ``ST-II over ...'' much as there are
``IP over ..''. documents today that address how subnet-specific
issues such as multicast address allocation are handled.
o Data link layer multicast, which it was agreed could be handled in
the ``ST-II over ...'' documents.
o Source routing. This is used by some implementations, so it will
need to be investigated further to determine whether it should
remain.
o HID space. If the header requires an extra byte to word-align it,
we may bump the HID space to 24 or 32 bits, but we think 16 bits is
sufficient.
o Stream names, which have been an annoyance to many implementors. A
poll will be taken of the other implementors (primarily BERKOM
project members) to see what their consensus on the usefulness of
stream names is.
o The ErroredPDU error pointer. The group either needs to define
exactly where the pointer goes or else eliminate it. It was felt
that this should be discussed along with Reason Codes, so a final
decision will be made after Reason Codes are sorted out.
o SAP size. A proposal was made to limit SAP sizes to 2 bytes, but
BBN has used 6 byte SAPs in at least one application, so more
discussion will be required.
o Priority bits and their use for supporting heterogeneous streams.
This relates closely to the support of heterogeneous flowspecs and
should be addressed at that time. The group would need to define
how priority bits relate to delivering a partial stream to various
receivers.
o Use of ST over ATM, especially as it relates to ATM's ability to
mark certain cells for dropping under conditions of overload on the
network.
The meeting ended with a discussion of what other people were using
ST-II for. IBM will start shipping a multimedia server (Ultimedia
Server/6000) that uses ST-II to provide realtime data delivery to
clients. Other users had been mentioned previously (BBN and the ARPA
DSInet).
On Thursday the discussion turned to finding people willing to work on
various issues, defining the scope of various problems, identifying
people willing to work on writing the Internet-Drafts and the RFC,
classifying protocol issues, and identifying work that needs to be
completed prior to the Seattle IETF meeting.
State Transition and State Definition Problem
We started by discussing the State Transition and State Definition
problem. Luca Delgrossi presented the state transition diagrams
developed by IBM during implementation of the HeiTS stack. Luca agreed
to make PostScript and ASCII versions of the state transition diagrams
available via anonymous FTP so that others could review them. The
PostScript versions should be available by November 19, while the ASCII
versions might take a bit longer to create. People agreed that they
needed time to study the state diagrams before volunteering to work on
updating them, so a call for participation will be done over the mailing
list.
Groups of Streams
Lou Berger discussed his ideas for the use of Groups of Streams. This
could be used for associating independent streams (to allow ``channel
switching'' while only allocating bandwidth for a small number of
channels), bandwidth aggregation/sharing (for teleconferences), subnet
multicast address sharing, identifying interdependence of streams, or
sending hierarchically encoded data in multiple grouped streams. Lou,
Skip Harboth, and Sybille Schaller from IBM in Heidelberg will look at
defining Groups of Streams more fully and will then present a proposal
to the mailing list.
Join/Leave Stream
Luca presented the Join/Leave stream idea as a way to allow targets to
join a stream without having the source send a CONNECT message. This
would save 1/2 RTT in the stream setup phase and would be accomplished
by having the would-be recipient send a Join message toward the origin.
As soon as the Join hit a router that was carrying the stream, that
router would send a CONNECT back to the receiver and negotiation would
continue ``normally,'' with the exception that the router would be the
origin for that receiver instead of the original data sender. A second
proposal was that a backward path would be created from the would-be
receiver toward the origin. This caused a lot of concern about
requiring duplicate state machines in systems to handle a
reverse-connection and also because this flows backward from the way
routes are traditionally built. There was no consensus on this idea.
The group asked IBM to write this up more fully and present it to the
mailing list for discussion. After the list determines that this is (or
is not) something that should be pursued, volunteers will (or will not)
be solicited.
Future Plans
The discussion moved on to who would edit and write the Internet-Drafts
and the RFC. Luca and Steve DeJarnett agreed to work on this, and Lou
Berger said he would be willing to help out. The editors plan to base
the new drafts and RFC on RFC 1190, but expect that a substantial
rewrite and reorganization will be required. The editors intend to make
PostScript and ASCII text versions available for both the drafts and
(hopefully) the RFC.
Mark Pullen suggested that an interim meeting should take place in late
January or early February to work on the Internet-Draft. Mark offered
to host the meeting. Most people seemed to think this was a good idea
and it will be suggested to the mailing list.
Subjects that are likely to be discussed in the near future include:
o HIDs with the possibility of removing the negotiation and just
using globally-unique identifiers at each hop instead.
o Groups of Streams, and how you might use them to aggregate streams
for bandwidth sharing and multicast address allocation.
o State Transition diagrams. Define them for the current protocol
and then update them based on changes made by the working group.
o Join/Leave streams. Further specify how this might work for
receiver-initiated communication.
[These minutes, while the product of discussions of the entire group,
are quite possibly biased by the thoughts and interests of the author.
I've attempted to eliminate some of that bias by asking others to review
these notes but in the end they represent what I understood to have
happened at the meetings.]
Attendees
Susie Armstrong susie@mentat.com
William Barns barns@gateway.mitre.org
Lou Berger lberger@bbn.com
Stephen Casner casner@isi.edu
Richard Colella colella@nist.gov
Steve DeJarnett steve@ibmpa.awdpa.ibm.com
Luca Delgrossi luca@ibmpa.awdpa.ibm.com
Ed Ellesson ellesson@vnet.ibm.com
Eugene Geer ewg@cc.bellcore.com
Fengmin Gong gong@concert.net
John Hanratty jhanratty@agile.com
W.S. Harborth wharbort@ghost.darpa.mil
Ken Hayward Ken.Hayward@bnr.ca
Kathy Huber khuber@wellfleet.com
David Jacobson dnjake@vnet.ibm.com
Matthew Jonson jonson@ddn.af.mil
Lee Kilpatrick leekil@bbn.com
Byonghak Kim bhkim@cosmos.kaist.ac.kr
Charles Kunzinger kunzinger@vnet.ibm.com
Ted Kuo tik@vnet.ibm.com
Thomas Maslen maslen@eng.sun.com
Karen O'Donoghue kodonog@relay.nswc.navy.mil
Zbigniew Opalka zopalka@agile.com
Laura Pate pate@gateway.mitre.org
Michael Patton map@bbn.com
J. Mark Pullen mpullen@cs.gmu.edu
Bala Rajagopalan braja@qsun.att.com
Doris Roland droland@ghost.darpa.mil
Hal Sandick sandick@vnet.ibm.com
Henning Schulzrinne hgs@research.att.com
Dallas Scott scott@fluky.mitre.org
Michael See mikesee@vnet.ibm.com
Vincent Shekher vin@sps.mot.com
Ming Sheu msheu@vnet.ibm.com
Michael Speer michael.speer@sun.com
Michael St. Johns stjohns@arpa.mil
George Swallow gswallow@bbn.com
John Tavs tavs@vnet.ibm.com
Matsuaki Terada tera@sdl.hitachi.co.jp
Akihiro Tominaga tomy@sfc.wide.ad.jp
Claudio Topolcic topolcic@cnri.reston.va.us
Keisuke Uehara kei@cs.uec.ac.jp
Jean Yao yao@cup.hp.com
Shinichi Yoshida yoshida@sumitomo.com