Hi, Even better, thanks. Best, Meral
From: Giridhar Mandyam <[email protected]> Sent: Monday, February 4, 2019 3:22 PM To: Varun Singh <[email protected]> Cc: Meral Shirazipour <[email protected]>; [email protected]; [email protected] Subject: RE: Gen-ART Last Call review of draft-ietf-payload-flexible-fec-scheme-16 Hi Merai, Slight revision follows. I assume it is still OK. “… an application should avoid sending/receiving FEC repair streams if it knows that sending/receiving those FEC repair streams would not help at all in recovering the missing packets. Examples of where FEC would not be beneficial are: (1) if the successful recovery rate as determined by RTCP feedback is low (see RFC 5725 and RFC 7509), and (2) the application has a smaller latency requirement than the repair window adopted by the FEC configuration based on the expected burst loss duration and the target FEC overhead. It is RECOMMENDED that the amount and type (row, column, or both) of FEC protection is adjusted dynamically based on the packet loss rate and burst loss length observed by the applications." -Giri From: Varun Singh <[email protected]<mailto:[email protected]>> Sent: Monday, February 4, 2019 3:13 PM To: Giridhar Mandyam <[email protected]<mailto:[email protected]>> Cc: Meral Shirazipour <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: Gen-ART Last Call review of draft-ietf-payload-flexible-fec-scheme-16 CAUTION: This email originated from outside of the organization. Hi Giri, Both post-repair loss metrics should be referenced, one provides run-length perpacket feedback and the other provides loss and repair counters. Webrtc-stats reports on the latter and can already be used to toggle FEC in webrtc applications. On Mon, 4 Feb 2019 at 0.34, Giridhar Mandyam <[email protected]<mailto:[email protected]>> wrote: >-Section 8, "an application should avoid sending/receiving FEC repair streams >if it knows that sending/receiving those FEC repair streams would not help at >all in recovering the missing packets. It is RECOMMENDED that the amount and >type (row, column, or both) of FEC protection is adjusted dynamically based on >the packet loss rate and burst loss length observed by the applications." >How would the application know that sending/receiving those FEC repair streams >would not help at all? any rule of thumb to add here? The editors propose that the above text be revised as follows: “… an application should avoid sending/receiving FEC repair streams if it knows that sending/receiving those FEC repair streams would not help at all in recovering the missing packets. Examples of where FEC would not be beneficial are: (1) if the successful recovery rate as determined by RTCP feedback is low (see RFC 5725), and (2) the application has a smaller latency requirement than the repair window adopted by the FEC configuration based on the expected burst loss duration and the target FEC overhead. It is RECOMMENDED that the amount and type (row, column, or both) of FEC protection is adjusted dynamically based on the packet loss rate and burst loss length observed by the applications." Please let us know if this is acceptable. Thanks, -Giri Mandyam From: Meral Shirazipour <[email protected]<mailto:[email protected]>> Sent: Thursday, January 31, 2019 11:50 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Gen-ART Last Call review of draft-ietf-payload-flexible-fec-scheme-16 CAUTION: This email originated from outside of the organization. I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-payload-flexible-fec-scheme-16 Reviewer: Meral Shirazipour Review Date: 2019-01-31 IETF LC End Date: 2019-02-01 IESG Telechat date: NA Summary: This draft is ready to be published as Standards Track RFC . Major issues: Minor issues: Nits/editorial comments: -Section 1.1.1 Title "One-Dimensionsal "--->"One-Dimensional" -[Page 14] 3.2. , "signficant"--->"significant" -[Page 16], 4.2.1. , "pakcets"--->"packets" -[Page 35], 6.3.1. , "reciever"--->"receiver" -[Page 35], 6.3.1.1. , "signficant"--->"significant" -[Page 43], 7., "several Sesssion "--->"several Session " -Section 8, "an application should avoid sending/receiving FEC repair streams if it knows that sending/ receiving those FEC repair streams would not help at all in recovering the missing packets. It is RECOMMENDED that the amount and type (row, column, or both) of FEC protection is adjusted dynamically based on the packet loss rate and burst loss length observed by the applications." How would the application know that sending/receiving those FEC repair streams would not help at all? any rule of thumb to add here? Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com<http://www.ericsson.com> -- Founder, CEO, callstats.io<http://callstats.io> http://www.callstats.io Interested in networking, media quality, and diagnostics. We are hiring!: www.callstats.io/jobs/<http://www.callstats.io/jobs/>
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
