Subject: Re: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call

From: Vincent Roca <[email-masked]>
Date: Wed, 12 Oct 2005 17:13:29 +0200

Dear Mark/Mike/Lorenzo,

I have a question related to FEC BB revised (a bit late but...)

Is there any good reason not to include the "n-algorithm" in this
FEC BB framework document? The motivation is the following:

For FEC codes with rate > 0, the decoder usually needs to figure
out the Encoding symbol length value (n) for each source block
(in practice, since only A_large/A_small blocks are considered, this
needs to be done for these two values only).
This information is not carried directly by the FEC OTI or FPI, and
therefore needs to be calculated by both ends.
The method for doing that is fairly simple, but it needs to be made
explicit somewhere (in particular there are several possible choices
when doing double to integer conversions).

You can find the proposed text in section:
5.4  Determining the Number of Encoding Symbols of a Block
of the latest LDPC I-D.

What do you think?

Regards,

  Vincent

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 12 Oct 2005 11:47:20 -0400

Hi Vincent,

Ok.

You are right that it could be clearer in the FEC Building Block that it
is the responsibility of the FEC Scheme to define the blocking
algorithm. The 'common algorithms' are provided as a convenience to be
referenced by FEC Schemes where appropriate. I will try and clarify this
in the draft.

Regards,

Mark

-----Original Message-----
From: Vincent Roca [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2005 5:41 PM
To: Mark Watson
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call

Hello Mark,

The boundary between "common algorithms" and "FEC Scheme specific"
is not so clear when several schemes (but not Raptor of course)
can potentially share the same algorithm...

BTW, I've made a mistake in my text: it deals with the
"Number of Encoding Symbols of a Block" (i.e. n parameter) as
clarified in several places, not the symbol length (which is
already carried in most FEC OTI if not all). Sorry.

Having said that, keeping the text in all FEC schemes that actually
need it is acceptable.

Regards,

  Vincent

> The algorithm for working out the source block structure and symbols
> size is FEC Scheme-specific. We have included a source block structure
> algorithm in the FEC BB just to encourage FEC schemes to use the same
> algorithm where appropriate and I guess we could do the same with the
> algorithm from your draft, but it would not be the case that every FEC
> Scheme would have to use this algorithm. In particular, some FEC
Schemes
> may simply signal the symbol size in the OTI or specify their own
> algorithm
> 
> Since it's not essential and WGLC is over it might be better to leave
> this to FEC Schemes to specify (as yours does).
> 
> Regards,
> 
> Mark
> 
> -----Original Message-----
> From: Vincent Roca [mailto:[email-masked]] 
> Sent: Wednesday, October 12, 2005 5:13 PM
> To: Mark Watson
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call
> 
> Dear Mark/Mike/Lorenzo,
>