Subject: Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02

From: "Watson, Mark" <[email-masked]>
Date: Wed, 6 Jan 2010 18:38:55 -0800

Hi Ali,

Again, sorry for the slight delay ...

Comments inline...

On 10/27/09 9:59 PM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

Here is the list of my comments for this draft. As I mentioned earlier, this draft should be reviewed by AVT as well.

- RFC 3550 needs to be cited in the introduction section and in other relevant places.

MW: Presuably only on the first mention of RTP ?

- Section 3: "... In this case, in the language of the FEC Framework, there is no explicit FEC Source Payload Id." --> "... there is no (need for) explicit ..."

MW: I suggest "In this case, in the language of the FEC Framework, there is no need for an explicit FEC Source Payload Id and it is therefore not included in the packets."

- Section 4.1, Market bit: I believe "shall" should be "SHALL" in this sentence.

MW: Ok

- Section 4.1: What about the other fields in the RTP header? If there are no specific usage rules, a note saying that RFC 3550 rules shall apply should be added.

MW: Ok

- Section 4.2 and 4.3: This is the part that needs some work. I don't think we can simply refer to the framework and fecframe-raptor drafts and leave these parts (which are the most critical sections in a payload draft) empty. First of all, why is there a reference to the framework draft? Secondly, this section needs to make it clear that the payload draft is for the last FEC scheme introduced in the fecframe-raptor draft (Section 8).

In the current draft, it says there is no (FEC) payload header. So, I guess everything goes into the RTP payload. However, IMO it is better to introduce the Repair FEC Payload ID (section 8.1.3 of the fecframe-raptor draft) as the FEC payload header, and then put the repair symbols as the RTP payload. This makes it a better representation and easier for others to visualize the encoding/decoding ops.

MW: I disagree on these two points. The FEC Framework clearly defines the FEC Repair Payload, making reference to the details which must be filled in by an FEC Scheme. So the Framework, together with an FEC Scheme, fully defines the FEC Repair Payload for that scheme and all that remains is for us to say where in the RTP packet the FEC Repair Payload appears. Making reference to the internal structure of the FEC Repair Payload (Repair FEC Payload Id etc.) would be duplicate specification.

The payload format defined here could be used with any of the schemes defined in the Raptor FEC Schemes document.

- Are there any requirements for max-sbl and symbol-size parameters? If yes, they must be stated in every subsection of 6.3.

MW: The requirements are in the FEC Schemes and should not be duplicated here.

- Search for " definedf" and replace it with " defined".

MW: Ok

- Section 5: Are not there any special considerations for Raptor FEC? The CC section in the framework is pretty generic IMO. Some specific guidelines, if any, would be appropriate to put here. And this section should be moved to the end.

MW: I can't think of anything that is specific to Raptor.

- Section 7: The mapping to the SDP parameters should be explained. There is a boilerplate for it. Just apply it to your document.

- Section 8 and 9: I am pretty sure there are some offer/answer model and declarative SDP considerations. Again, there is a boilerplate for it, but it must be modified a little bit to fit to the specifics of this payload format.

MW: Where can I get the boilerplate ? I took the specification format from Magnus' "how to", but I didn't see additional boilerplate for these sections.

- Section 10: Before IANA considerations, I was hoping to have a section describing the "Protection and Recovery Procedures." The protection part explains how the repair packets are constructed. This can be kept brief with proper references to the fecframe-raptor draft, but there should sufficient text that gives a general idea to the readers. For the recovery procedures, they should be detailed more since even the other draft does not explain this AFAICT.

MW: Again, all this is covered by the combination of FEC Framework and the FEC Schemes and included by reference. I know that in the case of the XOR code you did not make use of the FEC Framework, and chose to define everything in the RTP Payload format, but here we are compliant to the framework and the RTP Payload Format need only define how the data is mapped to RTP packets and address and RTP-specific considerations. It is not a stand-alone document.

- An SDP example showing the RTP format parameters is essential.

MW: Ok.

- Section 11: There is a boilerplate for security considerations section and all RTP payload format drafts use it. That should be included here.

MW: Let me know where, although I don't see that there could be any Raptor-specific security considerations.

...Mark

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 9 Jan 2010 17:14:28 -0800

> MW: Presuably only on the first mention of RTP ?

Sure but also whenever it feels appropriate.
  
> 
> 	- Section 3: "... In this case, in the language of the FEC Framework, there is no
> explicit FEC Source Payload Id." --> "... there is no (need for) explicit ..."
> 
> 
> 
> MW: I suggest “In this case, in the language of the FEC Framework, there is no need for an
> explicit FEC Source Payload Id and it is therefore not included in the packets.”

Sounds good.
 
> 	- Section 4.2 and 4.3: This is the part that needs some work. I don't think we can
> simply refer to the framework and fecframe-raptor drafts and leave these parts (which are
> the most critical sections in a payload draft) empty. First of all, why is there a
> reference to the framework draft? Secondly, this section needs to make it clear that the
> payload draft is for the last FEC scheme introduced in the fecframe-raptor draft (Section
> 8).
> 
> 	In the current draft, it says there is no (FEC) payload header. So, I guess
> everything goes into the RTP payload. However, IMO it is better to introduce the Repair
> FEC Payload ID (section 8.1.3 of the fecframe-raptor draft) as the FEC payload header, and
> then put the repair symbols as the RTP payload. This makes it a better representation and
> easier for others to visualize the encoding/decoding ops.
> 
> 
> 
> MW: I disagree on these two points. The FEC Framework clearly defines the FEC Repair
> Payload, making reference to the details which must be filled in by an FEC Scheme. So the
> Framework, together with an FEC Scheme, fully defines the FEC Repair Payload for that
> scheme and all that remains is for us to say where in the RTP packet the FEC Repair
> Payload appears. Making reference to the internal structure of the FEC Repair Payload
> (Repair FEC Payload Id etc.) would be duplicate specification.

Fine for me. But, I must say this looked strange (or somewhat empty) to me the first time I read. 

> Raptor FEC Schemes document.

This was not clear to me. I thought RTP transport only applied to the single-sequenced flows. This seems to be what the fecframe-raptor is saying, too.
 
> 
> 
> 	- Are there any requirements for max-sbl and symbol-size parameters? If yes, they
> must be stated in every subsection of 6.3.
> 
> 
> 

I’d imagine you would get a similar comment from IESG on this. This is the payload format registration so IMO it should have all the reqs, exceptions, magical numbers, etc.
 
> 	- Section 7: The mapping to the SDP parameters should be explained. There is a
> boilerplate for it. Just apply it to your document.
> 
> 	- Section 8 and 9: I am pretty sure there are some offer/answer model and declarative
> SDP considerations. Again, there is a boilerplate for it, but it must be modified a little
> bit to fit to the specifics of this payload format.
> 
> 
> 
> MW: Where can I get the boilerplate ? I took the specification format from Magnus’ “how
> to”, but I didn’t see additional boilerplate for these sections.

Just check one of the recent payload format registrations. 
http://www.ietf.org/rfc/rfc5577.txt
Or more relevantly, check 
http://tools.ietf.org/html/draft-ietf-fecframe-1d2d-parity-scheme-01  

> 	- Section 11: There is a boilerplate for security considerations section and all RTP
> payload format drafts use it. That should be included here.
> 
> 
> 
> MW: Let me know where, although I don’t see that there could be any Raptor-specific
> security considerations.

See the refs above.
 
-acbegen

---

From: "Watson, Mark" <[email-masked]>
Date: Mon, 11 Jan 2010 15:47:36 -0800

Hi Ali,

Responses inline...

On 1/9/10 5:14 PM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

<snip>

MW: The single-sequenced-flow scheme can apply to any source flow where there is already a sequence number and an RTP source flow is a formally defined example of that.

But in this document we are discussing RTP *repair flows* and these can be used with any of the FEC Schemes. For example if you want to protect multiple source flows with a single repair flow you would need one of the schemes with an explicit FEC Source Payload Id.

> MW: The requirements are in the FEC Schemes and should not be duplicated here.

I'd imagine you would get a similar comment from IESG on this. This is the payload format registration so IMO it should have all the reqs, exceptions, magical numbers, etc.

MW: Incorporating information by reference is formally equivalent to including the information directly, but avoids duplication of documentation. So all the information is included. I can add some more explanation of this.

...Mark

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 11 Jan 2010 17:09:06 -0800

Hi Mark,

> -----Original Message-----
> From: Watson, Mark [mailto:[email-masked]]
> Sent: Monday, January 11, 2010 3:48 PM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
> 
> Hi Ali,
> 
> Responses inline...
> 
> 
> 	> The payload format defined here could be used with any of the schemes defined in
> the
> 	> Raptor FEC Schemes document.
> 
> 	This was not clear to me. I thought RTP transport only applied to the single-
> sequenced flows. This seems to be what the fecframe-raptor is saying, too.
> 
> 
> 
> MW: The single-sequenced-flow scheme can apply to any source flow where there is already a
> sequence number and an RTP source flow is a formally defined example of that.
> 
> But in this document we are discussing RTP *repair flows* and these can be used with any
> of the FEC Schemes. For example if you want to protect multiple source flows with a single
> repair flow you would need one of the schemes with an explicit FEC Source Payload Id.

Could you make this more clear in the text? 

> 	I’d imagine you would get a similar comment from IESG on this. This is the payload
> format registration so IMO it should have all the reqs, exceptions, magical numbers, etc.
> 
> 
> 
> MW: Incorporating information by reference is formally equivalent to including the
> information directly, but avoids duplication of documentation. So all the information is
> included. I can add some more explanation of this.

Would be useful.

Thanks.
-acbegen