RE: FEB BB changes impacts on FLUTE and NORM

Mark, Toni, et al

I _think_ I am also OK with option #2 and will keep the EXT-FTI 
extension type in the NORM spec (as is already the case) with the 
details for specific FEC schemes deferred to individual schemes' 
specification.

The nice thing I thought about option #3 (putting the "generic" 
EXT_FTI in the FEC BB document) is that it doesn't have to show up 
_both_ in the NORM spec _and_ in the FLUTE or ALC spec  ... but I see 
Mark's point where all content delivery protocols may not have the 
same "generic" needs ...

A note I would make with regards on Mark's comment on the 
appropriateness of the "transfer length" in the generic portion of 
EXT_FTI is that the "transfer length" is also used for NORM "stream" 
objects.  Although "streams" are _not_ of fixed or finite length, for 
purposes of NACK repair requests, it is useful for receivers to know 
the sender's stream buffer size and the "transfer length" (or "object 
size") portion of the EXT_FTI is useful for that purpose.

For consistency, NORM does use the same EXT_FTI extension type as ALC 
(RFC 3450) and the same formats as FLUTE (RFC 3926) had specified ...

We probably need to make sure that we quickly document the FEC 
schemes we know including the complete FEC payload id and FEC OTI 
formats, etc since these are now not included in the FEC BB document? 
I liked having an example EXT_FTI format (from the old FEC BB 
document) to provide in the NORM spec and I thought that made the 
FLUTE spec also perhaps easier to interpret  ...






At 2:50 PM -0400 9/26/05, Mark Watson wrote:
>Toni,
>
>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
>
>-----Original Message-----
>From: [email protected] [mailto:[email protected]]
>Sent: Monday, September 26, 2005 11:31 AM
>To: Mark Watson; [email protected]
>Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
>
>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
>
>
>>  -----Original Message-----
>>  From: ext Mark Watson [mailto:[email protected]]
>>  Sent: 26 September, 2005 21:21
>>  To: Paila Toni (Nokia-M/Espoo); [email protected]
>>  Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
>>
>>
>>  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 protected] [mailto:[email protected]]
>>  Sent: Monday, September 26, 2005 10:19 AM
>>  To: Mark Watson; [email protected]
>>  Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
>>
>>  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
>>
>>  > -----Original Message-----
>>  > From: ext Mark Watson [mailto:[email protected]]
>>  > Sent: 26 September, 2005 20:16
>>  > To: Paila Toni (Nokia-M/Espoo); [email protected]
>>  > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
>>  >
>>  >
>>  > 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 protected] [mailto:[email protected]]
>>  > Sent: Monday, September 26, 2005 9:51 AM
>>  > To: Mark Watson; [email protected]
>>  > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
>>  >
>>  > 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
>>  >
>>  > > -----Original Message-----
>>  > > From: ext Mark Watson [mailto:[email protected]]
>>  > > Sent: 26 September, 2005 18:50
>>  > > To: Paila Toni (Nokia-M/Espoo); [email protected]
>>  > > 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
>>  > > -----Original Message-----
>>  > > From: <[email protected]>
>>  > > Date: Mon, 26 Sep 2005 08:20:45
>>  > > To:<[email protected]>
>>  > > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
>>  > >
>>  > > 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
>>  > > 
>>  > >  > -----Original Message-----
>>  > >  > From: ext Mark Watson [mailto:[email protected]]
>>  > >  > Sent: 16 September, 2005 11:09
>  > > >  > 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
>>  > >  >
>>  > >  >
>>  > >  > 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 ;-)
>>  > >  >
>>  > > 
>>  > >  Maybe we should then rename the updated RFC as FLUKE :)
>>  > > 
>>  > >  > 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).
>>  > >  >
>>  > > 
>>  > >  Yes. Maintaining the backwards compability in defining the
>>  > > encodings is very important.
>>  > > 
>>  > >  > 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].)
>>  > >  >
>>  > > 
>>  > >  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]?
>>  > > 
>>  > >  > 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.
>>  > >  >
>>  > > 
>>  > >  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?
>>  > > 
>>  > >  > 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.)
>>  > >  >
>>  > > 
>>  > >  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?
>>  > > 
>>  > >  > 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 ??
>>  > >  >
>>  > > 
>>  > >  I think we can do this in [FEB BB].
>>  > > 
>>  > >  > 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
>>  > >  > >
>>  > >  > >
>>  > >  >
>>  > > 
>>  > > 
>>  > > Sent from my BlackBerry.
>>  > >
>>  >
>>
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt


-- 
Brian
__________________________________
Brian Adamson
<mailto:[email protected]>