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.
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.