Subject: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

From: Lorenzo Vicisano <[email-masked]>
Date: Sun, 11 Sep 2005 23:33:44 -0700

Please be advised that this email starts RMT working group
last-call for draft-ietf-rmt-bb-fec-raptor-object-02.

Please provide your comments by Monday September 26th, if any.

	thank you,
	Lorenzo Vicisano

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

---

From: Vincent Roca <[email-masked]>
Date: Wed, 28 Sep 2005 17:31:42 +0200

Dear authors and al.

Please find below a few comments for
draft-ietf-rmt-bb-fec-raptor-object-02.txt

   Vincent and Christoph

-------------------

This Raptor scheme requires that block size be less or equal to Kmax=8192
source symbols. This is relatively small, which is confirmed by  RFC3453
that says, section 2.4:
   Like Tornado codes, the number of source symbols k may be very
   large for LT codes, i.e., on the order of tens to hundreds of
   thousands [...]
Hence the question:

*** comment 1: is this a fundamental limitation or only a practical
    one? For instance, I see that section 5.8 provides an exhaustive list
    of possible values for K between 4 and 8192, so I can understand that
    providing a larger table would quickly become tedious. Is that one
    of the reasons for this limitation?

-------------------

*** comment 2: is Raptor FEC Enc ID 1 generic or not?

More precisely, is the present FEC scheme sufficiently generic to
be used in many different target environments (e.g. over high speed
Internet connections) or is it specialized for the 3GPP/DVB-H
use cases? I think it has been said that the IETF and 3GPP specifications
were aligned, but correct me if I'm wrong. The 8192 limitation for
Kmax, which might be appropriate in 3GPP/DVB-H use cases (here also
correct me if I'm wrong), is suboptimal for a general purpose FEC codec
when dealing with large object, since it opens the door to this good
old ``coupon collector problem'' that large block/expandable codes
were supposed to solve. Can you clarify please?

And the corrolary: if ever it is a carefully tailored FEC scheme
for a specific use case, do you plan to submit another Raptor FEC
scheme?

-------------------

*** comment 3: definitions/symbols/abbreviations

Definitions, symbols and abbreviations only appear in section 5.2,
after they have been heavily used and even re-defined earlier.
A few pathological examples of bad re-definitions are:

Section 4.1.
      - The transfer length of the object, F, in bytes
Then in section 4.2., same page:
      - F the object size, in bytes
Finally, section 5.2.2:
   F    the object size, for object delivery, in bytes

or:

Section 4.1:
      - A symbol alignment parameter (Al)
Then in section 4.2:
      - Al the symbol alignment factor, in bytes
Finally, section 5.2.2:
   Al   denotes a symbol alignment parameter.  Symbol and sub-symbol
        sizes are restricted to be multiples of Al.

I see no reason for delaying these definitions, which makes both
understanding difficult and creates duplicated, non coherent,
pre-definitions. I suggest to move section 5.2 before section 3.

-------------------

*** comment 4:
What is the motivation for including 13 full pages of numbers in
the main part of the document rather than having them defined in
an Annex, in section 5.8? The same is true for section 5.7.1.

*** comment 5:
By the way, for my personnal understanding, do the coder and
decoder need to memorize the 8192 - 4 systematic indices values
or not? A carreful reading of the document would certainly help
answering this question, but since the explanations are sometimes
really scarce (in particular in sections 5.5.4 where there are
many ``magic formulas''), I cannot easily answer...

-------------------

*** __Minor__ remark for figure p7

    3         2         1
   10987654321098765432109876543210
   +--------------+-------+-------+
   |      Z       |   N   |   Al  |
   +--------------+-------+-------+

This kind of graphic which shows bit alignment fields requires to
have some space between the bits, so that the separation between the
Al, N fields can be shown as taking place between bits 7 and 8,
rather than exactly at bit 8 (before or after?). In the present case,
common sense enables to easily answer, but adding "+" between each
"-" is preferable anyway.