Re: [Fecframe] Last Call: <draft-ietf-fecframe-rtp-raptor-05.txt> (RTP Payload Format for Raptor FEC) to Proposed Standard

[Thomas Stockhammer <[e-mail]>]

Vincent,

while working on the RTP Raptor draft, I came over this comment.
It seems to be more suitable to add a statement into the FEC scheme draft 
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-06.txt
at the end of section 8.2.2 as follows:

   Note also that the source packet flow processed by the FEC encoder
   MUST have consecutive sequence numbers.  In case the incoming source
   packet flow has a gap in the sequence numbers then implementors
   SHOULD insert an ADU in the source block that complies to the format
   of the source packet flow, but is ignored at the application with
   high probability.  For additional guidelines refer to [RFC6363],
   Section 10.2, paragraph 5.

If this is ok, I would upload a new version of the Raptor FEC schemes with only his change.

Thanks

Thomas

On Nov 4, 2011, at 1:47 PM, Vincent Roca wrote:

> Hello Brian,
> 
> First of all, sorry for the small delay in answering your email.
> 
> I agree, this document shall not duplicate procedures and formats defined in 
> [I-D.ietf-fecframe-raptor]. However what I'm highlighting here is a requirement
> that, if not fulfilled, can make a FECFRAME encoder fail.
> 
> It's quite simple to understand: since this RTP framing prevents the FECFRAME
> encoding instance to change the RTP source packet, all the RTP SN of a given
> source block must be in sequence. No gap is possible since the RTP Raptor
> scheme does not authorize it.
> 
> For most use-cases this is not an issue, as this "no loss before the FECFRAME
> encoding instance" is guaranteed. The only problem is that this REQUIRED
> property (in RFC2119 meaning) is not mentioned in [draft-ietf-fecframe-rtp-raptor-05].
> It seems to me it is not mentioned either in [I-D.ietf-fecframe-raptor] (at least
> not in Section 8.2.4.  "Procedures for RTP source flows" where it should).
> 
> We discussed this topic on the list earlier this year. I've also added a dedicated
> bullet in RFC6363 to discuss it (10.2. "Operational and Management
> Recommendations") with recommendations of what could be done if the
> problem arises. So it's pretty easy to fix, it's just a matter of adding a
> sentence and a pointer to RFC6363... But please, do not leave this key
> requirement implicit.
> 
> Regards,
> 
>  Vincent
> 
> 
> On Oct 25, 2011, at 21:47, Brian E Carpenter wrote:
>> Speaking as the Gen-ART reviewer*, IMHO the normative reference to
>> RFC 6363 (still disguised as draft-ietf-fecframe-framework)
>> seems clear enough:
>> 
>>  Procedures and data formats for the use of Raptor Forward Error
>>  Correction in a FECFRAME context are fully defined in
>>  [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor] and are
>>  not duplicated here.  The procedures of those documents SHALL be
>>  followed in order to generate repair data streams to be carried by
>>  the payload formats defined in this document.
>> 
>> Regards
>>  Brian Carpenter
>> 
>> * http://www.ietf.org/mail-archive/web/gen-art/current/msg06833.html
>> 
>> 
>> 
>> On 2011-10-25 20:27, Vincent Roca wrote:
>>> Hi everybody,
>>> 
>>> I've already mentioned this point in March 18th, this year, in the
>>> FECFrame list.
>>> 
>>> Unless I missed some key sentence, I have the feeling that this
>>> I-D **leaves implicit** the strong requirement that there  must not be any
>>> RTP packet loss (or reordering) before reaching the Fecframe encoder,
>>> i.e. that the RTP Sequence Numbers used to identify  source symbols in
>>> the FEC block are always in sequence.
>>> 
>>> This is a key requirement that MUST be clearly stated rather than
>>> being left implicit.
>>> 
>>> I haven't checked carefully in draft-ietf-fecframe-raptor-05, but sections
>>> 8.2.2. and 8.2.4. in this I-D do not seem to be more explicit on this point.
>>> 
>>> This requirement, that is specific to situations where RTP source packets
>>> are left unchanged, and some solutions to mitigate it, have already been
>>> discussed on the list and guidelines have been added in RFC6363:
>>> 
>>> 10.2. Operational and Management Recommendations
>>> [...]
>>> 5.  Management of Communication Issues before Reaching the Sending
>>>      FECFRAME Instance:
>>> 
>>> Cheers,
>>> 
>>>  Vincent
>>> 
>>> 
>>> On Oct. 20, 2011, 15:47, The IESG wrote:
>>>> The IESG has received a request from the FEC Framework WG (fecframe) to
>>>> consider the following document:
>>>> - 'RTP Payload Format for Raptor FEC'
>>>> <draft-ietf-fecframe-rtp-raptor-05.txt> as a 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
>>>> [e-mail] mailing lists by 2011-11-03. Exceptionally, comments may be
>>>> sent to [e-mail] instead. In either case, please retain the
>>>> beginning of the Subject line to allow automated sorting.
>>>> 
>>>> Abstract
>>>> 
>>>> 
>>>> This document specifies an RTP Payload Format for Forward Error
>>>> Correction repair data produced by the Raptor FEC Schemes.  Raptor
>>>> FEC Schemes are specified for use with the IETF FEC Framework which
>>>> supports transport of repair data over both UDP and RTP.  This
>>>> document specifies the Payload Format which is required for the use
>>>> of RTP to carry Raptor repair flows.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> The file can be obtained via
>>>> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/
>>>> 
>>>> IESG discussion can be tracked via
>>>> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/
>>>> 
>>>> 
>>>> No IPR declarations have been submitted directly on this I-D.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Fecframe mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/fecframe
>>> 
>>> _______________________________________________
>>> Ietf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ietf
>>> 
> 

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