Minutes of the ISSLL Working Group
39th IETF, Munich Germany

[Note: in general the URLs given in these minutes for slides reference
versions in Adobe Acrobat (PDF) format.  For most of these, the material is
also available in Postscript and/or Microsoft Powerpoint format (with .ps
or .ppt substituted for the .pdf in the URL.]

Minutes were recorded by Jim Binder, Eric Crawley, and John Wroclawski

First Session:  Monday August 11, 1997 0930-1130

Eric Crawley started the meeting with a quick review of the agenda.
Some agenda items, notably the discussion of the ATM Service Mapping
draft were being moved to the second session due to participant
schedules.

John Wroclawski gave the status of the ISATM documents.  The
framework, implementation requirements, and implementation guidelines
documents will be reviewed in detail later in the meeting. These
documents and the service mapping document are all expected to be
ready for WG last call shortly. They are:

- draft-ietf-issll-atm-framework-00.txt
- draft-ietf-issll-atm-imp-req-00.txt
- draft-ietf-issll-atm-imp-guide-01.txt
- draft-ietf-issll-atm-mapping-03.txt

John also talked about new work areas for ISATM. Two of these will be
discussed in more detail later; these include the use of multicast servers
(MARS/MCS) and support for the use of shortcuts with NHRP. A third item
that has been asked about is work to reconcile ISATM with updates and
changes in the ITU-T standardization of ATM.

Dave Oran gave a quick status of the ISSLOW documents. See
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/isslow_stuff.pdf>
for more details of Dave's presentation.  Some slides were also used
from Carsen's previous ISSLL presentations available in
<ftp://mercury.lcs.mit.eu/pub/issll/IETF/memphis_9703/isslow4.pdf>

Three ISSLOW documents are ready or nearly ready for WG last call.  They
are:

- The framework document, draft-ietf-issll-isslow-02.txt
- The MultiClass MultiLink draft, draft-ietf-issll-isslow-mcml-02.txt
- The RealTime Framing draft, draft-ietf-issll-isslow-rtf-01.txt

Of these, the first two are thought to be done, and will be WG last-called
shortly after the IETF. The realtime framing draft is being presented to
the PPPExt group for their input and consensus.

The service mapping draft,
- draft-ietf-issll-isslow-svcmap-00.txt
is further away from last call and in need of comments from the WG.

Andrew Smith gave an update on the IS802 work.  The framework document,
having passed WG last call, was rejected by the IESG for a number of minor
reasons.  However, there has been discussion of moving some information in
the service mapping draft into the framework draft.  This will be discussed
with the draft authors and the chairs.  The service mapping and Subnet
Bandwidth Manager (SBM) drafts were to be discussed later in the meeting.

Andrew also discussed the status of the IEEE 802.1p work, which is nearing
completion.  Products are expected shortly that implement the developing
standard.

The meeting then moved to presentations and discussion of specific works
in progress.

IS802:

Raj Yavatkar talked about the new SBM draft
(draft-ietf-issll-is802-sbm-04.txt). Slides are in
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/sbm04.pdf>.
Major changes include:
- Message processing rules and election processing moved into one
  place
- Clarification on the use of reserved multicast address
- Addition of a Traffic Class object as per the IEEE 802.1p draft (and
  service mapping draft)
- Added MAC level information to SBM-specific objects
- Added an implementation guidelines section
Raj went over the multicast address issues as well as the new traffic
class object.  The merging of TCLASS objects uses the *lowest*
priority value of the ones received.  This is different from RSVP
merging but Raj explained that this works better in IEEE 802.1p
networks.

There was a question about where to set the user_priority and why put it in
the PATH message.  The user_priority is set by SBMs but putting it in the
PATH message allows SBMs to give "hints" on the user_priority to downstream
SBMs.  The designers offered to think about the need for putting the
user_priority in the PATH message a bit more.

In response to a question, it was noted that all L2 addresses are encoded
using the IEEE 802 canonical encoding.

Open issues:
- Non-SBM nodes: reserve resources in different partitions or requests
  are resovled dynamically through a common BW   allocator.
- SBM transparent nodes: all messages work but the efficiency is lower
  because there is no separation of the physical segments
- Some non-DSBM clients:  Either require everyone to use SBM or a
  common allocator.

There was a question on a DSBM with different sized segments.  The
DSBM must know the segment sizes it is working with.

Further open issues:
- Only using raw IP mode for RSVP, no UDP encapsulation.  Is this a
  problem?
- I_AM_DSBM messages contain both L2 and L3 addresses.
- Raj made a request for any further open issues that folks had. None
  were raised.

Next, Andrew presented the IS802 Service Mapping draft
(draft-ietf-issll-is802-svc-map-00.txt).  See
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/is802-svc-mapping.pdf>
for the slides.  Andrew went over the goals and assumptions for the IS802
service mappings and the changes to the document.  There was a good deal of
background material presented on the IEEE 802 networks and their
characteristics as well as architectural information on implementing
IntServ in 802 environments.

There was a question about the applicability of the service mapping
draft to other 802 networks, such as 802.14 and MCNS for cable modems.
This is likely to be an entirely different area within ISSLL.

ISSLOW:

Carsten Bormann went into more detail on the RTF draft
(draft-ietf-issll-isslow-rtf-00.txt).  He marked up some of his previous
slides from Memphis (see:
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/memphis_9703/isslow4.pdf>.  He
briefly reiterated the requirements and the two complementary approaches
(fragmentation and suspension) being developed.  Fragmentation is easiest
to implement while suspension yields the lowest latency.  The challenge is
to define a scheme that allows both to interoperate.  Even with header
compression, the headers are still big.  The RTF frames increase the
sequence number size through a borrowing of bits.  They also steal bits for
added classes.  There is a 25% expansion, max, from stuffing for the FSE
byte.

The author of the ISSLOW service mapping draft
(draft-ietf-issll-isslow-svcmap-00.txt), Steve Jackowski, was not able
to be at the meeting so no update was presented.  However, Carsten and
Dave Oran brought up a few issues with the document that will be
discussed with the author.

ISATM:

Eric Crawley presented the status of the ISATM framework doc
(draft-ietf-issll-atm-framework-00.txt).  Slides are available in
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/isatm_framework.pdf>
Eric explained purpose of the document and the sorting of the issues into
"solved" and "unsolved" problems.  Indicate clearly what things are not
addressed int his round of work.  The current document is the merger of two
previous documents, draft-crawley-rsvp-over-atm-00.txt from February 1996
and draft-ietf-issll-atm-support-02.txt from March 1997.

Eric noted that more editing was needed to update some obsolete text and
remove some redundant bits.  There are also a few comments that have been
received and need to be incorporated.  A new version is expected soon and
should be ready for WG last call.

Second Session:  Wednesday, August 13th, 1997 0900-1130

Lou Berger presented his drafts on ATM Implementation Guidelines &
Requirements (draft-ietf-issll-atm-imp-guide-00.txt and
draft-ietf-issll-atm-imp-req-00.txt).  His slides can be found in
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/isatm_guide_req.pdf>

Lou indicated that his drafts were drawn from
draft-ietf-issll-atm-support-02.txt and that there was one major open
issue: Can RSVP control messages be sent on the data VCs?  The current text
allows for control messages to be sent on both data VCs and their own VCs.

After some discussion a concensus emerged that that RSVP control messages
MUST NOT be sent over a QoS data VC, so that implementations could "switch"
the QoS VC without having to look for control messages in the data flow.
RSVP control messages can be sent over a best effort VC or their own
control VC. The documents will be changed to reflect this view.

A discussion of error detection and recovery ensued.  The room agreed that
it is important that the RSVP data and control VCs have some form of "fate
sharing" for detecting errors, to avoid useless dangling VC's. There was
no agreement on the need for a single pecific mechanism to support this,
it was seen as a need that could be met in a number of ways.

Roch Guerin presented on the ATM Service Mapping draft
(draft-ietf-issll-atm-mapping-02.txt) for Mark Garrett, who was unable to
attend the meeting.  Roch's slides can be found in
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/isatm_mapping.pdf>.
Mark had made some last updates before WG last call.  Sections 2.5 & 2.6
have been revised and there are new sections on path characterization and
handling non-conformant traffic.  WG participants are requested to check
the expanded mapping tables and the unit conversions.

Additionally, for the handling of excess traffic, there is now consistency
between sections 2.2 and 3.2.  We want to ensure "preferred behavior
(no-reordering) vs.  tolerable behavior (reordering).

Mark requests comments promptly, and plans to have a revised version of
the document available in September.

This concluded the discussion of current drafts.  The remaining
presentations were on upcoming work items for the WG.

Roch Guerin initiated a discussion on support for shortcuts for RSVP flows
over ATM.  The slides for this presentation can be found in
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/shortcut.tar>.
I-D draft-guerin-issll-rsvp-shortcut-00.txt further discusses the proposal.

  Note: The tar file in the URL above expands to a set of html and GIF
  files which form a web-based presentation. There is no other version of
  this material presently available.

The purpose of the draft was to identify issues for shortcuts for ATM
flows, define requirements and guidelines for interoperability (internally
and externally).  Design issues: maintain consistent shortcuts for RSVP
data and control messages.  There is a need to consider several scenarios.
There are several error conditions that must be considered; best effort
shortcut failure, shortcut QoS VC fails, shortcut QoS setup failure during
renegotiation.  There was a consensus to continue this work.

Steve Berson then gave a short presentation on the issues for QoS ATM
MultiCast Servers (MCS) with MARS. His slides can be found in
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/mcs.pdf>.

The Problem: MARS does not indicate whether a Multicast Server or mesh
approach is in use, but MCS des not provide QoS support.

Three possible solutions:
	- Declare that Thou shalt do VC mesh in ISATM networks.
	- Change MARS to indicate whether mesh or MCS is being used.
	- Put QoS into the MCS.
There was some consensus that the group should do more work on this issue.

Richard Woundy gave an overview of the issues for IntServ over Cable Modems
(ISCABLE) [Sorry; formatting problem.  Slides available soon; availability
announcement will be sent to the issll mailing list]

Rich gave a quick overview of cable modems and MCNS.
There are some upstream traffic variations:
	- Requests can be piggybacked to data
	- CMTS generates allocation MAPs with "unicast" request
	  intervals (useful for Controlled Load?)
	- CMTS generates allocation MAPs with "unsolicited" data
	  grants but there are min/max packet size issues, and bursts
There will need to be split efforts for MCNS/POCIS and IEEE 802.14
	- different MAC protocols; cells vs. frames
	- share information for frame-based services
	- define dynamic SID messages formate, RSVP interaction
	- Enable controlled load and guaranteed services
There are interesting issues for policing. Rich asked for volunteers
to work on this effort.

The general meeting broke up at this point.  The ISSLOW subgroup, under the
direction of Dave Oran, used the remaining time to discuss some issues
particular to their work.

Dave Oran gave a PPPExt status update:

  Steve Casner presented the compression draft (again).  A new draft is in
  process to address issues.  There will be a reduction in the number of
  options.  Dave made a request for comments on the ISSLOW drafts from the
  PPPext participants.

Fred Burg gave a presentation on the overhead for processing of MCML & RTF
formats.  Fred's presentation can be found in:
<ftp://mercury.lcs.mit.edu/pub/issll/IETF/munich_9708/pre-emption-concl.pdf>.

Fred looked at RTF and MCML for type 1 and type 2 in terms of available
bandwidth after voice processing (28K modem speed, no prefix ellision, 1
vox stream, 1 data stream, 1 link in bundle, packetization rule per 4/97
draft revision of RFC1890.)  They looked at the BW left for data in 1
second after voice has gotten its share with no delay.  Partial results
indicate that RTF is better at keeping delay low than MCML/S2 by 7-25%.
Compressed RTP is necessary.

Next there was a discussion of the service mappings document.  Dave Oran
commented that the author, Steve Jackowski has received some comments and
is planning to put them in a revised draft.  There was some discussion of
the effect of varying rates in V.34.  There was more discussion on how to
incorporate the influence of header compression gain.  The problem is that
the compressor is not part of the application so it has to give "advice" to
the flowspecs (actually, TSpec) to indicate the compressability of the
header data.

Next Steps for ISSLOW were discussed.  Dave would like to wrap up by the
next meeting.  The Framework document will go to WG last call.  The MCML
document will wait for comments from PPPext and go to last call in
September.  The RTF document will do the same with longer a timeout; last
call in October.  The Service Mapping document will get a new draft by
September and address open issues.  It should be discussed in December with
a last call afterwards.