Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM

From: [email-masked]
Date: Thu, 15 Sep 2005 13:06:19 +0300

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

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

---

From: [email-masked]
Date: Thu, 15 Sep 2005 14:30:08 +0300

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-masked]] 
	Sent: 02 August, 2005 12:39
	To: [email-masked]; Walsh Rod (Nokia-NRC/Tampere); [email-masked]
	Subject: FEB BB changes impacts on FLUTE and NORM

	All,

	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)

	a.      Remove section 5.1.2

	NORM:

	Regards,

	Mark

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 15 Sep 2005 09:00:15 -0400

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-masked] [mailto:[email-masked]] 
Sent: Thursday, September 15, 2005 12:06 PM
To: Mark Watson; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM

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?

Regards,
 Toni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Mark Watson
Sent: 02 August, 2005 12:39
To: [email-masked]; Walsh Rod (Nokia-NRC/Tampere);
[email-masked]
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.

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"

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

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 15 Sep 2005 09:15:10 -0400

Rod,

Responses below marked MW:...

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

Hi Mark

MW: Make sure you get the new one that was agreed last week (ftp://ftp.3gpp.org/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050641.zip). Additionally, the Schema in the FLUTE RFC is not valid according to XML. 3GPP took the liberty of writing down what they thought the FLUTE FDT Schema 'ought' to be if it was modified to be valid XML, so I would suggest starting with that.

MW: See my response to Toni's comment.

MW: That was the intention.

 

MW: It's just an informative reference to indicate that the algorithm is identical to the one previously specified in the Experimental RFC. Is this a problem ? We can remove it if you like.

MW: There isn't any non-integer arithmetic in the algorithm specified in the new FEC BB. The problem with the previous algorithm was that it had an actual real-valued variable 'A_fraction' which was the multiplied by some integer and thus the integer implementation of this was not so clear. But this is removed now.

Can you point me at the other description that you refer to so I can better understand the difference ?

MW: Nothing to do with EXT-FTI, just the FDT. But yes, it should refer to the FEC BB just as you suggest. The FEC BB should indeed properly define these things and the FEC Schemes define the value ranges.

...Mark
 
Cheers, Rod.

	All,

	FLUTE:

	a.      Remove section 5.1.2

	NORM:

	Regards,

	Mark

---

From: [email-masked]
Date: Thu, 15 Sep 2005 23:59:21 +0300

Hello Mark,

Please find my answers inline.

> Sent: 15 September, 2005 16:00
> To: Paila Toni (Nokia-M/Espoo); [email-masked]; Walsh Rod
> (Nokia-NRC/Tampere); [email-masked];
> [email-masked]; [email-masked]

> 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

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 16 Sep 2005 04:08:33 -0400

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-masked] [mailto:[email-masked]] 
Sent: Thursday, September 15, 2005 10:59 PM
To: Mark Watson; [email-masked]; [email-masked];

Hello Mark,

> need to define that the EXT_FTI LCT Header Extension could be used to

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

> 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

---

From: [email-masked]
Date: Fri, 16 Sep 2005 11:15:23 +0300

Please see in-line... 

>MW: Make sure you get the new one that was agreed last week 
>(ftp://ftp.3gpp.org/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050641.zi
p). Additionally, the Schema in the FLUTE RFC is not valid >according to XML. 3GPP took the liberty of writing down what 
>they thought the FLUTE FDT Schema 'ought' to be if it was 
>modified to be valid XML, so I would suggest starting with that.

I have this, the DVB one and the original produced by Jani, Sami, Magnus and myself which went into the 3GPP CR. Don't worry, if there's a bug it will not be in the IETF! (Otherwise, I'll be looking for a sponsor to provide an edible hat :)

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

Yep, let's take that on the other thread.

>MW: That was the intention.

My complete FEC-BB review is nigh...

>- FEC-BB §9.1 references the experimental FLUTE. Please remove 
>this reference or change to a note "to be removed by the RFC editor"
>
>MW: It's just an informative reference to indicate that the 
>algorithm is identical to the one previously specified in the 
>Experimental RFC. Is this a problem ? We can remove it if you like.

Yep, this mustn't go into the standards track FEC-BB RFC. It's good as a note to be removed until all FLUTE, ALC, LCT, FEC-BB, FEC-basic are re-aligned

>- 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. 
> 
>MW: There isn't any non-integer arithmetic in the algorithm 
>specified in the new FEC BB. The problem with the previous 
>algorithm was that it had an actual real-valued variable 
>'A_fraction' which was the multiplied by some integer and thus 
>the integer implementation of this was not so clear. But this 
>is removed now.

I take another look and bring it up again only if there need for something different.

>I can better understand the difference ?

http://www.watersprings.org/pub/id/draft-peltotalo-rmt-bb-fec-supp-xor-pcm-rs-00.txt

>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...
>
>MW: Nothing to do with EXT-FTI, just the FDT. But yes, it 
>should refer to the FEC BB just as you suggest. The FEC BB 
>should indeed properly define these things and the FEC Schemes 
>define the value ranges.

EXP FLUTE says "field X of FDT is sementically equivalent to field Y of EXT_FTI" in a number of places. This link needs preserving even though specific mention of FEC ID numbers can be pushed elsewhere (FEC-BB or FEC-basic, etc.).

Cheers, Rod.

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 16 Sep 2005 05:11:54 -0400

Hi Rod,

1) DVB agreed corrected schema yesterday, so you probably do not have the most up-to-date (but for reasons which are obscure to me they did not agree to align with 3GPP/IETF).

3) So you think the Standards Track docs should not even make *informative* references to the Experimental ones ? Even just to state that they are backwards compatible with them ? The reference would be in the "Informative References" section. I thought that the ban of referencing Experimental documents was for Normative References only ?

4) The link between the OTI elements in the FDT and the OTI elements in the EXT-FTI is preserved in the sense that both FDT elements and EXT-FTI elements are defined (semantically) in the FEC BB - i.e. both FDT OTI and EXT-OTI point to FEC BB, rather than FDT OTI pointing to EXT-FTI.

Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 16, 2005 10:15 AM
To: Mark Watson; [email-masked]; [email-masked]
Subject: RE: FEB BB changes impacts on FLUTE and NORM

Please see in-line... 

Cheers, Rod.

---

From: [email-masked]
Date: Fri, 16 Sep 2005 12:51:10 +0300

Hi Mark

>1) DVB agreed corrected schema yesterday, so you probably do 
>not have the most up-to-date (but for reasons which are 
>obscure to me they did not agree to align with 3GPP/IETF).

ok

>3) So you think the Standards Track docs should not even make 
>*informative* references to the Experimental ones ? Even just 
>to state that they are backwards compatible with them ? The 
>reference would be in the "Informative References" section. I 
>thought that the ban of referencing Experimental documents was 
>for Normative References only ?

informational ref to EXP is ok in general. However, referencing a (soon
to be) obsolete version of the RMT RFC family seems strange when in 6
months (hopefully) the only FLUTE of interest will not be 3926. I think
"passing WGLC" will be enough justification for the alg in FEC-BB, it
does not need to justify itself. From experimental, an implementer will
see the block removed from standards track FLUTE and the ref to the new
FEC-BB so at no point will there need to be a reference back to EXP
FLUTE.

>4) The link between the OTI elements in the FDT and the OTI 
>elements in the EXT-FTI is preserved in the sense that both 
>FDT elements and EXT-FTI elements are defined (semantically) 
>in the FEC BB - i.e. both FDT OTI and EXT-OTI point to FEC BB, 
>rather than FDT OTI pointing to EXT-FTI.

ok - my full review of FEC-BB is even more nigh :)

Cheers, Rod.

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 16 Sep 2005 10:31:18 +0000 GMT

Ok, I agree on (3) below.

...Mark.
-----Original Message-----
From: <[email-masked]>
Date: Fri, 16 Sep 2005 05:51:46 
To:<[email-masked]>
Subject: RE: FEB BB changes impacts on FLUTE and NORM

Hi Mark

 ok
 
 >reference would be in the Informative References section. I
 
 passing WGLC will be enough justification for the alg in FEC-BB, it

 
 Cheers, Rod.

Sent from my BlackBerry.

---

From: [email-masked]
Date: Mon, 26 Sep 2005 15:20:07 +0300

Hello Mark,

Thank you for good and detailed comments. I'm sorry for my late response. Last week I was traveling. Please find my comments inline.

Regards,
 Toni

> Sent: 16 September, 2005 11:09

Maybe we should then rename the updated RFC as FLUKE :)

> containing the Transfer Length and FEC Instance ID).

Yes. Maintaining the backwards compability in defining the encodings is very important.
 
> extension are defined by the FEC Scheme as described in [FEC BB].")

Let me try to understand this. Your proposal is to include the basic specification of EXT_FTI in [FEC BB]. That would mean more or less copy-pasting the first part of section 5.1 and section 5.1.1. of FLUTE in [FEC BB]. Did I understand it right? If so, this sounds an excellent idea. Could you go forward and make the needed changes in [FEC BB]?

> it could be somewhere else.

Again, let me restate what you say. The encodings in FLUTE section 5.1.2 would be then included in "Basic Forward Error Correction (FEC) Schemes" [draft-ietf-rmt-bb-fec-basic-schemes-revised-00]. Actually, as you said before - they already are. Did I get it right? 

> submitting revised versions.)

Let's do it! The authors of FLUTE are putting FLUTEbis together. Based on the discussion and agreement on the split of specifications, we will remove section 5.1 altogether from FLUTE. We will also do necessary changes in the beginning of chapter 5 to accommodate this and add [FEC BB] and [draft-ietf-rmt-bb-fec-basic-schemes-revised-00] as references. Or, would [FEB BB] be enough?

> registry for LCT Header Extensions as well - any opinions on the

I think we can do this in [FEB BB].

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 26 Sep 2005 15:50:01 +0000 GMT

Hi Toni,

Yes, your summaries are correct, except that presently in the new FEC BB and FEC schemes, the EXT_FTI is split into two parts: a generic part containing transfer length and FEC instance Id, and .a part specific to each FEC scheme. The generic part is defined in FLUTE and the rest in each FEC scheme.

What I was proposing (in fact I thought it was what you were proposing) is that the whole contents of the EXT-FTI should be defined by each FEC scheme, even if the the existing schemes it will always start the same way with the transfer length and FEC instance Id.

...mark
-----Original Message-----
From: <[email-masked]>
Date: Mon, 26 Sep 2005 08:20:45 

Hello Mark,

 Regards,
  Toni

 

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

 > it could be somewhere else.
 
 Again, let me restate what you say. The encodings in FLUTE section 5.1.2 would be then included in Basic Forward Error Correction (FEC) Schemes [draft-ietf-rmt-bb-fec-basic-schemes-revised-00]. Actually, as you said before - they already are. Did I get it right?

 

 > > 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.
 > > proposal requires CDP specification to define Means to reliably
 > > defined by the FEC Scheme or (b) encoding formats defined
 > by the CDP
 > >
 > > 
 > >

Sent from my BlackBerry.

---

From: [email-masked]
Date: Mon, 26 Sep 2005 19:50:48 +0300

Hi Mark,

> What I was proposing (in fact I thought it was what you were 
> proposing) is that the whole contents of the EXT-FTI should 
> be defined by each FEC scheme, even if the the existing 
> schemes it will always start the same way with the transfer 
> length and FEC instance Id.

Splitting the definition between "FEC BB" and "Basic FEC Schemes" is OK to me. I'm only concerned about maintaining the existing definitions as they are, outside FLUTE.

Is is OK if you specify the generic EXT_FTI part in "FEC BB" and the individual encodings (or endings) in the "Basic FEC Schemes"?

Regards,
 Toni

> Sent: 26 September, 2005 18:50
> To: Paila Toni (Nokia-M/Espoo); [email-masked]
> Subject: Re: [Rmt] FEB BB changes impacts on FLUTE and NORM
> 
> 
> Hi Toni,
> 
> Yes, your summaries are correct, except that presently in the 
> new FEC BB and FEC schemes, the EXT_FTI is split into two 
> parts: a generic part containing transfer length and FEC 
> instance Id, and .a part specific to each FEC scheme. The 
> generic part is defined in FLUTE and the rest in each FEC scheme.
> 
> What I was proposing (in fact I thought it was what you were 
> proposing) is that the whole contents of the EXT-FTI should 
> be defined by each FEC scheme, even if the the existing 
> schemes it will always start the same way with the transfer 
> length and FEC instance Id.
> 
> ...mark
>  Thank you for good and detailed comments. I'm sorry for my 
> late response. Last week I was traveling. Please find my 
> comments inline.
>  
>  Regards,
>   Toni
>  
>  Let me try to understand this. Your proposal is to include 
> the basic specification of EXT_FTI in [FEC BB]. That would 
> mean more or less copy-pasting the first part of section 5.1 
> and section 5.1.1. of FLUTE in [FEC BB]. Did I understand it 
> right? If so, this sounds an excellent idea. Could you go 
> forward and make the needed changes in [FEC BB]?
>  
>  Again, let me restate what you say. The encodings in FLUTE 
> section 5.1.2 would be then included in Basic Forward Error 
> Correction (FEC) Schemes 
> [draft-ietf-rmt-bb-fec-basic-schemes-revised-00]. Actually, 
> as you said before - they already are. Did I get it right?
>  
>  Let's do it! The authors of FLUTE are putting FLUTEbis 
> together. Based on the discussion and agreement on the split 
> of specifications, we will remove section 5.1 altogether from 
> FLUTE. We will also do necessary changes in the beginning of 
> chapter 5 to accommodate this and add [FEC BB] and 
> [draft-ietf-rmt-bb-fec-basic-schemes-revised-00] as 
> references. Or, would [FEB BB] be enough?
>

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 26 Sep 2005 13:16:18 -0400

Hi Toni,

Actually, right now the generic part is specified in FLUTE, so moving
that to the FEC BB would broaden its applicability to protocols other
than FLUTE and even protocols which used some other container than
EXT-FTI for this information.

So, I would prefer that either (i) the generic part is defined wherever
the EXT-FTI header extension code is defined - which should be FLUTE,
ALC or LCT or (ii) there is no generic part and each FEC Scheme defines
its own format (accepting that for the existing schemes, the first bytes
of the formats will all look the same).

...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 26, 2005 9:51 AM
To: Mark Watson; [email-masked]
Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM

Hi Mark,

> length and FEC instance Id.

Splitting the definition between "FEC BB" and "Basic FEC Schemes" is OK
to me. I'm only concerned about maintaining the existing definitions as
they are, outside FLUTE.

Is is OK if you specify the generic EXT_FTI part in "FEC BB" and the
individual encodings (or endings) in the "Basic FEC Schemes"?

Regards,
 Toni

---

From: [email-masked]
Date: Mon, 26 Sep 2005 20:19:21 +0300

Hello Mark,

(i) OK - let's put this into "FEC BB".

(ii) OK - let's put these (actually they already are) in "Basic FEC Schemes" document.

Regards,
 Toni

> Sent: 26 September, 2005 20:16

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 26 Sep 2005 14:20:46 -0400

Hi Toni,

Actually, (i) and (ii) below were alternatives. So I'm not sure which
you prefer!

The two options (IMO) are:
(i) generic part of EXT-FTI defined in FLUTE or ALC or LCT plus
Scheme-specific part defined in the FEC Schemes

OR

(ii) whole format defined separately in each FEC Scheme - but of course
the format will be aligned with the present one, so no backwards
compatibility issues.

In both cases, the ETX-FTI header extension type should be defined in
FLUTE or ALC or LCT (tbd) as it is specific to that protocol.

Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 26, 2005 10:19 AM
To: Mark Watson; [email-masked]
Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM

Hello Mark,

(ii) OK - let's put these (actually they already are) in "Basic FEC
Schemes" document.

Regards,
 Toni

---

From: [email-masked]
Date: Mon, 26 Sep 2005 21:31:27 +0300

Hello Mark,

Seems that I read your previous email too quickly...

Anyway, I prefer to have the definition of EXT_FTI not in FLUTE. The reason is that EXT_FTI is more widely appicable than just FLUTE. Also, as I said earlier, we can put this either in the "FEC BB" or "Basic FEC Schemes" since they define the FEC issues. Under these conditions I would go for one of the following (first one is my favourite).

1) generic part of EXT_FTI defined in ALC and Scheme-specific part defined in the FEC Schemes.

2) both the generic part of EXT_FTI and Scheme-specific part defined in FEC Schemes 

3) generic part of EXT-FTI defined in FEC BB and Scheme-specific part defined in the FEC Schemes.

What is your view?

Regards,
 Toni

> Sent: 26 September, 2005 21:21

---

From: [email-masked]
Date: Mon, 26 Sep 2005 21:56:28 +0300

Hello Mark,

Yes, let's go for (2) with the brief definition of the EXT_FTI header extension type in ALC, as you propose.

That is:
- very brief declaration of the EXT_FTI header extension type in ALC
- both the generic part of EXT_FTI and Scheme-specific part defined in "Basic FEC Schemes"

Regards, 
 Toni

> Sent: 26 September, 2005 21:51
> Of these, I would go for (2), except that I would still put the
> definition of the EXT-FTI header extension type in ALC. Then the FEC
> Schemes would provide the complete details of the encoding of the
> contents of the EXT_FTI (in fact, they provide complete details of the
> encoding of the FEC OTI and then in the specific case of ALC/LCT we
> specify that EXT_FTI is used to carry this data - other 
> future protocols
> might carry it some other way).
> 
> The problem with (1), is that the generic part of the EXT-FTI includes
> the Transfer Length, which is kind of specific to fixed length object
> delivery and so it might not be appropriate to have this in ALC which
> could in future have wider application than delivery of fixed length
> objects.
> 
> The problem with (3) is that EXT-FTI is specific to a particular
> protocol (ALC/LCT) and so it's not appropriate to have it in 
> the FEC BB
> which is supposed to be protocol-independent.
> 
> So, can we agree on (2) ?
> 
> ...Mark
> 
> Sent: Monday, September 26, 2005 11:31 AM
> Anyway, I prefer to have the definition of EXT_FTI not in FLUTE. The
> reason is that EXT_FTI is more widely appicable than just FLUTE. Also,
> as I said earlier, we can put this either in the "FEC BB" or 
> "Basic FEC
> Schemes" since they define the FEC issues. Under these conditions I
> would go for one of the following (first one is my favourite).
> 
> 2) both the generic part of EXT_FTI and Scheme-specific part 
> defined in
> FEC Schemes 
> 
> > > >  > > for the contents of the EXT-FTI in the FEC BB, and 
> FLUTE (or
> > > >  > > LCT) would
> > > >  > > 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
> > > >  > > ID for the Small Block Systematic FEC Scheme with 
> a reference
> > > >  > > to the FEC
> > > >  > > Schemes document.
> > > >  > >
> > > >  > > algorithm (which I believe to be the same, but 
> others should
> > > >  > > check!) and
> > > >  > > defined there. So, I am unsure whether this should 
> be removed
> > > >  > > from NORM
> > > >  > > (b) above for the Common FEC OTI elements with the 
> exception
> > > >  > > of Transfer

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 26 Sep 2005 15:05:37 -0400

Toni,

Ok - just to be clear, though, the FEC Schemes will define the full
encoding format but they won't actually specify that it is EXT-FTI that
is used to carry that information, because other future (non-LCT-based)
protocols might carry the same information in a different place.

Then in ALC we will define EXT-FTI and say that the OTI encoding format
defined by the FEC Scheme is carried within the EXT-FTI.

...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 26, 2005 11:56 AM
To: Mark Watson; [email-masked]
Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM

Hello Mark,

Yes, let's go for (2) with the brief definition of the EXT_FTI header
extension type in ALC, as you propose.

That is:
- very brief declaration of the EXT_FTI header extension type in ALC
- both the generic part of EXT_FTI and Scheme-specific part defined in
"Basic FEC Schemes"

Regards, 
 Toni

---

From: [email-masked]
Date: Mon, 26 Sep 2005 22:08:18 +0300

Mark,

OK.

And FLUTE will say that EXT_FTI or FDT is used. For EXT_FTI we refer to ALC + Basic FEC schemes.

Toni

> Sent: 26 September, 2005 22:06
> > 3) generic part of EXT-FTI defined in FEC BB and 
> Scheme-specific part
> > defined in the FEC Schemes.
> > 
> > What is your view?
> > 
> > Regards,
> >  Toni
> > 
> > 
> > > > >  > The encodings are not mis-aligned - what is 
> specified in the
> > > > >  > new set of
> > > > >  > should not refer to any particular FEC Schemes 
> draft. Instead
> > > > >  > you should
> > > > >  > We would then amend the FEC Schemes draft to 
> define the full
> > > > >  > contents of
> > > > >  > The remaining issue is where the EXT-FTI LCT 
> Header Extension
> > > > >  > Type value
> > > > >  > > 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
> > > > >  > > need to define that the EXT_FTI LCT Header 
> Extension could
> > > > >  > be used to
> > > > >  > > carry that.
> > > > >  > >
> > > > >  >
> > > > >  > concepts of FEC in FEC BB without going to 
> details. Then you
> > > > >  > would like
> > > > >  > 5.1.2.2 (similar to Figure 5). What is the reason 
> you did not
> > > > >  > use those
> > > > >  > encodings?
> > > > >  >
> > > > >  > 2)
> > > > >  > > contains something that has wider applicability 
> than FLUTE
> > > > >  > > itself. What
> > > > >  > > From: [email-masked] 
> [mailto:[email-masked]]On
> > > > >  > > Behalf Of ext
> > > > >  > > Mark Watson
> > > > >  > > NORM into compliance with that section, without 
> introducing
> > > > >  > backwards
> > > > >  > > compatibility issues.
> > > > >  > >
> > > > >  > > 
> > > > >  > >
> > > > >  > > included in the FLUTE General EXT-FTI portion) 
> followed by
> > > > >  > > (optionally)
> > > > >  > > the Scheme-Specific FEC OTI element the encoding 
> formats of
> > > > >  > which are
> > > > >  > > 4)     The description of the use of FDT for 
> signaling the
> > > > >  > FEC OTI in
> > > > >  > > 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
> > > > >  > > 2)     Likewise, the EXT-FTI format is given as 
> an example.
> > > > >  > > However, it
> > > > >  > > FLUTE, which just recommended one, I think. The 
> new FEC BB
> > > > >  > defines an
> > > > >  > > refer to the FEC BB and require the same 
> algorithm for all
> > > > >  > > FEC Schemes -
> > > > >  > > One potentially confusing point that I noticed 
> is that the
> > > > >  > new FEC BB
> > > > >  > > communicate the Common FEC Object Transmission 
> Information
> > > > >  > > element from
> > > > >  > > differently from the other Common OTI elements, 
> since FLUTE
> > > > >  > defines a
> > > > >  > > since it is before the FEC Instance ID. i.e. 
> FLUTE defines
> > > > >  > > both (a) and
> > > > >  > > We could consider whether Transfer Length should 
> be one of
> > > > >  > > the Mandatory