|
Re: [Fecframe] Last Call: <draft-ietf-fecframe-simple-rs-04.txt> (Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME) to Proposed Standard
2012-11-06 11:27:19
Vincent,
Thanks, I think this will help the document.
Mike
On 11/6/12 4:38 PM, "Vincent Roca" <vincent(_dot_)roca(_at_)inria(_dot_)fr>
wrote:
Mike,
Thanks for your comments. It seems your email didn't show up in the
fecframe
list (it's not in the mailing list archive either) which explains why we
didn't answer
so far.
Concerning (1), you're right and here is the way we address it both in the
introduction and section 5.3.
** Introduction:
OLD:
More specifically, the [RFC5510] document introduced such Reed-
Solomon codes and several associated FEC schemes that are compatible
with the [RFC5052] framework. The present document inherits from
[RFC5510] the specification of the core Reed-Solomon codes based on
Vandermonde matrices, and specifies a simple FEC scheme that is
compatible with the FECFRAME framework [RFC6363]. Therefore this
document specifies only the information specific to the FECFRAME
context and refers to [RFC5510] for the core specifications of the
codes. To that purpose, the present document introduces:
o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that
specifies a simple way of using of Reed-Solomon codes over
GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for
arbitrary packet flows;
NEW:
More specifically, the [RFC5510] document introduced such Reed-
Solomon codes and several associated FEC schemes that are compatible
with the [RFC5052] framework. The present document inherits from
[RFC5510], Section 8 "Reed-Solomon Codes Specification for the
Erasure Channel", the specifications of the core Reed-Solomon codes
based on Vandermonde matrices, and specifies a simple FEC scheme that
is compatible with the FECFRAME framework [RFC6363]:
o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that
specifies a simple way of using of Reed-Solomon codes over
GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for
arbitrary packet flows;
Therefore sections 4, 5, 6 and 7 of [RFC5510], that define [RFC5052]
specific Formats and Procedures, are not considered and are replaced
by FECFRAME specific Formats and Procedures.
** Section 5.3:
OLD:
The present document inherits from [RFC5510] the specification of the
core Reed-Solomon codes based on Vandermonde matrices for a packet
transmission channel.
NEW:
The present document inherits from [RFC5510], Section 8 "Reed-Solomon
Codes Specification for the Erasure Channel", the specifications of
the core Reed-Solomon codes based on Vandermonde matrices.
As soon as possible, I'll update the LDPC document as well, unlike
what I said previously, in the same manner. Saying that all the Formats
and Procedures of RFC5170 are replaced by FECFRAME variants
can clarify a little bit the document.
Concerning (2), same answer than for the LDPC document (it's not
an exhaustive list).
Cheers,
Vincent, on behalf of the authors
---
€ From: "Luby, Michael" <luby at qti.qualcomm.com>
€ To: "ietf at ietf.org" <ietf at ietf.org>
€ Cc: "Luby, Michael" <luby at qti.qualcomm.com>, "fecframe at ietf.org"
<fecframe at ietf.org>
€ Date: Thu, 11 Oct 2012 17:30:31 +0000
€ In-reply-to: <20121008141129.10923.33854.idtracker at ietfa.amsl.com>
Some quick comments.
(1) This proposal relies upon parts of RFC 5510 for the definition of the
underlying Reed-Solomon code. However, it isn't completely explicit in
this proposal about what exact parts/sections of RFC 5510 are to be used
in this proposal and how. It would seem that explicit references to the
particular sections of RFC 5510 that are being used, and exactly how these
parts of RFC 5510 are being inherited and used, would be useful (probably
necessary).
(2) This proposal references RFC 5170 and RFC 5053, and makes some
comparisons. However, there is also RFC 6330 that is relevant and is not
mentioned or referenced in this proposal. It would seem appropriate to do
so.
Thanks, Mike
On Oct 8, 2012, 16:11, The IESG wrote:
The IESG has received a request from the FEC Framework WG (fecframe) to
consider the following document:
- 'Simple Reed-Solomon Forward Error Correction (FEC) Scheme for
FECFRAME'
<draft-ietf-fecframe-simple-rs-04.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2012-10-22. Exceptionally,
comments may
be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document describes a fully-specified simple FEC scheme for Reed-
Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to
protect arbitrary media streams along the lines defined by the
FECFRAME framework. Reed-Solomon codes belong to the class of
Maximum Distance Separable (MDS) codes which means they offer optimal
protection against packet erasures. They are also systematic codes,
which means that the source symbols are part of the encoding symbols.
The price to pay is a limit on the maximum source block size, on the
maximum number of encoding symbols, and a computational complexity
higher than that of LDPC codes for instance.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
Fecframe mailing list
Fecframe(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/fecframe
|
|