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

From: [email-masked]
Date: Tue, 09 Oct 2012 06:22:06 -0700

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/

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 11 Oct 2012 18:23:34 +0000

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, "[email-masked]" <[email-masked]>
wrote:

>_______________________________________________
>Fecframe mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/fecframe

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 17 Oct 2012 11:13:55 +0200

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.

Anyhow, apart from the timing, the questions are probably good to be 
discussed. Especially, as there are IPR declarations for RFC 5170.

Any feedback from the WG?

Thanks,

   Martin

-- 
IETF Transport Area Director

[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

---

From: Vincent Roca <[email-masked]>
Date: Wed, 17 Oct 2012 13:59:31 +0200

Mike,

Thanks for your feedback.

>> it should be the other way around, stating explicitly what should be used

I have no doubt that an implementer will find its way in RFC5170 and identify
what needs to be used. With the further restriction of having G=1, the
specifications of RFC5170 become fairly small (~14 technical pages, pseudo-code
included) and easy to understand IMHO.

We are not planning to change anything here unless the IESG asks us to do so.

>> mentioned or referenced in this proposal.  It would seem appropriate to do

This list is not intended to be exhaustive. No other FEC scheme tries to provide
an exhaustive list: RFC5053 (Raptor) does not reference any other FEC scheme,
and RFC6330 (RaptorQ) / RFC6681 (Raptor(Q) for FECFRAME) only reference
Raptor.

More importantly. Since:

1- you noticed we impose restrictions on the way LDPC-Staircase codes are
  being used in section 4.1;

2- you certainly remember the discussion we had in 2009 concerning 10 out
  of the 13 patents mentioned in the RFC5170 IPR disclosure, whose conclusion
  is here:
	http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html

3- the present I-D only considers LDPC-Staircase codes whereas RFC5170
   defines two FEC schemes;

you will probably conclude like us that QC's IPR disclosure for RFC5170 does
not necessarily apply to this I-D. Hence our question: does QC intend to do
a new IPR disclosure? When?

Regards,

    Vincent, on behalf of the authors

NB: I'm adding Stephen Farrell who first identified the IPR disclosure question
during IESG review.

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 17 Oct 2012 13:24:07 +0000

Hi Martin,
Comments below.
Best, Mike

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

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 17 Oct 2012 13:41:59 +0000

Vincent,
You are welcome.  Responses below.
Best, Mike

>We are not planning to change anything here unless the IESG asks us to do

*** The above suggestions I made are clarifying comments, and if they
aren't incorporated it only means that the spec is a little less easy to
understand and implement, it isn't earth shattering.

>and RFC6330 (RaptorQ) / RFC6681 (Raptor(Q) for FECFRAME) only reference

*** Ok.  However, the difference is that RFC 5053 and RFC 6330 and RFC
6681 don't have any survey like comparisons to other FEC technology
(except that of course the 6330 does have text to justify its existence
vis a vis 5053), whereas this specification does seems to try and make
some comparisons to other technologies out there.  Its ok as is, just
means it isn't quite as good of a comparison list as it could have been
given that a comparison survey is included at all.  The other option of
course would have been not to have such comparisons to other FEC within
the document at all, which is the path that 5053 and 6330 take.
>a new IPR disclosure? When?

*** This specification inherits technology from RFC 5170, and we have made
IPR declarations with regards to RFC 5170.  As far as I know, we do not
plan to make any further IPR declarations on this specification.

---

From: Vincent Roca <[email-masked]>
Date: Wed, 17 Oct 2012 16:13:37 +0200

Mike,

> plan to make any further IPR declarations on this specification.

IPR disclosure transitivity is only possible if the conditions of use are
exactly the same as that of the initial document. This is not the case
since we restrict to cases where G==1 and only focus on LDPC-
Staircase codes, and you recognized it.

Additionally  you acknowledged in Oct. 2009 that using G>1 was the
only reason that motivated 10 patents of this IPR disclosure. See:
	http://www.ietf.org/mail-archive/web/rmt/current/msg01358.html

So we have good reasons to believe that an IPR disclosure specific to
this I-D could differ from that of RFC5170.

Do you agree or not? I'd like to understand your point.

Cheers,

    Vincent

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 17 Oct 2012 17:02:20 +0200

Hi Michael,

> the spec is a little less easy to understand, it isn't earth shattering.

Ok, thanks.

> *** I don't understand this comment, as there were no IPR-related comments

This is solely meant for discussion and to get any questions resolved. 
We have had some discussion during the IESG evaluation if IPR declared 
for RFC 5170 is also valid for draft-ietf-fecframe-ldpc. Thus the 
linkage between your email and what has happened in the IESG.

This is not out of a bad intention, but it is more your AD which wanted 
some more clarity on this.

Thank you,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 17 Oct 2012 17:12:26 +0200

Hi Michael and Vincent, all,

On 10/17/2012 03:41 PM, Luby, Michael wrote:
> Vincent, You are welcome.  Responses below. Best, Mike
>
[...]

>>
>>
>> More importantly. Since:
>>
>> 1- you noticed we impose restrictions on the way LDPC-Staircase
>> codes are being used in section 4.1;
>>
>> 2- you certainly remember the discussion we had in 2009 concerning
>> 10 out of the 13 patents mentioned in the RFC5170 IPR disclosure,
>> whose conclusion is here:
>> 3- the present I-D only considers LDPC-Staircase codes whereas
>> RFC5170 defines two FEC schemes;
>>
>> you will probably conclude like us that QC's IPR disclosure for
>> RFC5170 does not necessarily apply to this I-D. Hence our
>> question: does QC intend to do a new IPR disclosure? When?
>
> *** This specification inherits technology from RFC 5170, and we
> have made IPR declarations with regards to RFC 5170.  As far as I
> know, we do not plan to make any further IPR declarations on this
> specification.

My open points are addressed, i.e., my question of the IPR declarations
for RFC 5170 and any potential relationship to draft-ietf-fecframe-ldpc.

I will go forward with draft-ietf-fecframe-ldpc and ship it off to the
RFC editor.

Thank you!

   Martin

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 17 Oct 2012 15:58:47 +0000

Thanks Martin, 
I didn't know there was an open question, but I'm happy to hear that it is
addressed.
Best, Mike