Subject: [Rmt] Raptor I-D changes

From: "Mark Watson" <[email-masked]>
Date: Fri, 4 Nov 2005 20:29:09 -0500

All,

This email summarises, for reference, the changes that have been made to
the Raptor FEC Internet Draft as a result of WGLC comments.

You can also see them in glorious technicolour at
http://tools.ietf.org/wg/rmt/draft-ietf-rmt-bb-fec-raptor-object/draft-i
etf-rmt-bb-fec-raptor-object-03-from-02.diff.html

Technical with 'on the wire' changes: None

Technical, but no 'on the wire' changes:

1) Description of the FEC Object Transmission Information is updated to

align with new terminology in the FEC Building Block. Specifically

explicit definition of "encoded Common FEC Object Transmission

Information" and "encoded Scheme-specific FEC Object Transmission

Information". It's clarified that the Transfer Length must be less that

2^45, due to the limitations on the symbol size, number of symbols per

source block and number of source blocks.

Editorial:

2) The draft title is qualified to "Raptor FEC Scheme for Object

Delivery"

2bis) State more clearly in the introduction that the whole document is
formatted according to the FEC Building Block and uses the terminology
from that document.

3) Section 3: encoding artwork and bit-numbering corrected.

4) Section 3.2.2

Old: in a source blocks to 2^^13 

New: in a source block to 2^^13 

5) Section 3.2.2

Old: limitation below on the number of source blocks

New: limitation on the number of source blocks

6) Section 4.1

Old: The symbol alignment parameter, Al.

New: A symbol alignment parameter, Al.

7) Section 4.1

Old: (CDP) making use the

New:  (CDP) that makes use of the

8) Section 4.1

Old: The raptor encoder supplies the CDP with encoding packet
information.

New: The Raptor encoder supplies the CDP with the following information
for each packet to be sent:

9) Section 4.1

Old: The CDP must communicate this information transparently to the
Raptor decoder.

New: The CDP must communicate this information to the receiver.

10) Section 4.2

Old: This section provides recommendations for the derivation of the
four transport parameters, Al, T, Z and N.

New: This section provides recommendations for the derivation of the
three transport parameters, T, Z and N.

11) Section 4.2

Old: , but that it is possible

New: , but it is possible

12) Section 5.1 removed

13) Section 5.2 definition of 'Systematic Code'

Old: a code in which the source symbols are included as part of the
encoding symbols sent for a source block.

New: a code in which all the source symbols may be included as part of
the encoding symbols sent for a source block.

14) Section 5.3

Old: This document defines the systematic Raptor code encoder.

New: This document specifies the systematic Raptor code encoder.

15) Sub-section 5.4.1.2

Old:  The symbol alignment parameter Al ensures that sub-symbols are

always a multiple of A bytes.

New:  The symbol alignment parameter Al ensures that sub-symbols are

always a multiple of Al bytes.

16) Section 5.4.2

Subsection titles 5.4.2 and 5.4.2.2 have the same names. Merge 5.4.2.1

and 5.4.2.1 into 5.4.2.

17) Sub-section 5.5.1

Old:  This process can be can be realized by a Raptor decoding

process.

New:  This process can be realized by a Raptor decoding process.

18) Section 5

The phrases "source triples" and "source symbol triples" are used

interchangeably. 

At other places the phrase "repair symbol triples" is used.

For consistency, please replace the phrase "source triples" with "source

symbol triples" everywhere.

19) Section 5.5.1

Old:  Each repair symbol group is associated with an Encoding Symbol

ID (ESI) and a number, G, of encoding symbols.

New:  Each repair symbol group is associated with an Encoding Symbol

ID (ESI) and a number, G, of repair symbols.

20) Old:    The ESI is used to generate a triple of three integers, (d,
a,

b) for each repair symbol, again using the Trip[] generator as described

in Section 5.4.2. 

New:  The ESI is used to generate a triple of three integers, (d, a,

b) for each repair symbol, again using the Trip[] generator as described

in Section 5.4.2.2.

21) Section 5.5.2.3

Old:  g[j,k] denote the jth element, j=0, 1, 2, ..., of the

subsequence of

g[i] whose elements have exactly k non-zero bits in their binary

representation.

New: m[k] denote the subsequence of g[.] whose elements have exactly k

non-zero bits in their binary representation.

m[j,k] denote the jth element of the subsequence m[k], where

j=0,1,2,.....

Also replace g[.,.] with m[.,.] in the algorithm below.

22) Section 5.3.

Replace "Principle" with "Principal".

23) Section 5.5.2.4.1.

Old: ...satisfy the K constraints C'[i] = ....

New: insert a new line after K constraints.

24) General: replace "object size" with "transfer length"

Thanks to everyone who provided comments and see you next week!

Regards,

Mark Watson

Digital Fountain

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