FCAST: Scalable Object Delivery on top of the ALC Protocol

1. <draft-roca-rmt-newfcast-00.txt>IETF 68th – Prague meeting, March 2007 Vincent Roca (INRIA) FCAST: Scalable Object Delivery on top of the ALC Protocol

2. If you missed the San Diego meeting… • initiative motivated by Nokia’s patent on Flute • patent granted in 2004… • but we (Flute co-authors and RMT group) only discovered it at the end of 2006 • today’s goals: • have a deeper look at the patent • see if (hopefully non patented) alternatives are feasible • decide if it’s worth the pain

3. I hereby declare that I haven’t tried to patent any technique that is described in <draft-roca-rmt-newfcast-00.txt> and that I am not aware of any patent or other IPR claim related to this I-D.

4. Outline • a quick look at the patent • a little bit of history, back in 2000 • the proposal (see the I-D for more details) • discussion

5. A quick look at the patent • Nokia’s IPR disclosure https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=733 • licensing conditions (INRIA/Nokia exchange, November 2006) • "INRIA is free to do what they want for their software, but if Nokia patent is used for commercial purpose, then a proper license is required. Nokia is committed to provide the license on FRAND (fair, reasonable and non-discriminatory) principles."

6. A quick look at the patent… (cont’) • administrative aspects • priority date: January 31, 2003 • i.e. a few days before Toni submitted the “File Delivery over ALC” I-D • granted on August 2004 • title: DATACAST FILE TRANSMISSION WITH META-DATA RETENTION

7. A quick look at the patent… (cont’) • claim1 (claim7 is similar): 1. A device for receiving datacast information comprising: […] - means for arranging the object packets into at least a first object and a second object based on the object packet's transmission object identifiers; - means for extracting meta-data from the first object pertaining to the second object as identified by its transmission object identifier; and - means for storing the second object in non-volatile memory as a file having one or more properties identified by the extracted meta-data. It’s Flute’s basic principle: an FDT Instance object contains the meta-data associated to files that are sent in separate objects…

8. A quick look at the patent… (cont’) • other claims build on this idea • what can we do then? • question the validity of the patent, showing prior art? • design something different that does not use claim1 (and 7)? • it’s the purpose of this I-D…

9. A little bit of history, back in 2000 • the first ALC I-D “Asynchronous Layered Coding: A scalable reliable multicast protocol”, <draft-ietf-rmt-pi-alc-00.txt> • from: Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff • published on March, 2000: • of particular interest • A.3. File Transfer using ALC - "Fcast“ • principle: append meta-data to the file’s content

10. A little bit of history, back in 2000… (cont’) • object format: • the trailer contains MIME fields: • Content-Location • Last-modified • Content-Length • Content-Encoding… +----------------------------------------------+ | Object | 4-byte checksum | Null padding| +----------------------------------------------+ / \ | ........... | \ | .......... / \ +--------------------------------------+ | File data | Trailer | Trailer Length | +--------------------------------------+

11. A little bit of history, back in 2000… (cont’) • BTW, there’s nothing new in Claim1 of Nokia’s patent… • in <draft-ietf-rmt-pi-alc-00.txt>, A.3., it is said: • is it sufficient to say there’s prior art? • I’m not a lawyer, so… When the object being transmitted is a file, the receiver usually requires "metadata" in addition to the file itself, such as the file name, its creation date, etc. Metadata can be sent a number of ways. For example, it could be part of the object session description or sent as a separate ALC object with a well-known object transmission label. The method described here combines the file with its metadata in a single ALC object.

12. The proposal • follow-up of Fcast <draft-ietf-rmt-pi-alc-00.txt> • the initial Fcast has a major limitation: • extracting meta-data requires to download and decode the whole object, which may be: • costly (power consumption) • impossible (not enough memory to decode the object) • especially if the client discovers he cannot process the object (e.g. non supported format)

13. The proposal… (cont’) • two complementary but optional ways to carry meta-data in new Fcast: • append meta-data to the object (idem) • add a dedicated EXT_OMD (Object Meta-Data) header extension to the ALC/LCT packets • the EXT_OMD can be processed immediately, and the client may decide whether or not he needs the object

14. The proposal… (cont’) • in practice: • put only a subset (e.g. Content-Length/Content-Encoding) in the EXT_OMD, the rest being appended • with small objects, no need to use EXT_OMD • send EXT_OMD in the first few packets sent for a new object, and then periodically • add an Fcast session description object • it describes the session’s content, not the objects • lists the objects (i.e. their TOI) that are part of the current carousel instance

15. Discussion • what’s next? • Option 1: is the patent valid? • NB: I’m not a lawyer… • Option 2: we don’t care about patents and leave everything as it is… • NB: I don’t like it but you might disagree…

16. Discussion… (cont’) • Option 3: we continue along the lines sketched here (or something else if somebody has better ideas…) • NB: this proposal can be extended to work on top of both ALC and NORM… We (INRIA) did it in the past… • NB: thanks’ to the experience gained with Flute, it should not take too long • NB: even if Flute is included (definitively) into several standards (3GPP, DVB), there are use-cases where having a brand new application is not an issue • e.g. file distribution within clusters, grids, servers, etc.