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

From: Vincent Roca <[email-masked]>
Date: Wed, 09 Nov 2005 20:01:24 +0100

Dear colleagues,

Following the recommendation of Lorenzo on Monday, during the RMT WG 
session,
we are asking you whether you see any good reason to make the FLUTE File 
Aggregation
I-D (draft-neumann-rmt-flute-file-aggregation-02.txt)*** *a working 
group item or not.

Please do not hesitate to comment.

Cheers,

   Vincent.

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Christoph Neumann <[email-masked]>
Date: Sat, 19 Nov 2005 13:55:08 +0530

Dear all,
 To start the discussion on the object aggregation draft, I wanted to point
out some issues that I think are in favour of having this as an WG item.
 Physical aggregation scheme is of great advantage to avoid the coupon
collector problem. In the case of a large number of small files, physical
aggregation combined with FEC is the only way to effeciently transport the
content.
Therefore I think it is necessary to have some standardized solution for
that, which could possibly be reused in several use cases with different FEC
schemes...
The draft exaclty addresses this problem.
 I heard that some physical aggragation scheme has also been defined in 3GPP
MBMS, but I'm not really following 3GPP activities and are therefore not
aware of that. Maybe someone has an input here?
 Beside the coupon collector issue, some FEC schemes perform badly with
small files, and aggregating them, seems the only solution in this context
(as it has been mentioned on the slides during the rmt session).
 other comments? Suggestions?
 cheers,
 Christoph

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Nov 2005 11:23:47 +0100

Hi Christoph,

See inline.

> The draft exaclty addresses this problem.

But in the process it looses a number of properties that individual 
files. I think there would be a number of benefit to NOT use multi-part 
mime and instead use an FDT based scheme. Yes, unfortunately it will not 
be backwards compatible with the normal FDT, but it could have a number 
of benefit:

- The possibility to externally before receiving the object determine if 
all files already has been received or if some has. This is quite 
important to minimize the connection time when doing repeated 
transmission to repair/complete unfinished sessions.

- Possibility to extract data from an partially decoded block. With 
small files and large FEC blocks this becomes highly interesting. Thus 
the data offset and length needs to be available from external source. 
Special data integrity mechanisms to make this reliable may also need to 
be considered.

I think these comments becomes extra important when considering battery 
powered wireless devices.

> (as it has been mentioned on the slides during the rmt session).

The aggregation mechanism defined in 3GPP is to aggregate several 
different UDP datagram streams used in streaming. Please see
http://www.ietf.org/internet-drafts/draft-watson-tsvwg-fec-sf-00.txt
for the outline of that solution and which is an initial proposal for 
the most likely to be FECFrame WG. The actual 3GPP specification of this 
is TS 26.346:
http://www.3gpp.org/ftp/Specs/html-info/26346.htm
Select the latest version.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]