Subject: [Rmt] new RMT Charter

From: Lorenzo Vicisano <[email-masked]>
Date: Sun, 16 Mar 2003 16:20:27 -0800

dear RMTers,

please find attached the text of what will likely be our
new charter. It has already been approved by the IESG, but
it is still under IAB review.

We will have a discussion about this in tomorrow's meeting,
but please note two important changes:

 - RMT is hosting a sub-group chartered to standardize a
   small-scale, unicast-based, simple replication service.

 - TRACK has been taken out of the charter.

Also please note the new aggressive milestones, aimed at
closing the WG activity within the next one or two IETF meetings,
after the current one.

	thank you,
	Roger and Lorenzo

Reliable Multicast Transport (rmt) Working Group

Chairs:
Roger Kermode <[email-masked]>
Lorenzo Vicisano <[email-masked]>

Area Director:  Allison Mankin <[email-masked]>

The purpose of this WG is to standardize reliable multicast transport.

Initial efforts have focused solely on the standardization of the
one-to-many transport of large amounts of data. Due to the large
number of applications that fall into this category, and the sometimes
orthogonal requirements these applications exhibit, it is believed
that a "one size fits all" protocol will be unable to meet the
requirements of all applications. In recognition of this observation,
this working group will standardize two protocol instantiations,
initially as Experimental protocols, and then as warranted, in the
standards track, from the following families:

1) A NACK-based protocol.
2) An "Asynchronous Layered Coding protocol that uses Forward Error
   Correction.

In addition, the rmt WG will have a sub-group for a different task.
This sub-group will develop a protocol for a simple unicast
replication service that is specifically designed to address the need
of very-small-scale multicast sessions. The goal of this protocol is
to provide a small-scale replication solution that does not require
per-session state in all parts of the network crossed by the session
traffic, unlike native IP multicast.  The applicability of this
protocol is to situations where end-to-end unicast replication is not
appropriate due to bandwidth limitation in some part of the
network (usually last-mile links).

It should be noted that this simple unicast replication work is in a
sub-group because a strict interpretation of this service would
determine that it falls somewhat outside the transport domain (other
than congestion control) and has more routing issues than most of the
other work in rmt.  Given that the bulk of the experts who would be
qualified to comment on this work item are already active participants
in the rmt WG, the Routing and Transport Area Directors have concluded
to make an exception and develop it in this working group's sub-group
instead of forming a new working group.

The WG will carry out protocol standardization in general by composing a
a set of RFCs that specify
       
- building blocks: A set of easily-separable coarse-grained modular
components that are common to multiple protocols along with abstract
APIs that define a building block's access methods and their
arguments.

- protocol instantiations: Specifications that define the necessary
gluing logic and minimal additional functionality required to realize
a working protocol from one or more building blocks. These
specifications will also include an abstract API that defines the
interface between the protocol implementation and an application.

The WG has previously completed work on three documents to assist in
the standardization process. RFC2887 describes the design-space in  
which the one-to-many transport protocols will be developed. RFC3048
explains the concepts of building-blocks and protocol
instantiations. RFC3269 provides guidelines to authors of drafts that
specify building-blocks and protocol instantiations.

The WG will generate and submit for standardization drafts of the
following building-blocks for use in the construction of the two
protocols: congestion control, negative acknowledgments, forward error
correction, generic mechanisms for router assist, and to address the  
RFC 2357 security requirements.

The WG will also standardize and generate RFCs for the following two
protocol instantiations: A NACK-based protocol, and an Asynchronous 
Layered Coding (ALC) protocol that uses Forward Error Correction.   
RFC 3450 is the Experimental RFC of the ALC protocol instantiation. 

If new requirements are identified that cannot be satisfied with the
building-blocks and protocol instantiations described above, the Area
Directors in consultation with the IESG may add additional
building-blocks and protocol instantiations to the working group
deliverables.

This working group will work closely with the Internet Research Task
Force (IRTF) groups on Reliable Multicast (RMRG) and
Secure Multicast (SMUG), especially for meeting the congestion control
and security requirements mandated by RFC 2357. This working group may
work with the Area Directors to recharter to standardize reliable
multicast for additional scenarios beyond the one-to-many transport of
bulk data once they are sufficiently well understood.

Future MILESTONES:

 MAY 03 Submit congestion control building block (TFMCC, WEBRC, PGMCC) for
        publication as Experimental

 AUG 03 Submit NACK building block and protocol instantiation for publication
        as Experimental

 AUG 03 Submission of simple unicast replication building block
        for publication as Experimental, possibly including a specification
        or considerations on how to achieve congestion control

 DEC 03 Evaluate when and how the RMT Experimental specifications
        will be submitted for publication as Proposed Standard, and
        update this charter accordingly.

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Mark Handley <[email-masked]>
Date: Mon, 17 Mar 2003 14:47:31 -0800

>network (usually last-mile links).

I'm confused.  Is the proposal that the replication happens at the
application layer, or is this a ressurection of xcast through a
transport-area back door?

Cheers,
	Mark

---

From: Lorenzo Vicisano <[email-masked]>
Date: Tue, 18 Mar 2003 13:53:36 -0800

A few updates on the re-chartering:

first of all, I apologize that I gave the wrong impression that
the WG had no saying on the new charter. This was just a
proposed-charter and the WG Is invited to comment on it.

Indeed at yesterday's meeting we had important feedback
that lead to a few changes:

 - The small-scale, unicast-based, simple replication service
   subgroup has been removed from the proposed charter

 - some of the milestones dates have been adjusted to allow
   more time to complete the tasks.

We will soon send the re-vised proposed charter to this mailing list.

	thank you,
	Lorenzo