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

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