Re: on the opportunity to design an alternative to FLUTE

Hi Vincent, Brian et al.

I've been quiet for a while so I wanted to ping if there's been any
discussion about FLUTE technology. One example is, whether the IPR
discussion has had any technical basis. Another is, are there any groups of
uses of flute that might benefit from further profiling.

(I only remember two "specialised groups of uses" raised in the IETF so far:
object aggregation to make archive and metadata-snippet transferral more
efficient - now an expired ID; metadata announcement - long term unspecified
from MMUSIC IMG activities).

It sounds like the "inefficient FDT" argument of #1 is just an
implementation choice rather than a FLUTE spec issue. (I've been wrong
before, but seems clear enough to me prior to getting flamed :) The critical
thing is that TOI 0 is not used for anything but FDT instances. That doesn't
prevent file description data being carried on other TOIs, nor does it
prevent it being bundled into aggregate objects on the same TOI as one or
many files. As long as FDT instances don't get the mime type wrong for any
newly invented object types, nothing is likely to break.

A long time ago, in an IETF meeting far, far away; we had some consensus
that "something like FLUTE over NORM" would be a great idea.

Brian, who was it volunteered to look at that for NORM? Any study results
available?

It makes sense to work out if there can be some similarities between the
ALC-full-PI and NORM-full-PI, get some review and consensus, and use the
same bit of spec text for both. I'm guessing that the exchange of file
description data could be a bit more formal with NORM since there's some
form of feedback (but it need not be so if the only feedback is to routers).
The same FEC schemes are probably of interest to NORM, although probably the
CC schemes are other-worldly to each other. There's scope for innovations
for late joiners and mid-session leavers optimized differently for NORM and
FLUTE. On the 3GPP side, the idea of multicast session access from different
physical connections was important (e.g. UMTS vs GERAN), and it would be
relevant to many multicast distributions where the source feeds (routes)
across a heterogeneous system - don't know if that suggests more commonality
or difference between apps for NORM and ALC.

Another obvious and interesting one that cam up ages ago is header
compression. I guess ROHC, as the main candidate for RTP, is the main
candidate for RMT header compression. Does that lack of emails imply a lack
of need? (As for object compression, I guess the FLUET encoding fields make
that possible to describe easily enough already).

Just a few thoughts. I'm not proposing anything solid because I'm not
currently in a position to back that up with the manual labour required for
spec and software. But harmonisation between NORM and ALC/FLUTE remains an
interesting topic if only there were 25 hours in my day.

Cheers, Rod.

PS Since the FLUTE IPR thread seems to come up almost as regularly as RMT
emails and since I'll inevitably be painted with the affiliation brush on
that topic: Maybe some technical basis to the issue is valuable. Anyone with
a summary of technical concepts in intellectual property, officially
declared or undeclared, effecting RMT? Any WG chair or AD guidance?


On 1/11/08 8:21 PM, "ext Brian Adamson" <[email protected]> wrote:

> Vincent,
> 
> I would be interested in contributing to an FCAST update as I can,
> particularly wr2 to point #2 below that it could be applied to NORM
> as well.
> 
> best regards,
> 
> 
> 
> 
> At 4:03 AM +0100 12/6/07, Vincent Roca wrote:
>> Dear Stephan, everybody,
>> 
>> Just to make it clear: the decision belongs to the group, hence this
>> "call for opinion".
>> Your opinion is welcome as well as the opinion of other participants.
>> 
>> A few __technical__ points I see in favor of an alternative along
>> the lines of the original
>> FCAST (the one sketched in March 2000):
>> 
>> 1- There are situations where all receivers are supposed to get all
>> the objects sent during
>>  the session (rather than selecting a subset of the objects received
>> as made possible by
>>  FLUTE). In that case, having meta-data appended to the file and
>> delivered as a single
>>  aggregate object:
>>   1.1- is more efficient from a transmission perspective since it
>> removes the interdependency
>>   between the reception of the object and the reception of the
>> metadata if they are
>>   delivered separately. Typically with FLUTE, the FDT Instance needs
>> to be delivered
>>   regularly (at carousel startup and periodically later on). With a
>> solution that appends
>>   metadata to the file, once the object is decoded the receiver has
>> whatever he needs
>>   to exploit it, and the metadata needs to be delivered only once
>> (or at least as many
>>   times as the object itself, be it because of the repair redundancy
>> added or because of
>>   several carousel transmission cycles).
>>   1.2- is more efficient from an error recovery perspective, since
>> the metadata benefits
>>   naturally from the FEC protection of the object it belongs to
>> (when used). This is not
>>   the case with FLUTE.
>> 
>> 2- FLUTE has been designed to work on top of ALC. We can probably design an
>>  application that runs on top of both ALC and NORM (in fact I did it before).
>>  Honestly speaking, the same can perhaps be done with FLUTE, but it
>> has not been
>>  considered so far and I don't expect any update of FLUTE to do that.
>> 
>> Now we can also discuss about __IPR aspects__ since it is common
>> practice for working
>> groups to have a look at IPR details and get an opinion of its content.
>> 
>> As already explained, the foundations of the FCAST proposal come from a
>> public
>> document that has been published three years before the patent
>> priority date...
>> Concerning the possible extensions on top of this underlying
>> proposal, we clearly need to
>> be more careful... But the design team (assuming the RMT group
>> approves this initiative)
>> might also decide to stick with the basic scheme only. And somebody
>> else might also
>> come with another brand new technique.
>> 
>> Besides there are situations where there's no need to follow any
>> standard, and where
>> proprietary solutions are perfectly suitable. In that case the
>> designer will probably prefer
>> solutions that are not been subject to any IPR disclosure (which of
>> course does not mean
>> there is none, but no matter what you do, there will always be
>> risks). This is all the more
>> true as in these situations, IPR negotiations are more complex (as I
>> understand, correct
>> me if I'm wrong) than in case of well recognized standards where all
>> proponents benefit
>> from global patent pool negotiations.
>> 
>> Having said that, FLUTE remains a great, useful, technology, with
>> several commercial
>> perspectives of which many of us benefit, including myself. Don't
>> misunderstand me, it
>> has never been my intention to deny this point, and __I'm still a
>> FLUTE supporter__
>> for all situations where it makes sense.
>> 
>> Hope it clarifies my position.
>> 
>> Regards,
>> 
>> 
>>  Vincent.
>> 
>> NB: thanks for catching the error, RFC 3979 is the appropriate RFC.
>> 
>> Stephan Wenger wrote:
>> 
>>> Hi Vincent, folks,
>>> I believe I have said this in Prague already: it is somewhat tricky
>>> to design around a well written patent or patent application
>>> (especially if there is still a chance for the alarmed rightholder
>>> to  amend the claims).  I do not encourage such an attempt.  Let me
>>> suggest to base a decision predominantly on potential technical
>>> merits of a FLUTE successor, rather than attempting an arms-race
>>> with  lawyers on patent coverage.
>>> This is going to be my last statement on this matter.
>>> Cheers,
>>> Stephan
>>> P.s.: I work for Nokia, the company which has made an IPR
>>> disclosure  towards FLUTE-revised.
>>> P.p.s.: instead of RFC3667, you may wish to cite the up-to-date
>>> patent policy document (RFC3979), or use the generic designation
>>> (BCP79).
>>> 
>>> 
>>> On Dec 4, 2007, at 5:12 PM, Vincent Roca wrote:
>>> 
>>>> Hello,
>>>> 
>>>> During the RMT meeting, today morning, it was decided to ask the
>>>> RMT members
>>>> their opinion on the opportunity to continue the work on an
>>>> alternative to FLUTE
>>>> for which an IPR has been disclosed in June 2006 (see below for
>>>> the  details).
>>>> If feasible, this alternative application could be designed so
>>>> that  it works on both ALC
>>>> and NORM.
>>>> 
>>>> If it turns out that there is an interest, the sub-question is the
>>>> following:
>>>>  Are there volunteers to work on the subject in order to design an
>>>> alternative that
>>>>  bypasses the FLUTE patents?
>>>> 
>>>> Don't hesitate to speak up.
>>>> Cheers,
>>>> 
>>>>  Vincent.
>>>> 
>>>> 
>>>> ** Nokia's IPR disclosures  related to FLUTE:
>>>> https://datatracker.ietf.org/ipr/733/
>>>> but also:
>>>> https://datatracker.ietf.org/ipr/517/   (FLUTE and SDP)
>>>> https://datatracker.ietf.org/ipr/635/   (file aggregation for FLUTE)
>>>> https://datatracker.ietf.org/ipr/731/   (RFC 3926)
>>>> https://datatracker.ietf.org/ipr/102/   (the original IPR
>>>> disclosure, Feb. 2003)
>>>> 
>>>> ** IETF position W.R.T. IPR:
>>>> http://www.ietf.org/rfc/rfc3668.txt?number=3668
>>>> ** Minutes of IETF67 RMT meeting, where this point has been raised
>>>> (see item 6, "open discussion"):
>>>> http://www3.ietf.org/proceedings/06nov/minutes/rmt.html
>>>> 
>>>> **More information on the FCAST proposal is available here:
>>>> http://www3.ietf.org/proceedings/07mar/slides/rmt-0/sld1.htm
>>>> http://tools.ietf.org/html/draft-roca-rmt-newfcast-00
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Rmt mailing list
>>>> [email protected]
>>>> https://www1.ietf.org/mailman/listinfo/rmt
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> Rmt mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rmt
>