Subject: [Rmt] Question on EXT_CENC in draft-ietf-rmt-flute-revised

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 07 Oct 2006 22:49:14 -0700

Folks,

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?

thanks,
Lakshminath

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

---

From: Vincent Roca <[email-masked]>
Date: Mon, 09 Oct 2006 12:57:31 +0200

Hello Lakshminath,

> 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?
Cheers,

    Vincent

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 18 Oct 2006 01:38:32 -0700

At 03:57 AM 10/9/2006, Vincent Roca wrote:
>>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?
>

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

---

From: <[email-masked]>
Date: Wed, 25 Oct 2006 12:36:54 +0300

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-masked]] 
>Sent: 18 October, 2006 11:39
>To: Vincent Roca
>Cc: Charles Lo; [email-masked]
>Subject: Re: [Rmt] Question on EXT_CENC in draft-ietf-rmt-flute-revised
>
>
>extension 
>>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
>>

---

From: Vincent Roca <[email-masked]>
Date: Wed, 25 Oct 2006 16:15:18 +0200

Hello Rod,

It seems to me that the main benefit of moving CENC to ALC is to
clarify and rationalize things when it's still feasible.

Since object encoding can potentially be required by any application
built on top of ALC (FLUTE being one of them), no matter whether
it is applied to "stream objects" or "bounded/discrete objects", it's
not a bad idea to leave the door open. Of course, with "stream
objects" a gzip encoding is meaningless as you say, but one can
probably find another encoding for these objects (even if I don't
have one in mind). An ALC CENC mechanism can be made
sufficiently flexible so that we do not restrict its use to bounded
objects.

Concerning the applications that could benefit from this ALC
level CENC:
(1) they already exist, our simple and stupid FCAST file
transfer application being one of them. Even if there's currently
no need to standardize it, there are use cases where it's sufficient.
Why should I use a more complex application then? If an
ALC CENC exists, then FCAST would be able to (e.g.) gzip big
files on the fly. And there are perhaps other similar applications,
designed outside of the RMT group, that have the same needs,
who knows?
(2) there are probably ALC use-cases we can't even imagine today
that would need it. Perhaps Lakshminath has one of them in mind...
Even if it's not the case, I'd prefer not to close this door today.

And I don't think it's a tough work to move the text, even if I
might miss something..

Cheers,

    Vincent

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 26 Oct 2006 01:50:41 -0700

Given that ALC can in fact be used to send "bounded/discrete" objects 
aka files, it is clear to me that as long as the sender uses ALC to 
send such objects, CENC is as applicable to ALC as it is to FLUTE.

I don't see the related specification as a difficult endeavor at all.

As to requirements and use cases, I can talk about other standards 
bodies' specifications that use ALC for file transfer, but I think we 
don't need to really get to that debate, as we have a clear notion of 
sending files via ALC already and specifying CENC for that makes perfect sense.

Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 26 Oct 2006 01:56:34 -0700

Hi Vincent,

Thanks for sharing your thoughts on this.  Like I noted in my earlier 
emails on this topic, it makes perfect sense to move CENC support to 
ALC.  The drafts are "open" at the moment and it appears like we have 
the window of opportunity to make the change to address some of the 
use cases you list, and also to make the generic applicability of 
CENC to ALC objects feasible.

As you say, I don't see how the spec work related to this can be 
complex.  We may have to put some notes saying not all encodings are 
applicable to all types of objects, but that I am sure is not a big 
issue really!

regards,
Lakshminath