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

From: Lorenzo Vicisano <[email-masked]>
Date: Tue, 4 Oct 2005 10:19:06 -0700

Rod,

I just noticed that I missed to comment on this, please see inline.

On Mon, Sep 26, 2005 at 09:56:19AM +0300, [email-masked] wrote:
> So to clarify: is 3452 wrong about the RFC, so that IETF (currently RMT)
> consensus is enough? (And, what is the mechanism for documenting the
> consensus in case of arguments after a race condition?

not quite: the "RFC required" in 3452 is correct, however 3452 should
say "IETF Consensus" [which essentially means RFC required] and not
"Specification Required" [which means something else], please check
RFC 2434. .. confusing I know.. 

> 
> (Note, doing the RFC is definitely a useful thing in anycase).
> 
> Since the Raptor I-D exists, and the I-D has had email and meeting
> discussion - whereas the "oma null fec" has not yet been presented in
> the IEFT - I think it makes sense to rapidly form an RMT consensus that
> 1 holds for Raptor (reserved until IANA assignment or RMT decision not
> to assign Raptor - which doesn't make sense and I can not imagine
> happening). Anyone not support this?
> 
> Since the IETF doesn't normally do the liaison statement stuff, it's
> really individual responsibility to communicate to OMA-BCAST (and
> anywhere else) that a request to temporarily hold an ID number would
> need to be made to RMT if IANA race conditions are to be avoided. (Short
> of receiving tens of such requests, I guess this scales).
> 
> In the meantime, we're also aware of triangle and staircase codes so
> maybe there are 4 new fully specified numbers on the radar. (Vincent -
> fully specified or underspecified?)
> 
> And finally, this raises an interesting question of reuse of RMT work
> outside the IETF (especially outside the IETF culture). It seems to make
> sense to allocate an "experimental fec id" (probably one fully
> specified, one underspecified) so new work doesn't need to go
> underground when implementations are tested before IANA allocation. This
> way the actual code allocation is not rushed while the code is still
> under work. This should also make it clearer that codes which have not
> been IANA registered yet should not be the basis of non-IANA decisions.
> (127 and 255 "feel right" for such use). Opinions?

I'm not sure I like this: it is confusing to allocate
fully-specified IDs without a ietf spec.. if the organizations that
specify these schemes are interested in IETF compliance and the
interoperability implications that come with it, I don't see
any reason why they shouldn't come to the IETF and move their work
through the WG. If they are not, they might as well allocate their own
(conficting) ids.

	thanks,
	Lorenzo

> 
> Cheers, Rod.
> 
> 
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On 
> >Behalf Of ext Lorenzo Vicisano
> >Sent: 21 September, 2005 08:21
> >To: Michael Luby
> >Cc: Vedantham Ramakrishna (Nokia-NRC/Dallas); Paila Toni 
> >(Nokia-M/Espoo); [email-masked]
> >Subject: Re: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call
> >
> >All,
> >
> >RFC 3452 is clear about the assignmet of FEC Enc IDs:
> >
> >"  An IETF RFC MUST exist and specify the FEC Payload ID fields and
> >   formats as well as the FEC Object Transmission Information for the
> >   value of "ietf:rmt:fec:encoding" (FEC Encoding ID) being assigned
> >   by IANA.. "
> >
> >Unfortunatly RFC 3452 is incorrect in citing "Specification 
> >Required" from RFC 2434, it should say "IETF Consensus" [this 
> >got corrected in the current draft]
> >
> >.. nevertheless the intention of RFC 3452 is very clear, both 
> >from the verse above and the rest of the specification.
> >
> >This process allow for race conditions, and IANA is supposed 
> >to detect/solve conficts. Note that currently race conditions 
> >are unlikely, given that RMT is the only place in the IETF 
> >where FEC IDs are specificed [this migth change in the future].
> >
> >On the specifics of Raptor vs OMA: technically Raptor hasn't 
> >grabbed anything until it becomes an RFC and its ID is 
> >registered with IANA.
> >.. on the other side there is not any other fully specified ID 
> >being worked on in our WG [apart from 0], so there are no 
> >conflicts yet.
> >
> >If we start working on another fully specified scheme, I hope 
> >that we will avoid conflicts even if raptor hasn't become an RFC yet ..
> >
> >Note that this last part of RMT trying to do comflict 
> >avoidance is just my opinion .. seems common sense 'though.
> >
> >	Lorenzo
> >
> >On Tue, Sep 20, 2005 at 04:36:18PM -0700, Michael Luby wrote:
> >> Wow, that's amazing!  Didn't anybody at OMA read the FEC building 
> >> block before trying to hand out FEC Encoding IDs?  Perhaps the OMA 
> >> numbering space is completely different than the IETF FEC 
> >Encoding ID 
> >> space?  Anyway, as is clearly stated in the FEC building block 
> >> (RFC3452, and also in the new FEC building block that is in IETF RMT 
> >> wglc), the ONLY way to get an FEC Encoding ID is to have an 
> >IETF RFC, 
> >> and clearly OMA didn't do that, and the Raptor specification is in 
> >> IETF RMT wglc with FEC Encoding ID 1 specified, so I guess that 
> >> answers who is ahead and following the established procedures.
> >> 
> >> Thanks for pointing this out, Ramakrishna (and Naveen).
> >> Best, Mike
> >> 
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On 
> >Behalf Of 
> >> [email-masked]
> >> Sent: Tuesday, September 20, 2005 4:21 PM
> >> To: [email-masked]; [email-masked]
> >> Cc: [email-masked]
> >> Subject: RE: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG 
> >Last Call
> >> 
> >> Hi,
> >> 
> >> Has the FEC Encoding ID = 1 been already reserved for Raptor FEC?
> >> 
> >> The latest version of OMA BCAST SG
> >> 
> >http://member.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Pe
> >> rmanen t_documents/OMA-TS-BCAST_ServiceGuide-V1_0_0-20050910-D.zip
> >> defines another null-FEC scheme with FEC Encoding ID = 1. 
> >This has to 
> >> be registered with IANA by the proponents.
> >> 
> >> But it is not clear who is ahead of the race to IANA, IETF 
> >RMT or OMA BCAST.
> >> 
> >> Would you please clarify this issue?
> >> 
> >> (Thanks to Naveen of Qualcomm to point this out after the last SA4 
> >> meeting.)
> >> 
> >> Regards,
> >> Ramakrishna Vedantham.
> >> 
> >> 
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]On Behalf Of 
> >> ext Lorenzo Vicisano
> >> Sent: Tuesday, September 13, 2005 6:54 PM
> >> To: Michael Luby
> >> Cc: Walsh Rod (Nokia-NRC/Tampere); [email-masked]
> >> Subject: Re: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG 
> >Last Call
> >> 
> >> 
> >> Mike,
> >> 
> >> the two WGLCs are overlapped: both drafts are in right now and 
> >> feedback is welcome for both of them, we jsut moved the deadline for 
> >> Raptor by one week.
> >> 
> >> Considering the normal IETF times, this is unlikely to have 
> >an impact 
> >> in the date of publication of the RFC.
> >> 
> >> > wglc back by a week, and there are some good reasons why 
> >it would be 
> >> > good
> >> to
> >> > have the FEC bb and the Raptor wglcs finished by the end 
> >of the week 
> >> > of September 26.  I've never seen another IETF wg that 
> >tried to keep 
> >> > the
> >> wglcs
> >> 
> >> please state the reasons.
> >> 
> >> Note that this is a fairly informal process: if needed we can delay 
> >> asking the IESG to review the FEC BB.. in case something comes up to 
> >> require another WGLC. Also note that other FEC IDs are behind and 
> >> still have to enter WGLC.
> >> 
> >> 	thanks,
> >> 	Lorenzo
> >> 
> >> 
> >> 
> >> On Tue, Sep 13, 2005 at 04:24:27PM -0700, Michael Luby wrote:
> >> > All,
> >> > I don't understand this.  Rod admittedly is going to do his wglc 
> >> > review at the last minute on the last day, and for this the Raptor 
> >> > wglc is pushed
> >> back
> >> > a week?  I don't understand why this is a reasonable argument to 
> >> > push the non-overlapped, and if I remember correctly the 
> >first time 
> >> > around the FEC bb, the LCT bb and the ALC pi were all in wglc at 
> >> > exactly the same time
> >> and
> >> > all finished wglc at exactly the same time within the RMT wg.
> >> > Mike
> >> > 
> >> > > -----Original Message-----
> >> > > From: [email-masked] 
> >[mailto:[email-masked]]On Behalf 
> >> > > Of Lorenzo Vicisano
> >> > > Sent: Tuesday, September 13, 2005 11:31 AM
> >> > > To: [email-masked]
> >> > > Cc: [email-masked]
> >> > > Subject: Re: [Rmt] 
> >draft-ietf-rmt-bb-fec-raptor-object-02 WG Last 
> >> > > Call
> >> > >
> >> > >
> >> > > Rod,
> >> > >
> >> > > this is reasonable: let's make October 3rd the feedback deadline 
> >> > > for draft-ietf-rmt-bb-fec-raptor-object-02.
> >> > >
> >> > > 	thanks,
> >> > > 	Lorenzo
> >> > >
> >> > > On Tue, Sep 13, 2005 at 04:53:04PM +0300, 
> >[email-masked] wrote:
> >> > > > Hi Lorenzo et al.
> >> > > >
> >> > > > Is there any chance of shifting the raptor date back 
> >one week so 
> >> > > > we don't have to do two reviews at the last minute on 
> >the same day?
> >> > > >
> >> > > > (Yes I feel ashamed for openly admitting to leaving reviews to 
> >> > > > the
> >> last
> >> > > > minute - I know I'm not the only one though :)
> >> > > >
> >> > > > Cheers, Rod.
> >> > > >
> >> > > >
> >> > > >
> >> > > > >-----Original Message-----
> >> > > > >From: [email-masked] [mailto:[email-masked]] On 
> >> > > > >Behalf Of ext Lorenzo Vicisano
> >> > > > >Sent: 12 September, 2005 09:34
> >> > > > >To: [email-masked]
> >> > > > >Subject: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last 
> >> > > > >Call
> >> > > > >
> >> > > > >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
> >> > > > >
> >> > >
> >> > > _______________________________________________
> >> > > Rmt mailing list
> >> > > [email-masked]
> >> > > https://www1.ietf.org/mailman/listinfo/rmt
> >> > >
> >> 
> >> _______________________________________________
> >> Rmt mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/rmt
> >> 
> >> _______________________________________________
> >> Rmt mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/rmt
> >
> >_______________________________________________
> >Rmt mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/rmt
> >
> 
> _______________________________________________
> Rmt mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rmt

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

---

From: [email-masked]
Date: Thu, 6 Oct 2005 18:51:43 -0500

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-masked]
www.nokia.com/openness
----------------------------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Mark Watson
Sent: Wednesday, September 28, 2005 3:59 PM
To: Vincent Roca; Lorenzo Vicisano; [email-masked]
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-masked] [mailto:[email-masked]] On Behalf Of
Vincent Roca
Sent: Wednesday, September 28, 2005 5:32 PM
To: Lorenzo Vicisano; [email-masked]
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.