RE: FEB BB changes impacts on FLUTE and NORM

Toni,

Regarding EXT_FTI, do you mean that the whole EXT_FTI definition should
be in the FEC-BB ? This would be strange since the EXT-FTI is specific
to LCT (it being an LCT Header Extension) and the FEC-BB is not specific
to any particular protocols. I think we could define the encoding format
for the contents of the EXT-FTI in the FEC BB, and FLUTE (or LCT) would
need to define that the EXT_FTI LCT Header Extension could be used to
carry that.

5.1.2.1 and 5.1.2.2 contain FEC-scheme specific information and so
should not be in FLUTE. The proposal is not to discard these sections
but to include them in the definitions of those FEC Schemes (see
draft-ietf-rmt-bb-fec-basic-schemes-00). Btw, we should probably Last
Call that draft as well - it just collects together the previously
existing material on these FEC Schemes in one place and makes them
compliant to the new FEC BB.

Regards...Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Thursday, September 15, 2005 12:06 PM
To: Mark Watson; [email protected]; [email protected];
[email protected]; [email protected];
[email protected]
Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM

Dear Mark, FLUTE authors and all,

Doing the FLUTEbis work it occurred to me that the current FLUTE RFC
contains something that has wider applicability than FLUTE itself. What
I mean is the specification for EXT_FTI. My proposal is to move the
section 5.1 "Use of EXT_FTI for delivery of FEC Object Transmission
Information" of RFC 3926 to the to-be-proposed-standard FEC BB.
Investigating the case, I found that section 5.1 is specified in a clean
way - i.e., it can be nicely separated from FLUTE, shifted to FEC BB and
then referenced from FLUTE.

Actually this is pretty much in line with your comment 2) below. Only
thing I do not agree is the dropping of specific sections 5.1.2.1 and
5.1.2.2. Dropping the sections makes the specification weaker as it
leaves these essential details unspecified.

What do you think?

Please consider this as my formal comment in the FEC BB last call.

Regards,
 Toni

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of ext
Mark Watson
Sent: 02 August, 2005 12:39
To: [email protected]; Walsh Rod (Nokia-NRC/Tampere);
[email protected]
Subject: [Rmt] FEB BB changes impacts on FLUTE and NORM



All,

 

I was asked at the RMT session yesterday to summarise the impacts on the
RMT protocols which use the FEC Building Block of the changes proposed
in the FEC BB
(http://www.ietf.org/internet-drafts/draft-ietf-rmt-fec-bb-revised-00.tx
t). The requirements on Content Delivery Protocols are explicitly listed
in Section 8 of the FEC BB, so the task is really to bring FLUTE and
NORM into compliance with that section, without introducing backwards
compatibility issues.

 

>From a quick review I have come up with the following:

 

FLUTE:

1)     The FDT Schema needs updating to provide support for FEC
Scheme-specific Object Transmission Information, for example using the
FEC-OTI-Scheme-Specific-Info attribute defined in Section 7.2.10 of 3GPP
TS26.346 6.1.0 (
http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-610.zip)

2)     The FEC Encoding ID specific portion of the EXT-FTI should no
longer be defined in FLUTE except to say that it consists of (a subset
of) the Common FEC OTI elements (except the Transfer Length which is
included in the FLUTE General EXT-FTI portion) followed by (optionally)
the Scheme-Specific FEC OTI element the encoding formats of which are
defined by the FEC Scheme. As a result, the following changes are
needed:

a.      Remove section 5.1.2

b.      Modify the text on the FEC Encoding ID Specific Format in 5.1.1
according to the above

3)     The algorithm for computing source block structure should be
removed - this is in 5.1.2.2, so removing 5.1.2 as suggested in 2(a)
above achieves this.

4)     The description of the use of FDT for signaling the FEC OTI in
Section 5.2 needs modification to remove references to specific FEC
Encoding IDs and instead reference the Common FEC OTI Element
descriptions in the FEC Building Block. It should also be mentioned that
the value range for each of these Common elements is specified by the
FEC Scheme.

 

NORM:

1)     Most of the references to specific FEC Encoding ID values in the
NORM protocol are examples, so it would not be strictly necessary to
remove or modify these. But we could consider (for example) whether it
would be clearer to replace the description in 4.2.1 of the FEC Payload
ID for the Small Block Systematic FEC Scheme with a reference to the FEC
Schemes document.

2)     Likewise, the EXT-FTI format is given as an example. However, it
probably is necessary to specify the 'skeleton' EXT-FTI format - at
least to include the FEC Instance ID since it is a Mandatory OTI
element. At the moment I think it is assumed, although not explicit,
that the EXT-FTI format for NORM is the same as that for FLUTE and so
perhaps a reference to FLUTE would be appropriate ?

3)     The FEC Building Block does not require that each packet of data
contains only a single Encoding Symbol, wheras this requirement is
included in NORM section 5.1.1 - of course this can be resolved by just
defining the term 'symbol' differently in the context of NORM vs the
context of a particular FEC Scheme - but this can lead to confusion.

4)     NORM defines an object partitioning algorithm, in contrast to
FLUTE, which just recommended one, I think. The new FEC BB defines an
algorithm (which I believe to be the same, but others should check!) and
the FEC Schemes document requires that it be used for the FEC schemes
defined there. So, I am unsure whether this should be removed from NORM
and deferred to the FEC Scheme specifications or whether NORM should
refer to the FEC BB and require the same algorithm for all FEC Schemes -
I would prefer the former, since the way the input parameters are
calculated (particular the number of symbols per packet) may be FEC
Scheme-specific.

 

One potentially confusing point that I noticed is that the new FEC BB
proposal requires CDP specification to define "Means to reliably
communicate the Common FEC Object Transmission Information element from
sender to receiver(s) using either or both of (a) encoding formats
defined by the FEC Scheme or (b) encoding formats defined by the CDP"

 

(This should say 'elements' not 'element' in the second line)

 

The confusing point is that FLUTE will need to treat the Transfer Length
differently from the other Common OTI elements, since FLUTE defines a
single format for the Transfer Length in the general portion of the
EXT-FTI - we can't make the length of this field FEC-scheme specific
since it is before the FEC Instance ID. i.e. FLUTE defines both (a) and
(b) above for the Common FEC OTI elements with the exception of Transfer
Length, where is defines (b) only.

 

We could consider whether Transfer Length should be one of the Mandatory
FEC OTI elements, rather than a Common one.

 

Regards,

 

Mark