Subject: Separating the MRCC from the ALC/FEC

From: Meir Feder <[email-masked]>
Date: Sun, 12 Nov 2000 17:59:05 +0200

Dear RMT-er's,

In response to the standardization effort of the RMT working group in the
drafts ALC-01 and MRCC-00, we feel that the ALC draft combines together the
FEC and the congestion control somewhat unnecessarily. Thus, we like to
suggest that the draft will maintain a clear separation of the functionality
between the MRCC and the ALC/FEC part.

We believe that the MRCC will prove itself as a working protocol for
multicast congestion control, that is important for interoperability and for
friendly network behavior. The FEC is the data (maybe the most natural data)
that is transferred via the MRCC transport. Thus, MRCC should essentially be
(and is) for the Transport layer (layer 4), while ALC/FEC should be for the
Application layer (layer 7).

The separation will give the following benefits:

1. MRCC will be able to deliver not only FEC packets but also, e.g., RTP
packets (for continuous real-time viewing). When the payload is ALC/FEC
packets, registering to more MRCC layers will provide a faster download.
When using RTP packets, it can provide higher quality streams, by using
successive refinement payload.

2. Since MRCC and ALC/FEC (implementing different communication layers) will
each have its own header, version number, header size field, extension
fields, and so on, modifications in one should not affect the other.

3. The long-term goal should be the implementation of MRCC at the kernel
level, like TCP today, in order to give true inter-operability, congestion
control, fairness, safety, robustness and so on. Applications will create
MRCC socket, possibly giving only (S,G), and start receiving packets at
varying rates. If MRCC is not implemented at the kernel, there is a danger
that we will see more aggressive MRCC implementations over time.

4. ALC/FEC packets should carry only application-related information, not
transport. Note that, then, the source of ALC/FEC packets can be payload of
MRCC protocol, disk files, caches, broadcast channels (when there is no need
for MRCC...) or any other source.

The separation is clear and simple. The header part of the ALC associated
with congestion control will be in the MRCC, while the ALC/FEC header will
have the code information. In general, in order to know if some information
should be in the header field of MRCC or ALC/FEC, one should ask the
following question: If a packet is cached to the disk, and re-transmitted
later, should it have the original value (ALC/FEC) or a new value (MRCC).
Thus, for example, the time extension mechanism should migrate to MRCC.

Meir Feder and Doron Rajwan
Bandwiz

---

From: Luigi Rizzo <[email-masked]>
Date: Sun, 12 Nov 2000 20:00:18 +0100 (CET)

Hi,

...
> FEC and the congestion control somewhat unnecessarily. Thus, we like to

point well taken and in fact we are working on a revised version of
ALC draft mostly along the lines you suggest.

<PERSONAL OPINIONS FOLLOW>

In ALC-01 the MRCC info is already well separated from the ALC
header (the header field is opaque); it is true that ALC-01
still has some FEC-related header fields which do not belong there,
and we are revising the draft and move this info to the payload.

> fields, and so on, modifications in one should not affect the other.

I am not too happy in using two different headers for MRCC (or whatever
cong. control protocol is going to be used) and ALC, as you seem to
suggest, as some form of cong.control is an integral part of ALC.

> level, like TCP today, in order to give true inter-operability, congestion
...
> that we will see more aggressive MRCC implementations over time.

having a protocol implemented in kernel or user space is irrelevant for
most aspects, except perhaps overhead at source/receiver (which i
do not think is a concern here) and ease of deployment (and this is
a double-edged sword).

We can have bad (more aggressive, or buggy, or just initial) kernel
implementations of MRCC and be stuck with them for a long time
because people do not upgrade the OS (there are still IGMPv1 hosta
around). Or we can have good user-space implementations of MRCC
and stand the risk of people using "accelerators" which are more
aggressive than they should (same as it happens with TCP and various
companies offering modified stacks).

> Thus, for example, the time extension mechanism should migrate to MRCC.

I partly disagree with the example. CC controls the throughput ("slower",
"faster"), whereas the time extension mechanism operates at a higher
level ("I am not done yet"). It certainly does not belong to MRCC e.g. for
streaming video you do not need it ("sorry, the show is over!").
You might argue that it does not even belong to ALC/FEC, but the
thing is you have to info somewhere.

	cheers
	luigi rizzo
----------------------------------+-----------------------------------------
 Luigi RIZZO, [email-masked]  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone (510) 666 2927             .
----------------------------------+-----------------------------------------