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