RE: draft-ietf-rmt-fec-bb-revised-01 WG Last-Call

Hi 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 protected]] 
Sent: Wednesday, October 12, 2005 5:13 PM
To: Mark Watson
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call

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