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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 24 Nov 2010 07:38:54 -0800

In addition, please use proper capitalization for the frequently used terms like "Repair packet", "Payload ID", etc.

Also you might wanna remove the definitions and acronyms from your draft, and simply refer to:
https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/

to stay consistent (there is still a slight change the text could be modified in the framework draft). Or, please make sure that the text will be updated before the RFC publication.

In the SDP example, there are some typos. I am only copying the lines that need to be fixed:

        a=group:FEC-FR S1 R1 (Update the a=group line in the second paragraph of section 10 as well)
        ...
        m=application 30000 UDP/FEC
        ...
        a=fec-repair-flow: encoding-id=0; fssi=Kmax:8192,T:128,P:A
        a=repair-window:200ms

In the repair-flow line, you are using 0 for the encoding-id. But, that is now what is registered for a particular FEC scheme you are defining here. 0 is special and should probably be reserved (I will put that note in the next framework revision).

Actually, in Section 12.1, instead of saying XXX, you should put numbers starting from 1. So that IANA knows what to register. Once you do that, update the repair-flow line in the SDP to reflect the proper fec scheme for your example.

Update the reference 4756bis to RFC 5956.

You are missing the informative references section. From what I can tell, there are a few references that are informative - not normative. You should fix this.

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Luby, Michael
> Sent: Tuesday, November 23, 2010 2:10 PM
> To: [email-masked]
> Subject: [Fecframe] Comments on: I-D Action:draft-ietf-fecframe-raptor-03.txt
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 11/22/10 11:30 PM, "[email-masked]" <[email-masked]>
> wrote:
> 
> > 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.
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

---

From: Thomas Stockhammer <[email-masked]>
Date: Fri, 26 Nov 2010 00:15:26 +0100

Ali,

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

>>> implementation to automatically retrieve the ASCII version of the

---
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.