INRIA Rhône-Alpes - V. Roca - 1 FCAST: Scalable Object Delivery on top of the ALC Protocol IETF 68 th – Prague meeting, March 2007 Vincent Roca (INRIA)

INRIA Rhône-Alpes - V. Roca - 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

INRIA Rhône-Alpes - V. Roca - 3 I hereby declare that I haven’t tried to patent any technique that is described in and that I am not aware of any patent or other IPR claim related to this I-D.

INRIA Rhône-Alpes - V. Roca - 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

INRIA Rhône-Alpes - V. Roca - 5 A quick look at the patent Nokia’s IPR disclosure r_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."

INRIA Rhône-Alpes - V. Roca - 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

INRIA Rhône-Alpes - V. Roca - 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…

INRIA Rhône-Alpes - V. Roca - 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…

INRIA Rhône-Alpes - V. Roca - 9 A little bit of history, back in 2000 the first ALC I-D “Asynchronous Layered Coding: A scalable reliable multicast protocol”,  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

INRIA Rhône-Alpes - V. Roca - 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 |

INRIA Rhône-Alpes - V. Roca - 11 A little bit of history, back in 2000… (cont’) BTW, there’s nothing new in Claim1 of Nokia’s patent…  in, 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.

INRIA Rhône-Alpes - V. Roca - 12 The proposal follow-up of Fcast 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)

INRIA Rhône-Alpes - V. Roca - 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

INRIA Rhône-Alpes - V. Roca - 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

INRIA Rhône-Alpes - V. Roca - 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…

INRIA Rhône-Alpes - V. Roca - 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.