RE: FEB BB changes impacts on FLUTE and NORM

Hi Toni,

In the currently proposed set of drafts, then the definition of the
contents of the EXT_FTI is split between FLUTE and the FEC Scheme
specifications. As before, FLUTE specifies that the EXT-FTI always
starts with the Transfer Length and FEC Instance ID. Then the rest of
the contents depend on the FEC Scheme and the only change is that the
description of this is moved from FLUTE to the FEC Scheme
specifications. This was all deliberate - no luck involved ;-)

The encodings are not mis-aligned - what is specified in the new set of
drafts is backwards-compatible with what is in the old ones (assuming
the new FLUTE draft still defines the common part of the EXT-FTI
containing the Transfer Length and FEC Instance ID).

But I think your proposals move towards a cleaner split of the
description: FLUTE would not define anything about the *contents* of the
EXT-FTI and would defer to the FEC Scheme definitions for that part.
Remember that there may be many more FEC Schemes in future and each may
define a different format for the contents of the EXT-FTI so FLUTE
should not refer to any particular FEC Schemes draft. Instead you should
refer to the FEC BB e.g. "The contents of the EXT-FTI LCT header
extension are defined by the FEC Scheme as described in [FEC BB].")

We would then amend the FEC Schemes draft to define the full contents of
the EXT-FTI for each scheme. Note that I would not mention EXT-FTI
explicitly in the FEC Schemes, but rather say that the FEC Schemes
provide an encoding for the OTI and Content Delivery Protocols (of which
FLUTE is only one example) provide a place to carry this encoding. In
the case of FLUTE it is the EXT-FTI but in the case of other protocols
it could be somewhere else.

I can make the necessary changes to the FEC BB and FEC Schemes drafts
(we should probably review the set { FEC BB, FEC Scheme, FLUTE }
off-line to get them consistently joined together on this issue before
submitting revised versions.)

The remaining issue is where the EXT-FTI LCT Header Extension Type value
should be defined. Presently I think it is in FLUTE, but perhaps it
should be moved to LCT ?? The LCT update should probable include a
registry for LCT Header Extensions as well - any opinions on the
allocation rules ??

Regards,

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Thursday, September 15, 2005 10:59 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

Hello Mark,

Please find my answers inline.

> -----Original Message-----
> From: ext Mark Watson [mailto:[email protected]]
> Sent: 15 September, 2005 16:00
> To: Paila Toni (Nokia-M/Espoo); [email protected]; Walsh Rod
> (Nokia-NRC/Tampere); [email protected];
> [email protected]; [email protected]
> Subject: RE: [Rmt] 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.
> 

If I understand your proposal, you would like to specify the core
concepts of FEC in FEC BB without going to details. Then you would like
to have FLUTE just use the concepts by referring to the specification of
EXT_FTI. Yes, that sounds what I was trying to explain. Now the only
missing link is the place where EXT_FTI is specified. I believe you
explain it in the following:

> 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.
> 

I think this is a good idea. However, before going that way, let me
clarify a two of things:

1)
What is the source of the Figure 2 and Figure 5 in
(draft-ietf-rmt-bb-fec-basic-schemes-00)? I.e., where are they coming
from? Why I ask this question is that we already have almost identical
figures in RFC 3926 section 5.1.2.1 (similar to Figure 2) and section
5.1.2.2 (similar to Figure 5). What is the reason you did not use those
encodings?

2)
As far I see (draft-ietf-rmt-bb-fec-basic-schemes-00) does not yet
provide encodings for Transfer-Lenght and FEC Instance ID (in case of
underspecified schemes). Fortunately, RFC 3926 has defined these as well
- please see section 5.1.1.

My conclusion is that if we want to remove the EXT_FTI from FLUTE, the
cleanest way to do it is to have the spec text in
(draft-ietf-rmt-bb-fec-basic-schemes-00). Further, since that document
currenly has slighly misaligned encodings for FEC information and
missing encodings for some common pieces, complementing document
(draft-ietf-rmt-bb-fec-basic-schemes-00) with the relevant section 5.1.1
of RFC 3926 is needed.

Consequently I will remove the EXT_FTI definitions from section 5.1 and
clean up the section so that it only refers to
(draft-ietf-rmt-bb-fec-basic-schemes-00) for the specification of
EXT_FTI. 

What do you think?

Regards,
 Toni

> 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-rev
> ised-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
> 
>