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

[Vincent Roca <vincent.roca at inrialpes.fr>]

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:vincent.roca at inrialpes.fr] 
> Sent: Wednesday, October 12, 2005 5:13 PM
> To: Mark Watson
> Cc: luby at digitalfountain.com; lorenzo at cisco.com; rmt at ietf.org
> 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

_______________________________________________
Rmt mailing list
Rmt at ietf.org
https://www1.ietf.org/mailman/listinfo/rmt