[payload] AD Evaluation of draft-ietf-payload-flexible-fec-scheme-13

[Ben Campbell <[e-mail]>]

Hi,

This is my AD Evaluation of draft-ietf-payload-flexible-fec-scheme-13.

The document is overall in pretty good shape. It’s more readable than I expected, given the subject matter. I would like to discuss my substantive comments/questions prior to IETF LC.

Thanks!

Ben.

*** Substantive***

General: Do I read correctly that this document can completely stand alone from RFC 6363? That is, the calculation of the protection stream and reconstruction of lost source packets is completely specified in this document? I don’t see that as a problem, but if it’s correct some introduction text to that effect would be helpful. Is a normative reference to 6363 even needed?

 If that’s _not_ the intent, then we need some discussion about where I went wrong in reading it.

§2: Unless there’s a strong reason otherwise, please use the updated key word boilerplate from RFC 8174.

§4.2: "The FEC repair packets MUST contain information that identifies the
source block...”: The MUST seems more like a statement of fact than a normative requirement.

§4.2.1:

- There’s a number of 2119/8174 keywords in this section that seem more natural consequences of using RTP than new normative requirements. If that is the case, they shouldn’t use normative keywords unless in the form of direct quotes.

- 10th paragraph: "The repair streams’ SSRC’s CNAME SHOULD be
identical to the CNAME of the source RTP stream(s) that this
repair stream protects.”
Why is the SHOULD not a MUST? What happens if it is violated?


- 11th paragraph: "such
scenarios, using the same CNAME for the source and repair RTP
streams means that the RTP Source and the FEC Source MUST share
the same CNAME (for this specific source-repair stream
association).”

That MUST seems like a statement of fact.

§4.2.2: Please add a short explanation of why we need two different FEC packet formats. (Not counting the retransmission packet; the reasoning there is pretty obvious.)

§5.1.1 (and subsequent media type definitions)

- Please consider using the IESG ([e-mail]) as the contact for further information. Working groups come and go, and authors change jobs. But someone on the IESG should (hopefully) always be able to find the right person,

- Change control:  In 5.1.1, shouldn’t that be the PAYLOAD working group (or it’s successor as delegated by the IESG...)

- Are these registrations really intended to be provisional?

§5.2.1, last bullet: "Any unknown option in the offer MUST be ignored and deleted from
the answer.”: Is that a a new requirement specific to flex-fec, or just a normal offer/answer requirement?

§6.3.1.1, last paragraph: This is the only mention of “staircase” in the draft. Please add or cite a definition.

§8:
- "the potential impacts of using FEC MUST be considered” is vague for a MUST. Who/what does this apply to? Is the implementor expected to know in advance whether their implementation will be used in a congestion-prone network? (If that is the intent, I suggest non-normative guidance.)
- “In a network-friendly implementation”: Do you expect to see network-unfriendly implementations? Is that okay?

§9, last paragraph: What are the security implications of unused source-buffers? Is this a potential DoS vector?


*** Editorial ***

- Abstract: I’m not sure how to interpret the phrase “decent complexity”. How much complexity qualifies as “decent”?

§1,

- first paragraph: Please add  or cite a definition for FEC. I’m not sure all readers will understand it the same way the authors do. (I was personally surprised to find discussion about reacting to feedback, since I thought of FEC as something used when no feedback channel was available.)

- 2nd paragraph: s/Redunadncy/Redundancy”

§1.1.1:

- It would be helpful to describe what L and D represent here, or at least give a forward reference to the definition. (I note that a lot of text goes by before you get to the  definitions or the 2119 boilerplate.)

- Does 1-D and later 2-D stand for “one dimensional” and “two dimensional”? If so, please expand  both first mention. (As it was, I got a bit confused by trying to conflate the “D” in “1-D” with the “D” in “LxD”.)

§1.1.5:
- "assuming that each repair packet carries an equal
number of bytes carried by a source packet,”
s/ “bytes carried”/“bytes as carried”

§4.2, last paragraph: Missing article before ‘Repair “Payload” ‘

§4.2.2, paragraph after Figure 10:
The text seems to be suggest there is one source packet protected by a given repair packet. IIUC, that’s not the case; a given FEC packet protects several source packets, doesn’t it?

§5.2, first paragraph: s/ "Applications that are using RTP transport” / “Applications that use the RTP transport”

§5.2.1, first bullet: I don’t know how to interpret “SHOULD normally”.

§5.2.2, first paragraph: Is there a reason to cite the obsolete RFC 2326?

§6.3.3:
- list item 2: "The padding of octet 0 MUST be added at
the end of the bit string.”: I assume that means “padded with zeros”, but it could be interpreted to mean “pad the zeroth byte”.

- list item 5: Should “num_recovered_until_this_iteration” say “before_this_iteration”?

§9, last paragraph: I don’t understand the intent of the last sentence.