Subject: Re: [Fecframe] WG Last Call - Framework

From: "Watson, Mark" <[email-masked]>
Date: Fri, 5 Mar 2010 15:05:15 -0800

Orly,

Thanks for your detailed comments. My responses are below. An -06 draft will be available shortly.

...Mark

On Jan 19, 2010, at 11:28 PM, Orly Peck wrote:

> Hi,
> Following are my comments for draft-ietf-fecframe-framework-05:
> 
> 1) On page 11, last sentence: "a repair packet carried over RTP starts with an RTP header of its own which is immediately followed by parity data..." - what about a FEC header that follows the RTP header?

Good point. I will replace "immediately followed by" with "followed (after the Repair Payload ID) by"

> 
> 2) on page 14 - "a CDP specification MUST define how a receiver determines the length of time it should wait to receive FEC repair packets for any given source blocks". 
> Sometimes only the receiver knows how much time it can wait for a FEC repair packet due to latency considerations or any other consideration the receiving application may take into account. IMHO the sender can define a MINIMUM time that the sender should wait for the repair packet.

Agreed. If we say "...how a receiver determines a minimum length of time ..." does that address the issue ? 

> 
> 3) typo - on page 22 section 6.2 - "For each sApplication Data Units..." - remove "s".

Ok.

> 
> 4) same paragraph -  I think that the FEC scheme should (optionally) receive the information of the index of the ADU in the source block (this is important for FEC codes where order is significant).
> 

Agreed. I re-worded the sentence before the bullet list as "Each Source Block provided to the FEC scheme consists of an ordered sequence of Application Data Units where the following information is provided for each ADU: " This way the FEC Scheme gets the ordering but we do not have to define any kind of specific index.

> 5) page 23 - IMHO it should be mentioned that using the Explicit Source FEC Payload ID is not backward compatible with non-FEC support receivers, and therefore is a disadvantage. I think it should be recommended that if there is a way to avoid using the Explicit Source FEC Payload ID appended to the end of the source packet, then it should be avoided.
> 

I agree this should be mentioned, but I am not sure we can make a recommendation at the level of the Framework. Backwards compatibility considerations are highly application and even deployment-specific. Even where a well-known existing protocol is being enhanced with FEC there may not be any equipment deployed in the target environment supporting the existing protocol and so then backwards compatibility in that case is not a consideration. Existing protocols may also have other compatibility mechanisms (e.g. negotiation) which mean the Explicit Source FEC Payload ID could be used without breaking backwards compatibility. What I suggest to add is just the following:

"In many applications, support for Forward Error Correction is added to a pre-existing protocol and in this case use of the Explicit Source FEC Payload ID may break backwards compatibility, since source packets are modified."

This raises the issue in a suitably innocuous way and lets the reader decide how important this point is to them.

> 6) typo - page 24, section 6.3.1, second paragraph - "construction source packets within a gioven source block...." - gioven=given.

Ok.

> 
> 7) typo - same paragraph - "values in the sequence nmber space..." nmber=number.

Ok

> 
> 8) page 25, section 6.5, third paragraph - "...provides FEC protection for all packets of the specified set of Source Data Flows..." - I am not sure I understand this sentence. Sometimes not all packets of a source flow are protected (e.g. using mask). 
> 

Agreed. I suggest removing the word "all".

> 
> Thanks,
> Orly Peck.
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Orly Peck
> Sent: Thursday, January 14, 2010 12:31 PM
> To: Magnus Westerlund; [email-masked]
> Subject: Re: [Fecframe] WG Last Call - Framework
> 
> Hi, 
> I will review the document early next week.
> Thanks,
> Orly Peck.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Thursday, January 14, 2010 12:15 PM
> To: [email-masked]
> Subject: Re: [Fecframe] WG Last Call - Framework
> 
> WG,
> 
> This is one of your core documents. I have seen ONE (1) single comment
> that someone has read the document. I do expect to see a bit more
> reviews on this before I can consider there be consensus for publication
> in the WG.
> 
> Magnus Westerlund
> 
> Greg Shepherd skrev 2009-12-04 16:49:
>> Yes, we called LC on this earlier but I received feedback that there
>> just wasn't enough time...
>> 
>> So, let's keep the WG LC open with a comment due date pushed out to
>> Jan 8th to allow for the Holidays. I'll send weekly reminders to keep
>> everyone on task. Please read and respond so we can ship and shut. ;-)
>> 
>> Thanks!,
>> Greg
>> _______________________________________________
>> Fecframe mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fecframe
>> 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Watson, Mark" <[email-masked]>
Date: Sun, 7 Mar 2010 19:36:56 -0800

All,

In addressing comments on the Raptor FEC Schemes document I found there were some additional changes needed to the framework (specifically related to text encoding of the FEC Scheme-specific FEC Framework Configuration Information).

So there is a -07 draft for the Framework now. Please ignore the -06.

...Mark