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

[Thomas Stockhammer <[e-mail]>]

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

On Nov 24, 2010, at 4:38 PM, Ali C. Begen (abegen) wrote:

> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Luby, Michael
>> Sent: Tuesday, November 23, 2010 2:10 PM
>> To: [e-mail]
>> 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, "[e-mail]" <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/fecframe

---
Dr. Thomas Stockhammer (CEO) || [e-mail] || phone [phone] || cell [phone] || 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.