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

[Vincent Roca <[e-mail]>]

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