RE: EXP2ST: FLUTE TOI allocation initial value

I can see why potentially a 3GPP or DVB server may want to use consecutive
TOIs, but I'm not at all sure why you would want to mandate this in the
IETF, as the range of FLUTE uses may be much broader, nor can I see how this
simplifies receiver behavior even for 3GPP or DVB.

Currently there is no concept of "TOI ordering" in FLUTE (not even a
discussion of ordering or what it might mean), and the only way to associate
a TOI with a file is through an explicit FDT mapping.  Before mandating
consecutive TOIs, the concept of what it means to be consecutive would have
to be introduced into FLUTE, and why this is important.  Thus, mandating
that there is somehow an ordering among TOIs seems to add complexity to me,
not reduce it, and thus there should be a good reason for adding this
complexity, and I'm not convince that the versioning idea is very strong
(and if this is the reason for mandating consecutive, this needs to be fully
specified in the FLUTE document as well as the ordering concept).  I think
overall this adds a lot of unnecessary complexity to FLUTE, and is the
opposite of simplification.  Furthermore, if particular applications want to
use ordering for example to indicate "earlier" or "later" version, there is
nothing in the FLUTE spec that disallows the application to do mandate
consecutive TOIs within their domain (for example, 3GPP or DVB), as this is
not inconsistent with FLUTE.

And yes, I can think of many reasons for non-sequential TOI ordering.  The
server may for example hae its own internal numbering of files, and it may
use this numbering to derive a TOI when it is sending a file.  As another
example, there may be categories of files, i.e., files relating to "baseball
clips" and other files relating to "basketball clips", and for the service
the sender may want to allocate a range of TOIs for each category and
perhaps use sequential TOIs within each category, but the categories are all
sent to the same session and thus the TOIs will be far from consecutive.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> [email protected]
> Sent: Sunday, July 31, 2005 10:04 AM
> To: [email protected]
> Subject: [Rmt] EXP2ST: FLUTE TOI allocation initial value
>
>
> With in 3GPP work (and fed into DVB) we were hard put to come up
> with a reason to start allocating TOI values to files from
> anything but "1" (obviously not "0" with that being reserved for
> FDT Instances). Similarly, we could not invent any good reason to
> have any progressive allocation other than using incremental values.
>
> Hence restricting FLUTE to work in this way (as has been done for
> 3GPP) would be a simplification with the added bonus of providing
> an indirect versioning (using TOI value) for any particular
> fileuri value (i.e. any particular file).
>
> Note, this applies to allocations of values (i.e. server-end),
> although it would not require a server the send in TOI order
> (hence there's no difference in what a client would expect
> regarding reception of TOI order).
>
> If anyone has a reason why either of these things are unwise
> please speak up to prevent me recommending them for the FLUTEbis:
> - start TOI value allocations for FLUTE at "1"
> - for each subsequent TOI allocation use the previous value plus
> 1 (i.e. increment by 1)
>
> Mike raised a similar issue in his email "[Rmt] RE: Comments to
> draft-ietf-rmt-fec-bb-revised-00.txt" last Wednesday which hinted
> at a use case for allocating any initial value (and then
> incrementing by one) - any details on the use case?
>
> Cheers, Rod.
>
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmt
>