RE: Question on EXT_CENC in draft-ietf-rmt-flute-revised

Hi All

Interesting question and worth a little thought.

I guess no one has implemented this for generic ALC objects, so it's
rather less mature a feature than a standards track FLUTE would merit
(experimental FLUTE already had 4 genetically different implementations
ran against each other prior to the experimental RFC - maybe more like
DS than EXP, but it certainly improved the spec enormously). Considering
what is ALC and what is FLUTE, it seems that generic ALC CENC wouldn't
be trivial in practice - now the long winded ("first Rod RMT email in
ages") bit...

With only a cursory look, ALC CENC seems harmless, though it lacks a
driving use case. (Pretty much what Vincent emailed).

For files (the interesting transport objects :), FDT description of
field CENC was the right level of flexibility without too much
complexity or else too much overhead. This was discussed in the early
days of FLUTE (initially FDALC) and probably there will be some email
references to this in the 2002/3/4 time frame. The FDT encoding CENC was
added later as a compromise to avoid the less desirable alternative of a
hierarchy of FDT descriptions. Specifically for reliable multicast
_file_ delivery, FLUTE is the right tool and CENC data is available in
FDTs for that. (As a side note, 3GPP-MBMS specifies not to use the CENC
header at all - i.e. no CENC for FDTs).

OTOH, ALC provides general "object" transfer with no particular bounds,
making it as applicable to "stream objects" as it is to
"bounded/discrete objects" (the latter being an interchangeable
pseudonym for "files" with FLUTE). Which means that a file-based
encoding (e.g. gzip) applied generally to ALC without exclusive profiles
would be flawed. Some kind of "pseudo-file" structure would be needed
(e.g. breaking ALC objects into blocks and performing CENC on those,
although not all FEC codes would block and then symbol -> direct to
symbol is perfectly acceptable). So some design issues would need
addressing and maturing from a few different perspectives.

Since FLUTE is the file delivery profiling of ALC, I wouldn't recommend
embarking on an "oboe" or "panpipe" adventure or something of that
nature to have a redundant FLUTE-clone. Given the 4 year brewing time of
FLUTE and the amount of RMT input (which has now subsided), that would
be a bit masochistic (contrary to the spectator perspective, developing
FLUTE has been a royal pain on more than one occasion).

Dondeti, do you have a non-file/non-discrete-object use case for ALC
CENC? There's quite a lot of use case and technical problem solving
mileage needed before I'm convinced a FLUTE->ALC switch is a good idea.
Taking a leaf out of the IPv6 manual, it seems to be neither of
"necessary and sufficient".

(At this rate, I guess my next "new thread mailing" to RMT comes around
February - great Christmases to one and all :)

Cheers, Rod.

(PS Magnus, worry not, I throw some brain time on FLUTE security before
the snow ;)


>-----Original Message-----
>From: ext Lakshminath Dondeti [mailto:[email protected]] 
>Sent: 18 October, 2006 11:39
>To: Vincent Roca
>Cc: Charles Lo; [email protected]
>Subject: Re: [Rmt] Question on EXT_CENC in draft-ietf-rmt-flute-revised
>
>
>At 03:57 AM 10/9/2006, Vincent Roca wrote:
>>Hello Lakshminath,
>>
>>>I have a question on EXT_CENC specified in 
>>>draft-ietf-rmt-flute-revised.  As per the draft, the header 
>extension 
>>>is "ALC PI Specific."  The question I have is whether the extension 
>>>can be used for any ALC object.  If not, how is content 
>encoding of an 
>>>ALC object signaled?
>>
>>In the FLUTE context, EXT_CENC is only meant to specify the 
>(optional) 
>>encoding of an FDT Instance. If an object (that is not an FDT 
>Instance) 
>>carried in a FLUTE session is to be content encoded, then 
>it's signaled 
>>in the "Content-Encoded" attribute of the associated file element in 
>>the FDT Instance. You'll find an example in Appendix B.
>>
>>If ALC is used by an application that is not FLUTE, then it's unclear 
>>to me whether EXT_CENC can be used or not for any ALC object 
>or not... 
>>I don't see any good reason to prevent it, though.
>>Maybe it would be good to move it's definition to the ALC I-D 
>and make 
>>clear in the FLUTE I-D that in this context it is restricted 
>to an FDT 
>>Instance. Opinion?
>
>Thanks Vincent.  I think so too.  Let's move it into the ALC 
>i-d and make the appropriate references and clarifications in 
>the FLUTE i-d.
>
>Perhaps the editors of those i-ds can incorporate this change 
>in the next revisions?  Are the drafts being revised for the 
>coming IETF meeting?  Thanks in advance to the editors for 
>their work on this.
>
>best,
>Lakshminath
>
>>Cheers,
>>
>>    Vincent
>>
>>_______________________________________________
>>Rmt mailing list
>>[email protected]
>>https://www1.ietf.org/mailman/listinfo/rmt
>
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt
>