RE: FEB BB changes impacts on FLUTE and NORM

Hi Mark
 
Specific responses for FLUTE changes:
 
1) OK - new schema will be checked and taken in if fine
 
 
2) Perhaps the whole EXT_FTI should be in the FEC-BB as it is more useful than just for FLUTE (see Toni's comments)
 
2a. OK providing FEC-BB preserves all the information specified (to be checked)
 
2b. OK - see comments on (4) below
 
 
3) OK . However there are a couple of issues with FEC-BB...
 
- FEC-BB §9.1 references the experimental FLUTE. Please remove this reference or change to a note "to be removed by the RFC editor"
 
- The improved (FEC-BB) wording doesn't take into account the improved integer version Vincent, Jani & Sami produced. (though it does remove the important note that the alg does not imply floating point arithmetic). This was all put in because of actual implementation experience and bugs so the integer stuff really does need mentioning. I guess using the integer algorithm (with improved wording if possible) is the best solution. 
 
 
4) OK - but this relates to the definition of EXT_FTI. I think it should say in each instance "semantically equivalent to X as defined in the FEC-BB [REF]". Though I need to check that the FEC-BB does properly define these in this context...
 
Cheers, Rod.
 



________________________________

	From: ext Mark Watson [mailto:[email protected]] 
	Sent: 02 August, 2005 12:39
	To: [email protected]; Walsh Rod (Nokia-NRC/Tampere); [email protected]
	Subject: 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.txt). 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