Subject: [Fecframe] I-D Action:draft-ietf-fecframe-raptor-03.txt

From: [email-masked]
Date: Mon, 22 Nov 2010 23:30:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the FEC Framework Working Group of the IETF.

	Title           : Raptor FEC Schemes for FECFRAME
	Author(s)       : M. Watson, T. Stockhammer
	Filename        : draft-ietf-fecframe-raptor-03.txt
	Pages           : 21
	Date            : 2010-11-22

This document describes Fully-Specified Forward Error Correction
(FEC) Schemes for the Raptor and RaptorQ codes and their application
to reliable delivery of media streams in the context of FEC
Framework.  The Raptor and RaptorQ codes are systematic codes, where
a number of repair symbols are generated from a set of source symbols
and sent in one or more repair flows in addition to the source
symbols that are sent to the receiver(s) within a source flow.  The
Raptor and RaptorQ codes offer close to optimal protection against
arbitrary packet losses at a low computational complexity.  Six FEC
Schemes are defined, two for protection of arbitrary packet flows,
two that are optimised for small source blocks and another two for
protection of a single flow that already contains a sequence number.
Repair data may be sent over arbitrary datagram transport (e.g.  UDP)
or using RTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Luby, Michael" <[email-masked]>
Date: Tue, 23 Nov 2010 11:09:56 -0800

Some comments on draft-ietf-fecframe-raptor-03.txt below.

General nits:

(1) Change "signalled" to "signaled"
(2) Change "modelled" to "modeled"
(3) Change "arbitary" to "arbitrary"
(4) Change "thepadding" to "the padding"
(5) Change "handware" to "hardware"

Particulars:

(6) Section 6.3.2 refers to Section 6.4 for the definition of I_repair: it
vaguely says that

The ESI value placed into a repair
   packet is given by the following formula:

  "ESI_repair = I_repair + SBL,

   where I_repair is the index of the repair symbol in the sequence of
   repair symbols generated according to Section 6.4, where the first
   repair symbol has index 0, the second index 1 etc. and SBL is the
   Source Block Length."

If you look at Section 6.4, it just says that you shall use the Raptor in
IETF RFC 5053 or the RaptorQ in the draft specification.  But, if you look
into either Raptor or RaptorQ, you will see that the indexing of the repair
symbols starts at K, where K is the SBL, and thus you need to reinterpret to
understand the ESI K in the Raptor or RaptorQ specification corresponds to
I_repair = 0, and then use this in the above, which gives you back exactly
the same ESI as would have been specified by Raptor or RaptorQ.  This whole
thing is overly confusing, and I think it would be better to just replace
the above with:

"The ESI value placed into a repair packet is calculated as specified in
Section 5.3.2 of [RFC5053] when [RFC5053] is used and as specified in
Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] when
[I-D.ietf-rmt-bb-fec-raptorq] is used, where K=SBL."

(7) Section 7.1, the second bullet point here is pretty confusing.  Suggest
changing it from:

"A restricted set of possible source block sizes is specified.
      This allows explicit operation sequences for encoding the
      restricted set of block sizes to be pre-calculated and embedded in
      software or handware."

To:
"The possible choices of the source block size for a stream is restricted to
a small specified set of sizes.  This allows explicit operation sequences
for encoding and decoding the restricted set of source block sizes to be
pre-calculated and embedded in software or hardware."

(8) Section 7.3.2, similar comment to (6) above.  Suggest rewording:

"The ESI value placed into a repair
   packet is given by the following formula:

   ESI_repair = I_repair + MSBL

   Where I_repair is the index of the repair symbol in the sequence of
   repair symbols generated according to Section 6.4, where the first
   repair symbol has index 0, the second index 1 etc. and MSBL is the
   Maximum Source Block Length signalled in the FEC Scheme Specific
   Information.  The Source Block Length field of the Repair FEC Payload
   ID field SHALL be set to the number of symbols included in the Source
   Packet Information of packets associated with the source block."

To:

"The ESI value placed into a repair packet is calculated as X + MSBL - SBL,
where X would be the ESI value of the repair packet if the ESI were
calculated as specified in Section 5.3.2 of [RFC5053] when [RFC5053] is used
and as specified in Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] when
[I-D.ietf-rmt-bb-fec-raptorq] is used, where K=SBL. The value of SBL SHALL
be at most the value of MSBL."

(9) Section 8.1.3:  The text for the second set of formats is a copy of the
first set and should be changed.  Specifically, The ESI in the second set of
formats should be specified as 24 bits, not 16 bits, and the ESI text should
be listed third, not second (to match the order of the parameters in Fig.
7).

Mike

---

From: Thomas Stockhammer <[email-masked]>
Date: Thu, 25 Nov 2010 20:49:27 +0100

Mike,

thanks! I will integrate all your suggestions in a revised version. Before posting a revision, I will await any additional comments received by Fri, Dec 3rd.

Thomas

On Nov 23, 2010, at 8:09 PM, Luby, Michael wrote:

> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

---
Dr. Thomas Stockhammer (CEO) || [email-masked] || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.