jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rtcweb-fec

Commentary: PTAL 
 threshold . 
 LGTM
Because use of FEC always causes redundant data to be transmitted,
and the total amount of data must remain within any bandwidth limits
indicated by congestion control and the receiver, this will lead to
less bandwidth available for the primary encoding, even when the
redundant data is not being used.  This is in contrast to methods
like RTX RFC4588 or flexfec's retransmission mode ( I-D.ietf-payload-
flexible-fec-scheme, Section 1.1.7), which only transmit redundant
data when necessary, at the cost of an extra roundtrip.
Given this, WebRTC implementations SHOULD consider using RTX or
flexfec retransmissions instead of FEC when RTT is low, and SHOULD
only transmit the amount of FEC needed to protect against the
observed packet loss (which can be determined, e.g., by monitoring
transmit packet loss data from RTCP Receiver Reports RFC3550), unless
the application indicates it is willing to pay a quality penalty to
proactively avoid losses.
Note that when probing bandwidth, i.e., speculatively sending extra
data to determine if additional link capacity exists, FEC SHOULD be
used in all cases.  Given that extra data is going to be sent
regardless, it makes sense to have that data protect the primary
payload; in addition, FEC can be applied in a way that increases
bandwidth only modestly, which is necessary when probing.
Because use of FEC always causes redundant data to be transmitted,
and the total amount of data must remain within any bandwidth limits
indicated by congestion control and the receiver, this will lead to
less bandwidth available for the primary encoding, even when the
redundant data is not being used.  This is in contrast to methods
like RTX RFC4588 or flexfec's retransmission mode ( I-D.ietf-payload-
flexible-fec-scheme, Section 1.1.7), which only transmit redundant
data when necessary, at the cost of an extra roundtrip and thereby
increased media latency.
Given this, WebRTC implementations SHOULD prefer using RTX or flexfec
retransmissions instead of FEC when the connection RTT is within the
application's latency budget, and otherwise SHOULD only transmit the
amount of FEC needed to protect against the observed packet loss
(which can be determined, e.g., by monitoring transmit packet loss
data from RTCP Receiver Reports RFC3550), unless the application
indicates it is willing to pay a quality penalty to proactively avoid
losses.
Note that when probing bandwidth, i.e., speculatively sending extra
data to determine if additional link capacity exists, FEC data SHOULD
be used as the additional data.  Given that extra data is going to be
sent regardless, it makes sense to have that data protect the primary
payload; in addition, FEC can typically be applied in a way that
increases bandwidth only modestly, which is necessary when probing.
Draft: draft-ietf-rtcweb-fec

Commentary: I believe this came from a WG mailing list post ( possibly my own ) , rather than an external document that could be linked to . Suggestions ? Unfortunately , that was the best RFC reference I could find .
For Opus, audio frames deemed important are re-encoded at a lower
bitrate and appended to the next payload, allowing partial recovery
of a lost packet.  This scheme is fairly efficient; experiments
performed indicate that when Opus FEC is used, the overhead imposed
is only about 20-30%, depending on the amount of protection needed.
Note that this mechanism can only carry redundancy information for
the immediately preceding audio frame; as such the decoder cannot
fully recover multiple consecutive lost packets, which can be a
problem on wireless networks.  See RFC6716, Section 2.1.7 for
complete details.
For Opus, audio frames deemed important are re-encoded at a lower
bitrate and appended to the next payload, allowing partial recovery
of a lost packet.  This scheme is fairly efficient; experiments
performed indicate that when Opus FEC is used, the overhead imposed
is only about 20-30%, depending on the amount of protection needed.
Note that this mechanism can only carry redundancy information for
the immediately preceding audio frame; as such the decoder cannot
fully recover multiple consecutive lost packets, which can be a
problem on wireless networks.  See RFC6716, Section 2.1.7, and
OpusFEC for more details.
Draft: draft-ietf-rtcweb-fec

Commentary: Ah , I see now . I think what would help is " in contrast to methods like RTX or  ( when retransmissions are used ) [ I - D. < ... ] "
Because use of FEC always causes redundant data to be transmitted,
and the total amount of data must remain within any bandwidth limits
indicated by congestion control and the receiver, this will lead to
less bandwidth available for the primary encoding, even when the
redundant data is not being used.  This is in contrast to methods
like RTX RFC4588 or flexfec I-D.ietf-payload-flexible-fec-scheme
retransmissions, which only transmit redundant data when necessary,
at the cost of an extra roundtrip.
Because use of FEC always causes redundant data to be transmitted,
and the total amount of data must remain within any bandwidth limits
indicated by congestion control and the receiver, this will lead to
less bandwidth available for the primary encoding, even when the
redundant data is not being used.  This is in contrast to methods
like RTX RFC4588 or flexfec's retransmission mode ( I-D.ietf-payload-
flexible-fec-scheme, Section 1.1.7), which only transmit redundant
data when necessary, at the cost of an extra roundtrip.