Re: [Fecframe] WGLC draft-ietf-fecframe-ldpc-00

Vincent Roca <vincent.roca@inria.fr> Tue, 29 November 2011 13:35 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: fecframe@ietfa.amsl.com
Delivered-To: fecframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B392D21F8C2B for <fecframe@ietfa.amsl.com>; Tue, 29 Nov 2011 05:35:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.249
X-Spam-Level:
X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBw0dGDIZpgZ for <fecframe@ietfa.amsl.com>; Tue, 29 Nov 2011 05:35:53 -0800 (PST)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id E230521F8C1F for <fecframe@ietf.org>; Tue, 29 Nov 2011 05:35:51 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.69,591,1315173600"; d="scan'208";a="133157237"
Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.0.10]) ([82.236.155.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 29 Nov 2011 14:35:50 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5410650BB5@xmb-sjc-215.amer.cisco.com>
Date: Tue, 29 Nov 2011 14:35:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <398D928C-5B44-427A-9969-0C31D702CBBF@inria.fr>
References: <CABFReBrZ7dzFJazyUdbZpv4_=rZawM3woicGRnRHJ+mO+EHiPw@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5410650BB5@xmb-sjc-215.amer.cisco.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Martin Ellis <martin.ellis@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: fecframe@ietf.org
Subject: Re: [Fecframe] WGLC draft-ietf-fecframe-ldpc-00
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2011 13:35:53 -0000

Hello everybody,

Thanks a lot Ali and Martin for your reviews of this draft as well as the RS draft.
I'm doing a common response since we did our best to keep both documents as close
to one another as possible.

From Ali:

> - Section 3.1: Again why not refer to 6363 for all definitions and use the exact wording from 6363. Alternatively, just remove the text and simply refer to 6363.

We've aligned the definitions with RFC6363. That's a good point.
We've kept a few additional sentences here and there when there is
something specific to the LDPC (resp. RS) FEC Scheme.
We've also kept a definition that is not in RFC6363, namely 
"ADU Block", which we differentiate from the "source block".

It depends on the point of view in fact:
- FECFRAME instance => ADU block
- FEC Scheme => source block

If we go into the details, the source block is composed of symbols
created from the ADUIs, not the ADUs. There are a few additional
bytes considered during the encoding process.

> - Figure 1 should be identical to figure 2 in 6363.

Done.

> - Remove the spaces in the fssi example.

Good catch!

> - SDP elements draft is now 6364.-

Corrected.

From Martin:

> The last 2 paragraphs of section 4.2 discuss a max_rt parameter, 
> which restricts the ADU block size for the real-time constraints of a
> particular application. Would it be appropriate to give an example
> here? (this also applies to the simple-rs draft).

We've added an example as suggested.
We've also improved the full section 4.2 for better clarity.

> - In section 7.1, some specific numbers are given on levels of 
> overhead required to reduce residual loss rates. Are these results
> based on the [Matsuzono10] reference? If so, I think it would be
> better to say so explicitly (and briefly mention the assumptions made
> in that study; i.e., uniform random packet loss).

As said before, these results come from an evaluation of the LDPC
codes, using a dedicated simulator. However they give an idea of
what performance (in terms of erasure recovery) can be expected
for real use-cases if these codes are correctly used. 
We've added "independently of FECFRAME" before introducing the
results, which we hope will be sufficient to clarify the point.

Thanks!

Greg, unless new reviews are expected, we think both I-Ds are
ready.

Regards,

   Vincent, on behalf of the authors