RTP Payload Format for Flexible Forward Error Correction (FEC)
draft-ietf-payload-flexible-fec-scheme-20
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-07-17
|
20 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-07-01
|
20 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-06-27
|
20 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-05-24
|
20 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-05-23
|
20 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-05-23
|
20 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-05-23
|
20 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-05-21
|
20 | (System) | RFC Editor state changed to EDIT |
2019-05-21
|
20 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-05-21
|
20 | (System) | Announcement was received by RFC Editor |
2019-05-20
|
20 | (System) | IANA Action state changed to In Progress from On Hold |
2019-05-20
|
20 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-05-20
|
20 | Amy Vezza | IESG has approved the document |
2019-05-20
|
20 | Amy Vezza | Ballot approval text was generated |
2019-05-16
|
20 | Adam Roach | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2019-05-16
|
20 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-20.txt |
2019-05-16
|
20 | (System) | New version approved |
2019-05-16
|
20 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2019-05-16
|
20 | Giridhar Mandyam | Uploaded new revision |
2019-04-26
|
19 | Adam Roach | Shepherding AD changed to Adam Roach |
2019-03-28
|
19 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-19.txt |
2019-03-28
|
19 | (System) | New version approved |
2019-03-28
|
19 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2019-03-28
|
19 | Giridhar Mandyam | Uploaded new revision |
2019-03-27
|
18 | Cindy Morgan | Shepherding AD changed to Barry Leiba |
2019-03-21
|
18 | (System) | IANA Action state changed to On Hold from In Progress |
2019-03-21
|
18 | Amy Vezza | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Approved-announcement sent::Point Raised - writeup needed |
2019-03-21
|
18 | (System) | IANA Action state changed to In Progress |
2019-03-21
|
18 | Ben Campbell | IESG state changed to Approved-announcement sent::Point Raised - writeup needed from Approved-announcement sent |
2019-03-21
|
18 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-03-21
|
18 | Amy Vezza | IESG has approved the document |
2019-03-21
|
18 | Amy Vezza | Closed "Approve" ballot |
2019-03-19
|
18 | Ben Campbell | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-03-19
|
18 | Ben Campbell | Ballot approval text was generated |
2019-03-08
|
18 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my DISCUSS points (and de-confusing me on how the recovery state is consolidated across the different SSRCs and packets … [Ballot comment] Thank you for addressing my DISCUSS points (and de-confusing me on how the recovery state is consolidated across the different SSRCs and packets it covers)! |
2019-03-08
|
18 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-03-05
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-03-05
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-03-05
|
18 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-18.txt |
2019-03-05
|
18 | (System) | New version approved |
2019-03-05
|
18 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2019-03-05
|
18 | Giridhar Mandyam | Uploaded new revision |
2019-02-27
|
17 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Radia Perlman. |
2019-02-21
|
17 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2019-02-21
|
17 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-02-21
|
17 | Mirja Kühlewind | [Ballot comment] Thanks for the well-written document! And thanks for addressing the TSV-ART comments (and thanks Bernard for the review)! |
2019-02-21
|
17 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2019-02-21
|
17 | Mirja Kühlewind | [Ballot comment] Thanks for the well-written document! |
2019-02-21
|
17 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-02-20
|
17 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-02-20
|
17 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-02-20
|
17 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-02-20
|
17 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-02-20
|
17 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-02-20
|
17 | Warren Kumari | [Ballot comment] Like others, I found the 2-D description confusing -- but I'm *so* not a SME here, and figured it's probably just me :-) |
2019-02-20
|
17 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-02-19
|
17 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-02-19
|
17 | Spencer Dawkins | [Ballot comment] I do have one question - the IESG has approved https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/, which updates RFC 6363 to support sliding encoding window codes, in … [Ballot comment] I do have one question - the IESG has approved https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/, which updates RFC 6363 to support sliding encoding window codes, in addition to block codes, and it seems like that would be useful for real-time payload FEC here. Is that something that people have looked at? |
2019-02-19
|
17 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2019-02-19
|
17 | Alexey Melnikov | [Ballot comment] I found 2-D description confusing as well. |
2019-02-19
|
17 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-02-18
|
17 | Benjamin Kaduk | [Ballot discuss] I'm confused about some parts of how I'd implement this. It's quite possible this is just my error, but I'm including this point … [Ballot discuss] I'm confused about some parts of how I'd implement this. It's quite possible this is just my error, but I'm including this point in the Discuss section in case it's not. This basically relates to how multiple recovery packets from a given FEC block get encoded and identified on the wire, but also how to populate the source block when multiple SSRCs are included. In short: suppose that I have D=3 and L=2. I should expect 5 repair packets for the six source packets in a block; the scheme for determining what order to generate them in and what their contents are is fairly clear to me. But how do I identify them on the wire? I'm assuming that the D and L on the wire are fixed values, since there's the possibility to only send zero on the wire and negotiate their values out of band. It's a little less clear whether the "SN base" fields are expected to be the same for all 5 recovery packets based on a given block, but if they do change then I'm not sure how I tell whether a given recovery packet is for a row or a column. Is this supposed to be using the sequence number from the outer RTP header for packet ordering, and the implicit order for row/column FEC packets? (It seems that in case of very bad packet loss and dynamic L+D, the receiver could then get out of sync as to what the sequence number is that corresponds to the start of a new batch of recovery blocks.) I also don't see how, for the case when there are multiple SSRCs, I know how many source packets to include from each SSRC in order to make up the D x L source block -- since Section 6.2's discussion lumps all the "source packets" together into a single set that get mutually xor'd, that seems to imply that the encoding is not "do recovery for SSRC1, do recovery for SSRC2, ..., concatenate them all". There are perhaps some other scenarios to worry about, such as interleaved recovery within a single block, but I'm happy to focus on the single 2-D case for purposes of illustration. Any insight into what I'm missing would be appreciated. A couple other points to check on: I'm not sure I'm following the procedures in Section 6.3.2 properly (see COMMENT) -- is the text correct as written? I also think there are a couple more factors worth mentioning in the security considerations (see COMMENT). |
2019-02-18
|
17 | Benjamin Kaduk | [Ballot comment] It's a little odd to see so much content in Section 1.1 before we get to requirements notation and defintions/notations. I think I'm … [Ballot comment] It's a little odd to see so much content in Section 1.1 before we get to requirements notation and defintions/notations. I think I'm a bit confused about current best practices for multiplexing, as RFC 3550 Section 5.2 says "separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields", but we seem to be not only recommending using SSRC for demultiplexing repair packets, but also suggesting that the FEC can cover multiple different audio and/or video streams with different SSRCs. I guess RFC 8108 is supposed to clarify when it's okay to use multiple SSRCs in the same RTP session, so maybe the answer is just "3550 was overly cautious and we don't worry about that anymore". Section 4.2.1 Version (V) 2 bits: This MUST be set to 2 (binary 10), as this specification requires all source RTP packets and all FEC repair packets to use RTP version 2. The reason for this restriction is the first 2 bits of the FEC header contain other information (R and F bits) rather than recovering the RTP version field. nit: is it better to say that the FEC mechanism does not recover this value, rather than talking about how the first 2 bits of the FEC header are used for something else? (The FEC header's structure need not bear any relation to the 12-byte RTP header, AFAICT.) Payload Type: The (dynamic) payload type for the FEC repair packets is determined through out-of-band means. [...] Is "(e.g., SDP)" applicable here? Sequence Number (SN): The sequence number follows the standard definition provided in [RFC3550]. definition. Therefore it must nit: drop separate "definition." multiplex multiple repair streams in an RTP session. The repair streams' SSRC's CNAME SHOULD be identical to the CNAME of the source RTP stream(s) that this repair stream protects. An FEC stream that protects multiple source RTP streams with different CNAME's uses the CNAME associated with the entity generating the FEC stream or the CNAME of the entity on whose behalf it performs the protection operation. In cases when the repair stream covers packets from multiple source RTP streams with different CNAME values, any of these CNAME values MAY be used. I'm not sure I'm parsing this properly; the penultimate sentence says that the CNAME to use is determined by nature of the entity producing the repair stream, but the last sentence says that there is a nondeterministic choice. Section 4.2.2 Any reason not to include "retransmit" and "fixed block" mnemonics for the 'R' and 'F' bits? Please include a note here that several fields (e.g., P, PT, etc.) in the FEC header are not meant to be interpreted directly but are instead actual FEC parity data akin to the following "payload". (Absent such an indication, the reader could see that these fields are "used to determine" values when they appear to contain values directly, and get confused.) I would suggest adding a forward-reference to Section 6 since that describes how the Repair Payload is calculated. Section 4.2.2.2 Should implementations set bounds on L and D that are smaller than the maximum encodable value (255)? If L=0, D=0, use the optional payload format parameters for L and D. What is the behavior when those payload format parameters were not provided? The L=1 case seems to imply that some full packet retransmission will be used; is it worth calling that out as a consequence of such a parameter choice? Section 4.2.2.3 nit: The "P|X" bits in Figure 15 seem indented by one too many spaces. Section 5.1 (all subsections) Having the ToP values for interleaved and non-interleaved 1-D protection presented in a different order than virtually all of the body text (that presents non-interleaved first) is needlessly hard on the reader. What is the interaction between rate, repair-window, and the L and D values? That is, if we set L and D to be large, and rate to be small, can we end up claiming a repair window that is too small to accumulate the necessary L*D source packets and compute recovery packets? Section 5.2.1 o The value for the repair-window parameter depends on the L and D values and cannot be chosen arbitrarily. More specifically, L and D values determine the lower limit for the repair-window size. The upper limit of the repair-window size does not depend on the L and D values. Per my above remark, this consideration seems generally applicable and not limited to SDP Offer/Answer. o Any unknown option in the offer MUST be ignored and deleted from the answer. If FEC is not desired by the receiver, it can be deleted from the answer. This sounds like it is restating an existing normative requirement (in which case a reference and descriptive, non-normative, text seems appropriate). Section 6.2 o The first 16 bits of the RTP header (16 bits). Maybe note here that we'll actually ignore the first 2 bits? Section 6.3.2 2. For the repair packet in T, compute the FEC bit string from the first 80 bits of the FEC header. I'm scratching my head a bit at this. Is this operation something other than "take the first 80 bits of the FEC header"? (If not, the length and sequence number base seem to be in different places in the source packets and FEC bit string, if I'm reading things right.) 11. Set the SN field in the new packet to SEQNUM. Skip the next 16 bits in the recovered bit string. To be clear, we're skipping over the xor of the reconstructed length field with the seqnum field of the source packets? 13. Take the next 16 bits of the recovered bit string and set the new variable Y to whatever unsigned integer this represents (assuming network order). Convert Y to host order. Y represents the length of the new packet in bytes minus 12 (for the fixed RTP header), i.e., the sum of the lengths of all the following if present: the CSRC list, header extension, RTP payload and RTP padding. I don't see how this matches up with the bit string construction in Section 6.2. Section 6.3.3 1. Append Y bytes to the new packet. [...] 5. Append the recovered bit string (Y octets) to the new packet generated in Section 6.3.2. I think a different verb than "append" should be used in step 1, perhaps "allocate Y additional bytes for the new packet", as the text as-written has us appending 2*Y bytes, only Y of which have a value specified. Section 9 The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity and source authenticity. Confidentiality is achieved by encrypting the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. [...] This phrasing of "is achieved by" implies that the mechanisms for doing so are defined in this document, but that's not the case. Don't we really mean things like "Confidentiality can be provided by encrypting the RTP payload"? Given that FLEX FEC enables the protection of multiple source streams, there exists the possibility that multiple source buffers may be created that may not be used. An attacker could leverage unused source buffers to as a means of occupying memory in a FLEX FEC endpoint. Moreover the application source data may not be perfectly matched with FLEX FEC source partitioning. If this is the case, there is a possibility for unprotected source data if, for instance, the FLEX FEC implementation discards data that does not fit perfectly into its source processing requirements. I don't think this text quite covers the risks when interacting with an adversarial endpoint -- an attacker could try to advertise FEC schemes with large D and L and/or large repair windows, that cause the receiver to consume a lot of resources buffering packets that may be used as repair inputs. Endpoints need to be aware of the risk when deciding whether to accept FEC streams, e.g., via SDP Offer/Answer. Similarly, a network attacker could modify the recovery fields corresponding to packet lengths (when integrity protection is not in play), to force large allocations on the receiver. It's fairly likely that this doesn't even require knowing which source packet(s) will be lost, since length is a 16-bit field and the expected input values are not likely to have the high bit(s) set. The need for integrity protection on the SDP Offer/Answer exchange is probably sufficiently well-documented elsewhere that we don't need to reiterate it here. |
2019-02-18
|
17 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-02-14
|
17 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-02-14
|
17 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Radia Perlman |
2019-02-14
|
17 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Radia Perlman |
2019-02-14
|
17 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Radia Perlman. |
2019-02-12
|
17 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tina Tsou |
2019-02-12
|
17 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tina Tsou |
2019-02-12
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-02-12
|
17 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-17.txt |
2019-02-12
|
17 | (System) | New version approved |
2019-02-12
|
17 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2019-02-12
|
17 | Giridhar Mandyam | Uploaded new revision |
2019-02-07
|
16 | Amy Vezza | Placed on agenda for telechat - 2019-02-21 |
2019-02-07
|
16 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2019-02-07
|
16 | Ben Campbell | Ballot has been issued |
2019-02-07
|
16 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2019-02-07
|
16 | Ben Campbell | Created "Approve" ballot |
2019-02-04
|
16 | Magnus Westerlund | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Bernard Aboba. |
2019-02-01
|
16 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-02-01
|
16 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-payload-flexible-fec-scheme-16. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-payload-flexible-fec-scheme-16. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete. First, in the audio Media Types registry on the Media Types registry page located at: https://www.iana.org/assignments/media-types/ a single, new Media Type will be registered as follows: Name: flexfec Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] Second, in the video Media Types registry on the Media Types registry page located at: https://www.iana.org/assignments/media-types/ a single, new Media Type will be registered as follows: Name: flexfec Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] Third, in the text Media Types registry on the Media Types registry page located at: https://www.iana.org/assignments/media-types/ a single, new Media Type will be registered as follows: Name: flexfec Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] Fourth, in the application Media Types registry on the Media Types registry page located at: https://www.iana.org/assignments/media-types/ a single, new Media Type will be registered as follows: Name: flexfec Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] IANA Question --> Section 10 of the current document suggests that in order to find the registration requirements, IANA can find the registration details of the payload formats and their parameters introduced in this document by referring to Section 5. IANA understands the requirements for Media Types in Section 5.1 of the current draft, but we are unable to determine if there are IANA requirements, once the document is approved, in section 5.2. Could the authors clarify any requirements for section 5.2 and possible include more detailed instructions for IANA in section 10. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-02-01
|
16 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2019-01-28
|
16 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bernard Aboba |
2019-01-28
|
16 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bernard Aboba |
2019-01-25
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2019-01-25
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2019-01-24
|
16 | Francesca Palombini | Assignment of request for Last Call review by GENART to Francesca Palombini was rejected |
2019-01-24
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francesca Palombini |
2019-01-24
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francesca Palombini |
2019-01-24
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2019-01-24
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2019-01-18
|
16 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-01-18
|
16 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-02-01): From: The IESG To: IETF-Announce CC: ben@nostrum.com, payload-chairs@ietf.org, payload@ietf.org, roni.even@mail01.huawei.com, Roni … The following Last Call announcement was sent out (ends 2019-02-01): From: The IESG To: IETF-Announce CC: ben@nostrum.com, payload-chairs@ietf.org, payload@ietf.org, roni.even@mail01.huawei.com, Roni Even , draft-ietf-payload-flexible-fec-scheme@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (RTP Payload Format for Flexible Forward Error Correction (FEC)) to Proposed Standard The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for Flexible Forward Error Correction (FEC)' as 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 ietf@ietf.org mailing lists by 2019-02-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes, where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes which are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications, but endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2794/ |
2019-01-18
|
16 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-01-18
|
16 | Ben Campbell | Last call was requested |
2019-01-18
|
16 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-01-18
|
16 | Ben Campbell | Last call announcement was generated |
2019-01-18
|
16 | Ben Campbell | Ballot writeup was changed |
2019-01-18
|
16 | Ben Campbell | Ballot approval text was generated |
2019-01-17
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-17
|
16 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-16.txt |
2019-01-17
|
16 | (System) | New version approved |
2019-01-17
|
16 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2019-01-17
|
16 | Giridhar Mandyam | Uploaded new revision |
2019-01-14
|
15 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2019-01-13
|
15 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-15.txt |
2019-01-13
|
15 | (System) | New version approved |
2019-01-13
|
15 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2019-01-13
|
15 | Giridhar Mandyam | Uploaded new revision |
2019-01-03
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-03
|
14 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-14.txt |
2019-01-03
|
14 | (System) | New version approved |
2019-01-03
|
14 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2019-01-03
|
14 | Giridhar Mandyam | Uploaded new revision |
2018-12-18
|
13 | Ben Campbell | 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. … 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. *** 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 (iesg@ietf.org) 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. |
2018-12-18
|
13 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-12-17
|
13 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2018-12-14
|
13 | Roni Even | What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is … What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document will be a standard track RFC. This document defines new RTP payload formats for the Forward Error Correction (FEC) packets The type is indicated on the title page (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes, where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes which are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document was discussed in the meetings, and on the mailing list. The open issues were addressed and there are no open issues, there was consensus on the content of the document. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The payload was developed by members from different vendors and is part of the RTCWEB deliveries. Magnus Westerlund and Steve Botzko did a thorough review of the document. A request for a media type review was sent to ietf-types and media-types mailing lists. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Roni Even is the Document Shepherd. The responsible AD is Ben Campbell. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed the document in previous and current versions and found it ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document had reviews before and during the two WGLC. The comments during the WGLCs were addressed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. None. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. The authors confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are IPR statements from Cisco https://datatracker.ietf.org/ipr/search/?id=draft-ietf-payload-flexible-fec-scheme&submit=draft It was mentioned and there were no objections to publish the document with this IPR. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG understand the document and agree with it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No issues (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No need (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? None (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are none (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). IANA section is OK (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None were needed |
2018-12-14
|
13 | Roni Even | Responsible AD changed to Ben Campbell |
2018-12-14
|
13 | Roni Even | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-12-14
|
13 | Roni Even | IESG state changed to Publication Requested |
2018-12-14
|
13 | Roni Even | IESG process started in state Publication Requested |
2018-12-11
|
13 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-13.txt |
2018-12-11
|
13 | (System) | New version approved |
2018-12-11
|
13 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2018-12-11
|
13 | Giridhar Mandyam | Uploaded new revision |
2018-12-07
|
12 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-12.txt |
2018-12-07
|
12 | (System) | New version approved |
2018-12-07
|
12 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2018-12-07
|
12 | Giridhar Mandyam | Uploaded new revision |
2018-11-26
|
11 | Roni Even | Notification list changed to "Roni Even" <roni.even@huawei.com> from "Roni Even" <roni.even@mail01.huawei.com> |
2018-11-26
|
11 | Roni Even | Changed consensus to Yes from Unknown |
2018-11-26
|
11 | Roni Even | Intended Status changed to Proposed Standard from None |
2018-11-26
|
11 | Roni Even | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2018-11-26
|
11 | Roni Even | Changed document writeup |
2018-11-18
|
11 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-11.txt |
2018-11-18
|
11 | (System) | New version approved |
2018-11-18
|
11 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2018-11-18
|
11 | Giridhar Mandyam | Uploaded new revision |
2018-11-04
|
10 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-10.txt |
2018-11-04
|
10 | (System) | New version approved |
2018-11-04
|
10 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2018-11-04
|
10 | Giridhar Mandyam | Uploaded new revision |
2018-10-22
|
09 | Giridhar Mandyam | New version available: draft-ietf-payload-flexible-fec-scheme-09.txt |
2018-10-22
|
09 | (System) | New version approved |
2018-10-22
|
09 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2018-10-22
|
09 | Giridhar Mandyam | Uploaded new revision |
2018-07-16
|
08 | Mo Zanaty | New version available: draft-ietf-payload-flexible-fec-scheme-08.txt |
2018-07-16
|
08 | (System) | New version approved |
2018-07-16
|
08 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2018-07-16
|
08 | Mo Zanaty | Uploaded new revision |
2018-03-22
|
07 | Mo Zanaty | New version available: draft-ietf-payload-flexible-fec-scheme-07.txt |
2018-03-22
|
07 | (System) | New version approved |
2018-03-22
|
07 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2018-03-22
|
07 | Mo Zanaty | Uploaded new revision |
2018-03-05
|
06 | Mo Zanaty | New version available: draft-ietf-payload-flexible-fec-scheme-06.txt |
2018-03-05
|
06 | (System) | New version approved |
2018-03-05
|
06 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2018-03-05
|
06 | Mo Zanaty | Uploaded new revision |
2018-01-04
|
05 | (System) | Document has expired |
2018-01-03
|
05 | Roni Even | Tag Revised I-D Needed - Issue raised by WGLC set. |
2017-07-03
|
05 | Mo Zanaty | New version available: draft-ietf-payload-flexible-fec-scheme-05.txt |
2017-07-03
|
05 | (System) | New version approved |
2017-07-03
|
05 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2017-07-03
|
05 | Mo Zanaty | Uploaded new revision |
2017-03-28
|
04 | Mo Zanaty | New version available: draft-ietf-payload-flexible-fec-scheme-04.txt |
2017-03-28
|
04 | (System) | New version approved |
2017-03-28
|
04 | (System) | Request for posting confirmation emailed to previous authors: Mo Zanaty , Giridhar Mandyam , Varun Singh , Ali Begen |
2017-03-28
|
04 | Mo Zanaty | Uploaded new revision |
2016-10-31
|
03 | Varun Singh | New version available: draft-ietf-payload-flexible-fec-scheme-03.txt |
2016-10-31
|
03 | (System) | New version approved |
2016-10-31
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Varun Singh" , payload-chairs@ietf.org, "Ali Begen" , "Mo Zanaty" , "Giridhar Mandyam" |
2016-10-31
|
02 | Varun Singh | Uploaded new revision |
2016-09-22
|
02 | (System) | Document has expired |
2016-05-13
|
Maddy Conner | Posted related IPR disclosure: Cisco Systems, Inc.'s Statement about IPR related to draft-ietf-payload-flexible-fec-scheme | |
2016-03-21
|
02 | Varun Singh | New version available: draft-ietf-payload-flexible-fec-scheme-02.txt |
2016-02-17
|
01 | Ali Begen | Notification list changed to "Roni Even" <roni.even@mail01.huawei.com> |
2016-02-17
|
01 | Ali Begen | Document shepherd changed to Roni Even |
2015-10-19
|
01 | Varun Singh | New version available: draft-ietf-payload-flexible-fec-scheme-01.txt |
2015-02-14
|
00 | Varun Singh | New version available: draft-ietf-payload-flexible-fec-scheme-00.txt |