Re: Announcing draft-ietf-rmt-bb-fec-raptorq-03

Dear RMT experts,

Resend of the previous e-mail with appropriate subject.

My name is Habeeb Mohiuddin Mohammed, a MSCE Student at the Munich
University of Technology. In my internship project I implemented the RaptorQ
encoder and decoder as specified in draft-ietf-rmt-bb-fec-raptorq-02. The
draft easily enabled implementation of the algorithms and protocols.
Nevertheless, during the implementation I detected some ambiguities.
Therefore, I contacted the authors of the draft to clarify those, in
particular the use and implementation of GF(256) operations.

It turned out that the specification was correct and only some
misunderstandings from my side. However, the authors were kind enough to
address the ambiguities and provide me an updated specification and also
integrated the clarification in latest draft
draft-ietf-rmt-bb-fec-raptorq-03.

We also agreed to exchange some test vectors for certain source block sizes
that contain mixtures of source and encoding symbols. All exchanged vectors
could be decoded by the other party, so we are confident to be able to claim
to have two independent implementations of the RaptorQ forward error
correction specification as documented in draft-ietf-rmt-bb-fec-raptorq-03.

Therefore, I support that WGLC is issued for this specification.

Best regards,

Habeeb Mohiuddin Mohammed,
Graduate Student, Master in Science of Communication Eng.,
Dept. of Electrical and Information Technology,
Technische Universität München,
Arcisstraße 21, D-80290 Munich,
Germany.
Email: [email protected]



On Jun 22, 2010, at 11:37 PM, Luby, Michael wrote:

RMT participants,
We have just submitted a new -03 version of “RaptorQ Forward Error
Correction Scheme for Object Delivery”.   There are no basic technical
changes to the actual RaptorQ code (a minor technical change is noted
below).  The main change between the –02 and –03 drafts is that there was an
effort to remove some of the ambiguities in the –02 draft and to make it
much easier to implement (this was based on feedback from a couple of people
who have implemented from the draft).  For example, we removed all the
mathematical discussions of GF(256), and removed introduction of complicated
mathematical operations in the middle of the draft, and isolated to Section
5.7 all symbol operations relating to GF(256), where we also describe the
symbol operations solely as table lookup operations instead of trying to
explain finite fields. (We do mention GF(256) in Section 5.7, but it is not
necessary to understand the theory of GF(256) finite field operations to
implement the draft.)  We also did some other cleanups as well, e.g.,
eliminated a few places where we described the same thing more than once,
and maintained and cleaned up the better of multiple descriptions that
provided the most straightforward way to implement.  We also isolated the
requirements for a compliant decoder to a new Subsection 5.8.  We feel that
these changes will help future implementers, and will also make the WGLC
faster and more efficient.

The minor technical change was that we did change J(K’) values for a couple
of K’ values in Table 2.  We anticipate computing and validating new J(K’)
values for a few other K’ values, and these will be updated along with any
WGLC comments after WGLC has been completed  (these updates have no impact
on the WGLC review of the draft, as from that perspective they are just
values in a table, and will be available before the WGLC is completed).   We
feel that this draft is now ready for WGLC.
Regards, Mike Luby
_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt

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