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

[Rod.Walsh at nokia.com]

The thread reminded me of the RMT minutes which said something about
applications for object aggregation - I think "web sites" was questioned
in the meeting?

As for using object aggregation for websites - it's a good idea
(providing you have a way to pay for the process of doing it :)

Obviously for static content there are no big update issues. For more
dynamic content (regularly changing web sites), then it is likely that
some "complete site" update is less frequent than a "delta" to update
the changed parts. There is no requirement to use a physically
aggregated object for the delta. In such a case it would make sense to
logically group the large aggregated object and the small update file
(or files) - as the semantics of "all belong together" are preserved.

Also, we have the logical aggregation semantics. This groups files to
the same logical object without physically transporting them as one. For
large files (multiples of the source block size), the FEC benefits of
physical aggregation drop off so it is simpler to use logical
aggregation: although optimal configurations of FEC schemes differ, HD
movies >1GB are likely to fall into the "easily big enough to skip
physical aggregation" category.

There are other times when logical aggregation is desirable. 3GPP uses
the technique to allow (for multicast service announcements) a metadata
envelope (version etc.) to be grouped with its corresponding metadata
fragment (e.g. a media description) this way so the client would know
that these belong together and the content/MIME type indicates the
behaviour. Multipart MIME is also allowed to combine these two related
objects, but the release 6 specification does not detail exactly how all
metadata gets to the client and so this technique allows, e.g., repair
of the metadata over HTTP without a GET for a correctly received
envelope.

Otherwise, the selection between logical and physical aggregation is
pretty much implementation specific (i.e. application specific) - where
the preference for FEC performance and SW complexity is balanced
according to the use cases and environment.

Hope that helps (or at least helps more than it confuses :)

Cheers, Rod.



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