RE: [Rmt] Should FLUTE File Aggregation I-D be a working group item?

["Michael Luby" <luby at digitalfountain.com>]

Hi Rod,
A couple of quick comments below. I've deleted most of your response and
just kept that parts needed to understand my response.
Regards, Mike

> -----Original Message-----
> From: rmt-bounces at ietf.org [mailto:rmt-bounces at ietf.org]On Behalf Of
> Rod.Walsh at nokia.com
> Sent: Friday, November 25, 2005 2:18 AM
> To: mark at digitalfountain.com
> Cc: magnus.westerlund at ericsson.com; vincent.roca at inrialpes.fr;
> rmt at ietf.org
> Subject: RE: [Rmt] Should FLUTE File Aggregation I-D be a working group
> item?
>
>
> Hi Mark et al.
>
...
> >- the draft includes some text attaching semantics to TOI
> >ordering - something we removed from FLUTE in favour of FDT
> >Instance IDs. We should stick with the FLUTE principle that
> >later version of a file is signalled by using a different TOI
> >in an FDT with a larger FDT Instance ID - it doesn't matter
> >whether the TOI value is greater or less than the previous one.
>
> Note, for FLUTE there is no such semantic. The client has no gauntees
> about FDT Instance numbers, no garuntees about TOI numbers.

I think Mark's main point was not about the ordering with respect to FDTs
(whether it is there or not is kind of irrelevant) but instead that that
TOIs can be used by a receiver to uniquely identify which version of a file
it has, which can be useful for incremental file updates using an AO, and
that TOIs do not have any restrictions (like ordering) on their values,
which is all good.

>
> >- the draft mentions that one might only consider file
> >aggregation when the aggregate is less than a single source
> >block - I think it is simpler and has no disadvantages if you
> >decouple the source blocking (which is a feature of the FEC
> >scheme chosen) from the file aggregation. If files belong
> >together in an aggregate then they should be put together and
> >then if the FEC code needs to split that data into blocks this
> >is ok and does not result in any worse performance so long as
> >it correctly interleaves the packets from the different blocks.
>
> Exactly.
>
> The I-D does not mean to bind AO and FEC blocking. The discussion is for
> implementation guidence: for files much greater than the block size
> there's no FEC benefit in physical aggregation; for the composite files
> being less than the block size it always makes sense to aggregate for
> robustness; inbetween it's a compromise; the I-D absolutely does not
> impose any FEC instance retraints and so it's implementation specific to
> optomise complexity and performance in this aspect. The guidence is
> valuable. If we inadvertantly made normative specification on this, it
> was an error to be corrected.

There is a lot of FEC benefit to having the FEC apply over the entire AO
when the AO is much larger than a single source block, and so the guidance I
believe is misguided and steers implementors in the wrong direction.  We can
talk more about this as the work progresses, but this is one of several
parts of the file aggregation draft that I think needs significant
rethinking and revision.

>
> Also, the logical grouping between objects can be used to get the
> "belongs together" semantics for multiple AOs - e.g. where partial
> recovery is undesirable, or different levels of robustness are
> desirable).
>
> Cheers, Rod.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Rmt mailing list
> Rmt at ietf.org
> https://www1.ietf.org/mailman/listinfo/rmt
>


_______________________________________________
Rmt mailing list
Rmt at ietf.org
https://www1.ietf.org/mailman/listinfo/rmt