Subject: Re: Draft meeting minutes

From: Lorenzo Vicisano <[email-masked]>
Date: Fri, 10 Dec 1999 18:04:40 -0800

Mike,

> Please change all references to "open loop" in this document and subsequent
> documents to "ALC", which stands for "Asynchronous Layered Coding".

Too late: I've already sent the minutes. Will do next time.
Please note however the we mentioned ALC in the notes.

	cheers,
	Lorenzo

---

From: Mike Luby <[email-masked]>
Date: Fri, 10 Dec 1999 17:54:34 -0800

Lorenzo and All,
Thanks, Mike 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Lorenzo
Vicisano
Sent: Thursday, December 09, 1999 3:06 PM
To: [email-masked]
Subject: Draft meeting minutes

Hi,

Please find enclosed the draft version of the Washington IETF meeting
minutes. If you have comments please let us know by tomorrow Dec 10th
3pm PST. Apologize for the short notice.

Cheers,  
The WG Chairs

Content-Type: multipart/mixed ;
	boundary="==_Exmh_-5897494130"

This is a multipart MIME message.

--==_Exmh_-5897494130

--==_Exmh_-5897494130
Content-Type: text/plain ; name="rmt2-minutes"; charset=us-ascii
Content-Description: rmt2-minutes
Content-Disposition: attachment; filename="rmt2-minutes"

Thursday, November 11 at 1300-1500
===================================

CHAIRS: Allison Mankin <[email-masked]>
        Roger Kermode <[email-masked]>
        Lorenzo Vicisano <[email-masked]>

Notes taken by Sally Floyd and Alliso Mankin.
Minutes reported by the WG chairs.

Meeting Agenda
==============

Agenda Bashing:                  Roger Kermode
BB & DS Drafts Update:           Roger Kermode
Guidelines Draft (NEW):          Allison Mankin
Congestion Control Update:       Mark Handley
Generic Router Assist:           Tony Speakman
Protocol 1 - NACK:               Joe Macker
Protocol 2 - TRACK:              Brian Whetten
Protocol 3 - Open Loop:          Mike Luby
Security Requirements:           Thomas Hardjono
Recharter/Discussion/Next Steps: Roger Kermode

General Remarks
================

- Volunteers to work on any/all drafts are sought. The WG chairs
are compiling a list of people interested that will be circulated
in the WG mailing list.

- As a result of the WG meeting discussion, a revision to the list
of building block is needed (probably need extension). This issue
will be discussed in a meeting to be held in between this and next
IETF.

Meeting Minutes
===============

The content of the viewgraphs presented is not fully reported in this
notes. Please refer to the presentation material for this.

+ Guidelines Draft
------------------

This draft is being put together by the Working Group co-chairs.

Besides the issues established initially, this draft should also
discuss requirement/applicability statement for Protocol Instantiation.
Protocol instantiation drafts should explicitly state how the
protocol being specified meets the guidelines requirements.

+ Congestion Control Update
---------------------------

No viewgraphs available.

The IRTF RMRG has a good handle on equation-based congestion control
for unicast. The multicast variant has not been developed as far as
expected.  A guess on time-scales are that a draft on sender-based
multicast
congestion control will be moved from RMRG to RMT in about six months.
The above applies to sender-based congestion control with single
data rate.

Sender-based and receiver-based congestion control will be covered in
separate drafts.

+ Generic Router Assist
------------------------

This constitutes one of the building blocks. The architectural design
draft is available: draft-ieft-rmt-gra-arch-00.txt .

The router task is to assist in functions that can also be accomplished
without their presence (albeit less efficiently).  It is lightweighted
and
it is not active networking.

Open issues are: mechanism for splicing GRA signals into transport
protocols (cannot go in network layer but should be
transport-independent).

The authors of the draft solicit input from protocol designers to
select the "support functions" implemented in routers. Operators
that manipulate packets will be limited in number (~ 10) and not
combinable.

+ Building Blocks for NACK-Only RM (NORM)
-----------------------------------------

This presentation is intended to stimulate a discussion on building
blocks for NACK-bases protocols by presenting a prototyped instantiation
of NACK-based protocol (MDP).

Assumption:
   - do not assume GRA, but be able to use it, if it is present.
   - support loosely controlled groups
   - Request for retransmission (NACK) should be based on the
type/content
       of the transfer. (e.g. discrete objects vs. continuous stream). 
   - NACK suppression and other needed functionalities should not make
       assumptions on the underling multicast network service. These
       should be able to work in presence of asymmetry introduced by
       the current variety of routing protocol (source-based tree, shred
tree,
       bidirectional tree, single source model). They should also work
       without multicast back-channel.

>From the discussion after the presentation it appears that there
are more 'small' building blocks that can be extracted from the
NACK protocol instantiation than the ones initially foreseen (e.g.
source/session identification).

+ TRACK protocol instantiation
------------------------------

Brian Whetten solicited people interested in working on TRACK to
help. The most important open issues seem to be: tree building and
scalability of server-based support (e.g. in the middle of the
network). Other issues belong to building blocks (e.g. congestion
control and security).

The presentation was based on the assumption that most of the
protocol functionalities were provided by the protocol instantiation
an not by building blocks. These included ACK and NACK machinery,
tree building/maintenance and session management. In the following
discussion it was raised the issue on why these cannot be provided
by building blocks (the same used for the NACK protocol). It seem
that efforts should be made to use building blocks as far as possible.

+ Open Loop Protocol
--------------------

The presentation was opened with the issue of agreeing on a new name
for this class of protocol. Mike Luby proposed ALC (Asynchronous
Layered Coding).

Two main open issues were raised for this class of protocol:
specification
of the session parameters (mainly FEC encoding) and congestion control.
As for the former, a possible approach is using out-of-band information
that apply to the session (need in-band session identification, common
with the other classes). The congestion control issue will be approached
along the line of RLC (layered CC by Vicisano, Rizzo, Crowcroft) after
addressing the issues that are left open in this proposal.

+ Security Requirement
----------------------

This point needs to be addressed in a more coordinated way at the
next meeting (or at the pre-IETF meeting). In particular it should
be made a clear distinction between the two issues:

   a) Security requirement for RM protocols
   b) Security building blocks 

Where the first is a pre-requisite for RM protocols, aimed at
protecting the network from malicious attack through security holes
opened by the presence of RM protocols. The second is a optional
component of RM protocols that provide additional service to the
application (Data protection, authentication ...).

>From the meeting discussion it seems that addressing a) with the
available security techniques can pose unacceptable scalability
limitation on RM protocols. Alternatively this issues could be
addressed in the context of congestion control (e.g. by making sure
that all the multicast traffic is accounted in the share assigned
to the session by its congestion control component).

+ Next Meeting
--------------
It is likely that an interim meeting will be held in mid-Februrary
on the west-coast of the USA. One possible date would be February 10th
immediately after the IP Multicast Summit.

--==_Exmh_-5897494130--

---

From: "Michael D. Myjak" <[email-masked]>
Date: Fri, 10 Dec 1999 23:16:05 -0500

> Please note however the we mentioned ALC in the notes.

Lorenzo,

Its not uncommon to circulate the minutes, make a correction or two, and
recirculate a final draft.

--
All the best -
    _
___|0|_|___  Michael D. Myjak, Vice President R&D and CTO
 | N & W |   The Virtual Workshop, Inc.
= oo---oo =  P.O. Box 98 Titusville Fl 32781
email: <[email-masked]>  voice&fax: 407.264.0440

---

From: Lorenzo Vicisano <[email-masked]>
Date: Sat, 11 Dec 1999 18:21:39 -0800

> recirculate a final draft.

Michael,

Mike's request arrived after the deadline we had set, that was
dictated by the IETF deadline. We do apologize, however,
for having sent out the minutes only one day in advance.

	cheers,
	Lorenzo