Re: draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

Hi Ramakrishna,

I'm reluctant to add significant amounts of new material at this stage since the draft has been stable for some time now. Several people have implemented the code from this specification, so I don't think there is any question that it is not clear enough to be easily implementable. Also, as a general rule, tutorial material should be kept separate from specifications, so perhaps if there is a need for such material it should be somewhere else?

But if there are particular points that you are not as clear as they should be, or deserve additional explanation, then perhaps we could add some small notes to clarify?

A new version addressing the last call comments will be available next week.

Regards,

Mark

Sent from my BlackBerry.

-----Original Message-----
From: <[email protected]>
Date: Thu, 6 Oct 2005 19:56:46 
To:<[email protected]>
Subject: RE: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

Dear authors and all,
 
 >>The specification is intended to rigorously specify the code and you
 >>are right that it does not provide a lot of explanation of why it is the
 >>way it is.
 The current draft is in decent shape. However, it would be good to include more explanation of "why it is the way it is".
 Of course the references provide detailed description of the FEC scheme, but having a simple description in the RFC itself would be good.
 The current draft gives just enough details for the implementers. A simple explanation of the design principles of this FEC scheme (with some block diagrams, matrix equations etc) would make this RFC a great piece of work.
 This RFC is going to describe the first fully specified "real" FEC scheme (though FEC Encoding ID = 0 was fully specified it is still a "dummy" FEC).
 It would be nice to set a good precedent in this RFC that future RFCs describing fully specified FEC schemes can follow.
 We are interested in this work and support this work.
 We would like to know if and when a new version of the current draft (that addresses the comments/concerns expressed so far over the reflector) will be available.
 
 Best Regards,
 Ramakrishna Vedantham
 Nokia Research Center
 
 ----------------------------------------------------------------------
 Nokia                           | Phone +1-972-374-1922
 6000 Connection Dr,           | Fax   +1-972-894-5937
 Irving, TX 75039, USA           | mailto:[email protected]: <mailto:[email protected]> 
 www.nokia.com/openness
 ----------------------------------------------------------------------
 
 
 
 -----Original Message-----
 From: [email protected] [mailto:[email protected]: <mailto:[email protected]> ]On Behalf Of ext
 Mark Watson
 Sent: Wednesday, September 28, 2005 3:59 PM
 To: Vincent Roca; Lorenzo Vicisano; [email protected]
 Subject: RE: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call
 
 
 Vincent & Christophe,
 
 Please see comments below, marked MW:
 
 Regards,
 
 Mark
 
 -----Original Message-----
 From: [email protected] [mailto:[email protected]: <mailto:[email protected]> ] On Behalf Of
 Vincent Roca
 Sent: Wednesday, September 28, 2005 5:32 PM
 To: Lorenzo Vicisano; [email protected]
 Subject: Re: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call
 
 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?
 
 MW: Yes, this is one of the reasons - as well as storing the table in
 implementations. Another is that having this limitation means that we
 can also limit to 65536 symbols in total (source and repair) and this
 keeps the FEC Payload ID small (the FEC Payload ID being an overhead in
 every packet) and assists with optimised implementation. If Kmax were
 larger then the limit of 65536 symbols in total becomes problematic,
 since it places a lower bound on the rates supported.
 
 Tornado, LT and some other LDPC codes require very large numbers of
 symbols to achieve efficient performance. In practice, it is desirable
 to have the freedom to use larger symbols (for computational reasons),
 so the possibility to work efficiently with smaller number of symbols is
 a plus point, because it means symbols can be larger (up to the packet
 size).
 
 Finally, in practice this limitation means that a very large file may
 have to be split into a small number of separate source blocks. Since
 these blocks are themselves still very large, the effect of the "coupon
 collector problem" is actually very small (the variance in the number of
 lost symbols across a few blocks of >8192 symbols will be very small).
 -------------------
 
 *** 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?
 
 MW: Yes, it is intended to be generic. See above for comments on the
 block size limitation. We believe this is the right balance between
 supported block size, the overhead of the FEC Payload ID and the need to
 provide some limitation for implementation practicality (including
 provision of the table of Systematic Indices).
 
 The code is aligned with 3GPP and DVB-H but it is not limited to
 3GPP/DVB-H object sizes and supports objects from kilobytes to
 gigabytes. Note that it's the object size that is relevant, not the
 connection speed - you should not assume that people never want to send
 large objects over slow connections ;-)
 
 
 -------------------
 
 *** 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.
 
 MW: Only the occurance in the "definitions" section is supposed to be a
 definition. I'd prefer not to re-arrange sections, but I can fix the
 discrepancies in nomenclature.
 -------------------
 
 *** 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.
 
 MW: There is no special reason. They could be in an Annex if people
 prefer (but not an Appendix ;-)
 
 *** 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...
 
 MW: Yes, the encoder and decoder must both know these numbers. They
 ensure that the first K symbols of the code are linearly independent and
 thus can be systematic symbols.
 
 The specification is intended to rigourously specify the code and you
 are right that it does not provide a lot of explanation of why it is the
 way it is. I am not sure the formulae are "magic" - they are just the
 way they are because that is what makes the code work!
 
 -------------------
 
 ***__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.
 
 MW: Ok.
 _______________________________________________
 Rmt mailing list
 [email protected]
 https://www1.ietf.org/mailman/listinfo/rmt: <https://www1.ietf.org/mailman/listinfo/rmt> 
 
 _______________________________________________
 Rmt mailing list
 [email protected]
 https://www1.ietf.org/mailman/listinfo/rmt: <https://www1.ietf.org/mailman/listinfo/rmt> 
 
 _______________________________________________
 Rmt mailing list
 [email protected]
 https://www1.ietf.org/mailman/listinfo/rmt: <https://www1.ietf.org/mailman/listinfo/rmt>

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