Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt

["Luby, Michael" <[e-mail]>]

Hi Martin,
Comments below.
Best, Mike

On 10/17/12 2:13 AM, "Martin Stiemerling" <[e-mail]>
wrote:

>Hi Michael, all,
>
>Thanks for your comments, but I would have wished to see them either
>during the WG Last Call or latest during IETF LC.
***  My comments aren't crucial, and it seems they are going to be ignored
anyway.  I wish I had time to look at it earlier, but I didn't.  They are
clarifying comments, and if they aren't incorporated it only means that
the spec is a little less easy to understand, it isn't earth shattering.
>
>Anyhow, apart from the timing, the questions are probably good to be
>discussed. Especially, as there are IPR declarations for RFC 5170.
*** I don't understand this comment, as there were no IPR-related comments
in my feedback.
>
>Any feedback from the WG?
>
>Thanks,
>
>   Martin
>
>-- 
>IETF Transport Area Director
>
>[e-mail]
>
>NEC Laboratories Europe - Network Research Division NEC Europe Limited
>Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>Registered in England 283
>
>
>On 10/11/2012 08:23 PM, Luby, Michael wrote:
>> Some quick comments.
>>
>> (1) This proposal relies upon parts of RFC 5170 for the definition of
>>the
>> underlying LDPC staircase code.  However, it isn't completely explicit
>>in
>> this proposal about what exact parts/sections of RFC 5170 are to be used
>> in this proposal and how.  It would seem that explicit references to the
>> particular sections of RFC 5170 that are being used, and exactly how
>>these
>> parts of RFC 5170 are being inherited and used, would be useful
>>(probably
>> necessary).  Note that there are several codes with different FEC
>>encoding
>> IDs defined in RFC 5170, so making exact references to which parts are
>> used
>> and how is important.  An example of how this is not at all precisely
>> defined:
>>
>> 	Because of the requirement to have exactly one encoding symbol per
>> 	group, i.e., because G MUST be equal to 1 (Section 4.1
>> <http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04#section-4.1>),
>> several
>> 	parts of [RFC5170 <http://tools.ietf.org/html/rfc5170>] are useless.
>>In
>> particular, this is the case of
>> 	Section 5.6
>> <http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04#section-5.6>.
>> "Identifying the G Symbols of an Encoding Symbol
>> 	Group".
>>
>> This snippet above that says several parts of RFC 5170 are useless (very
>> vague), and it seems instead it should explicitly state what
>> parts are to be used and exactly how.  It provides one example of
>> something that is not is to be used from RFC 5170, but it seems that
>> it should be the other way around, stating explicitly what should be
>>used
>> and how.
>>
>>
>> (2) This proposal references RFC 5170 and RFC 5053, and makes some
>> comparisons.  However, there is also RFC 6330 that is relevant and is
>>not
>> mentioned or referenced in this proposal.  It would seem appropriate to
>>do
>> so.
>>
>> Thanks, Mike
>>
>>
>>
>> On 10/9/12 6:22 AM, "[e-mail]"
>><[e-mail]>
>> wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the FEC Framework Working Group of the
>>>IETF.
>>>
>>> 	Title           : Simple LDPC-Staircase Forward Error Correction (FEC)
>>> Scheme for FECFRAME
>>> 	Author(s)       : Vincent Roca
>>>                           Mathieu Cunche
>>>                           Jerome Lacan
>>> 	Filename        : draft-ietf-fecframe-ldpc-04.txt
>>> 	Pages           : 22
>>> 	Date            : 2012-10-09
>>>
>>> Abstract:
>>>    This document describes a fully-specified simple FEC scheme for
>>>LDPC-
>>>    Staircase codes that can be used to protect media streams along the
>>>    lines defined by the FECFRAME framework.  These codes have many
>>>    interesting properties: they are systematic codes, they perform
>>>close
>>>    to ideal codes in many use-cases and they also feature very high
>>>    encoding and decoding throughputs.  LDPC-Staircase codes are
>>>    therefore a good solution to protect a single high bitrate source
>>>    flow, or to protect globally several mid-rate flows within a single
>>>    FECFRAME instance.  They are also a good solution whenever the
>>>    processing load of a software encoder or decoder must be kept to a
>>>    minimum.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-fecframe-ldpc-04
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> Fecframe mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/fecframe
>>
>> _______________________________________________
>> Fecframe mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/fecframe
>>
>