Subject: [Rmt] ALC header modifications

From: "Rami Lehtonen" <[email-masked]>
Date: Wed, 5 Feb 2003 14:00:06 +0200

Hi,

If you are planning to revise the ALC header format to make it possible
to get rid off congestion control identification in some cases (make it
optional), it could make sense to make the forward error correction
optional as well (reliability could be handled by retransmissions, we
might need the sequence number field). Those fields could be moved to
header options to be specified with TLV encoding. So when you don't want
to use those, you don't have to waste any bytes because of those fields.

In addition you could specify a field in ALC header that can be used as
a message type field when specifying an actual protocol based on ALC
without having out-of-band information on different message meanings.

Any comments,

Rami Lehtonen

>I think the plan is to move ALC from Experimental RFC status to 
>Proposed Standard RFC status aggressively, i.e., within the next couple

>of months, so perhaps it would be best to make this change when it 
>moves to Proposed Standard (since it is essentially through the 
>Experimental RFC status stage).
>
>Mike Luby
_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Lorenzo Vicisano <[email-masked]>
Date: Wed, 5 Feb 2003 09:20:22 -0800

Hi Rami,

As Mike mentioned this is not the right time to revise any
of the RMT RFCs, unless we discover some major flaw.

> to get rid off congestion control identification in some cases (make it

this is only possible if ALC is used in confined environments, not
internet-wide. Specifying for this kind of enveronment is not IETF's
main concern and anyone is free to change the specs to his/her needs,
if these are not going to be used internet-wide. said that, we could
discuss adding some kind of statement to the spec.

> might need the sequence number field). Those fields could be moved to

ALC is not a general-pourpose reliable multicast protocol.
Retransmissions are against the ALC design principle. Please
use another protocol (e.g. NORM) if you want retransmission.

> without having out-of-band information on different message meanings.

not sure I understand this.

	thanks,
	Lorenzo

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 5 Feb 2003 21:21:44 -0800

Comments interspersed below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Lorenzo
> Vicisano
> Sent: Wednesday, February 05, 2003 9:20 AM
> To: Rami Lehtonen
> Cc: [email-masked]
> Subject: Re: [Rmt] ALC header modifications
>
>
> Hi Rami,
>

This is something that several people have asked about, are concerned about,
would like to happen, and there is even some proposed language that we can
add/change the text to when the time comes.  I'd rather wait till we are
ready to move this from Experimental to Proposed Standard for this though.
I suggest we discuss that at the upcoming IETF meeting just to make sure
that there is consensus on this issue.  I know a lot of
applications/companies where ALC could be used without congestion control in
a controlled environment or where flow/congestion control is provided by
other means, and I would like to encourage the use of ALC in those
environments by making the standard cover those cases (with the proper
language) but clearly if it is being deployed broadly across the open
Internet then flow/congestion control is a must.

> use another protocol (e.g. NORM) if you want retransmission.

I concur with Lorenzo's comment on this.

> not sure I understand this.

My feeling is that this is getting too general and outside the scope of what
ALC is intended for, but honestly it is not explained well enough to
evaluate.

---

From: "Rami Lehtonen" <[email-masked]>
Date: Thu, 6 Feb 2003 08:49:41 +0200

> I concur with Lorenzo's comment on this.

Even if the ALC is designed to work without retransmissions, one could send
packets without FEC continuously on one ALC channel (carousel) or use
several ALC channels. To allow this the use of FEC could be optional even
though the implentation must support it.

> ALC is intended for, but honestly it is not explained well enough to

The idea was that protocol could include a message type field to be used
e.g. by applications relying on ALC for multicast session information
transfer. Like SAP contains a message type specifying whether it contains an
announcement or deletion of a session. But maybe I have assumed ALC as too
general multicast object transfer protocol with its varying header field
sizes.

- Rami

---

From: "Michael Luby" <[email-masked]>
Date: Thu, 6 Feb 2003 15:41:59 -0800

Hi Rami,
More comments interspersed below.
Regards, Mike

> From: Rami Lehtonen [mailto:[email-masked]]
> Sent: Wednesday, February 05, 2003 10:50 PM
> To: Michael Luby; Lorenzo Vicisano
> Cc: [email-masked]
> Subject: RE: [Rmt] ALC header modifications
>
>

Lorenzo and I are going to be submitting a supplement to the FEC BB today
that introduces two new FEC Encoding IDs, one Fully-Specified and one
Under-Specified. The Fully-Specified FEC Encoding ID uses no FEC encoding
(the original data is partitioned into "encoding symbols" and each packet
contains one of these encoding symbols, and the recommended sending approach
is carousel.  This will allow a standard and easy FEC Encoding ID to
implement, and I think it answers your request (others as well have asked
for a "no-coding" FEC scheme).

In terms of specifying feedback from receivers to the sender, I would not
put this into ALC because ALC does not include anything that limits
scalability and this would.  It might be a good idea to consider putting
something like this in a separate draft that could be used in conjunction
with ALC.  I would have to think about it more though before being
convinced.

> general multicast object transfer protocol with its varying header field

I believe there will be a new draft that does something like this coming
soon that uses a different mechanism than what you suggest that I think is a
pretty good idea. If and when it is submitted maybe it is good to look to
this as a starting place to see if achieves what you were hoping to achieve.