Original text:
CC, FEC in CC, FEC below CC), the impact of reliable transport on the FEC reliability mechanisms is different.  The application layer may be composed of several streams above FEC and transport layers instances.  The different streams could exploit different paths between the sender and the receiver or not.  The transport layers instances is out of the scope of the document and not further described. <del> 2.3. </del>  Traffic from or to different end users may share various types of bottlenecks.  When such a shared bottleneck does not implement some coding rate of a FEC mechanism could be adapted based on inputs from the application and the trade-off between latency and packet loss. Partial reliability impacts the type of FEC and type of codec that <del> can be used. </del>  3.7. example, the reliability offered by FEC may be sufficient, with no retransmission required.  This depends on application needs and the trade-off between latency and loss.  Partial reliability impacts the <del> type of FEC and type of codec that can be used. </del>  4.7. partial reliability only.  In this case, FEC may provide an unnecessary service if it is not aware of the reliability requirements.  Partial reliability impacts the type of FEC and type <del> of codec that can be used. </del>  5.7. (1) reducing goodput when useless repair symbols are transmitted and (2) helping to recover from transmission and congestion losses. <del> For the FEC above transport case, there is a trade-off related to the amount of redundancy to add, as a function of the transport layer protocol and application requirements. For the FEC within transport case, recovering lost symbols may hide congestion losses from the congestion control.  Some existing solutions already propose to disambiguate acked packets from rebuilt packets QUIC-FEC.  New signaling methods and FEC-recovery-aware congestion controls could be proposed. For the FEC below transport case, there are opportunities for introducing interaction between congestion control and coding schemes to improve the quality of experience while guaranteeing fairness with other flows.  New signaling methods and FEC-recovery-aware congestion controls could be proposed.  An open question also resides in the relevance of FEC when there are multiple streams that exploit the FEC channel. </del>  6.3.

Reviewer comments:
I agree with all your comments. I think we could have a chat at some point to discuss the sentence that has been deleted.
Cool. About discussing: anytime!
NAME NAME NAME : what do you think of this PR ? I think this solves the current open issues of the document and once we agree, we could publish this, send an email to the list and advertise the document in other research groups.
I like the PR and I agree with you. Others?
Fine for me
This is an IRTF document how is this relating to current research and where? CC and NC are essentially two competing control loops - there is a lot of heritage on that topic (outside networking too) - what can NC/CC learn from that - any research questions? My experience with NC is that the most gains are in low loss networks (far from network capacity) - where in fact CC protocols over react- is there research on appropriate metrics? Most of the gain seems to be in last-mile/access networks - any other research? -> All of this to say that the draft should be clearer on the type of research that is needed again when the performance is impacted 2 conflicting control loops.
I think the draft touches upon quite a number of research ideas / possibilities, but they're "hidden" in the structure perhaps... so I believe this is a matter of making them explicit, let them stand out - perhaps a section towards the end that summarizes pulls them together and summarizes?
It would be good. Thanks. mjm Marie-José Montpetit, Ph.D. EMAIL
I think this is covered by the research questions in the dedicated section - see PR
From Vincent's email : While working on RFC 8681 on sliding window codes, we tried to find appropriate parameter derivation techniques. It turned out to be quite difficult. You can have a look at the discussion here: URL
Feedback from IETF110 : Refer to existing RFC Same as far issue , the impact of the type of codes (block vs sliding), size of the blocks, etc.
The research question section has been modified in PR
From Vincent's email : ** Section 3.6: I would say that partial reliability essentially impacts the type of FEC and type of codec you can use. If your codec does not enable a subset of the linear system to be inverted, but instead waits to have the perfect expected rank to invert and recover missing packets, you won’t achieve partial reliability. Partial reliability also impacts the way you use a block FEC: in that case, I’d say use small block sizes, so that you can solve one of them but not necessarily all of them… except that it will also lower the robustness in front of long loss periods. This is typically where sliding window codes do offer a key advantage. (see URL)
Feedback from IETF110 meeting: Mention the difference between block and sliding window codes, the impact of the size of the blocks , etc.
Propose closure with PR
Marie-José I am following the evolution of this draft and while the issues are starting to be well covered this is RG document so while I approve of the changes it would be nice to highlight the research that is still needed. Michael Regarding Marie-José's comment: I agree, and I think that we could approach this by trying to find at least one published example of research per category - ideally the "best" per category. This would show, wherever we find something, what the SoA is - research could focus on improving this SoA. Also, it would probably give us some holes - e.g., I don't think there's any much research on (e2e!) FEC "below the transport", especially using multiple CC instances as hinted on in the draft. These holes would let us identify missing research.
I see two examples of FEC below the transport, maybe am I forgetting other ones. SUNDARARAJAN, Jay Kumar, SHAH, Devavrat, MÉDARD, Muriel, et al. Network coding meets TCP: Theory and implementation. Proceedings of the IEEE, 2011, vol. 99, no 3, p. 490-512. (URL) There is a variant with MPTCP (URL) Tetrys (URL) can be used below the transport as a tunnel as discussed here: URL For the use of FEC inside the transport I know that there is a use of FEC with RTP and WebRTC, I saw it in the source code of some browsers but I don't know a well-cited research paper about this. There are RFCs however: URL and this very short article: URL For QUIC, I know three articles proposing FEC inside the transport: Michel, F., De Coninck, Q., & Bonaventure, O. (2019, May). QUIC-FEC: Bringing the benefits of Forward Erasure Correction to QUIC. In 2019 IFIP Networking Conference (IFIP Networking) (pp. 1-9). IEEE. (URL) -> use of a RECOVERED frame to indicate when a packet is recovered and does not hide the losses to the congestion control GARRIDO, Pablo, SANCHEZ, Isabel, FERLIN, Simone, et al. rQUIC: Integrating FEC with QUIC for Robust Wireless Communications. In : 2019 IEEE Global Communications Conference (GLOBECOM). IEEE, 2019. p. 1-7. (URL) -> they seem to hide the congestion-induced losses to cubic using FEC to increase their bitrate (but no clear discussion on that) PALMER, Mirko, KRÜGER, Thorben, CHANDRASEKARAN, Balakrishnan, et al. The quic fix for optimal video streaming. In : Proceedings of the Workshop on the Evolution, Performance, and Interoperability of QUIC. 2018. p. 43-49. (URL) -> No clear discussion on what is done regarding the congestion control (i.e. are the recovered pacekts ACKed or not ?). I am not really into this one as they basically state that using TCP for video streaming does not work well in general even with cases under 1% of losses and make claims such as this one: Do not hesitate if you have other references. I think one good research "advice" we could point out is to include a discussion concerning the impact of the proposed FEC solution on the congestion control, especially loss-based congestion control such as cubic. There is often no discussion on that.
A new section on open research questions has been added
Some more, I think they're all "Inside transport": Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, E., and R. Govindan, "Reducing Web Latency: the Virtue of Gentle Aggression", Proceedings of the 2013 ACM SIGCOMM , 2013. (I think that's the same work as the now-expired draft-flach-tcpm-fec ) Ferlin S, Kucera S, Claussen H, Alay Ö. MPTCP meets FEC: Supporting latency-sensitive applications over heterogeneous networks. IEEE/ACM Transactions on Networking. 2018 Aug 29;26(5):2005-18. (this extends the Flach et al idea of "instant recovery" to MPTCP) Baldantoni L, Lundqvist H, Karlsson G. Adaptive end-to-end FEC for improving TCP performance over wireless links. In2004 IEEE International Conference on Communications (IEEE Cat. No. 04CH37577) 2004 Jun 20 (Vol. 7, pp. 4023-4027). IEEE. Sato Y, Koga H, Ikenaga T. TCP using adaptive FEC to improve throughput performance in high-latency environments. IEICE Transactions on Communications. 2018.
For a high-level overview of this research, see: URL

Revised text:
CC, FEC in CC, FEC below CC), the impact of reliable transport on the FEC reliability mechanisms is different. <ins> 2.3. </ins> The application layer may be composed of several streams above FEC and transport layers instances.  The different streams could exploit different paths between the sender and the receiver or not.  The transport layers instances is out of the scope of the document and not further described.  <ins> 2.4. RFC8406 summarizes recommended terminology for Network Coding conceps and constructs.  In particular, the document identifies the following coding types (among many others): Block Coding: Coding technique where the input Flow must first be segmented into a sequence of blocks; FEC encoding and decoding are performed independently on a per-block basis. Sliding Window Coding: general class of coding techniques that rely on a sliding encoding window. The decoding scheme may not be able to decode all the symbols.  The chance of decoding the erased packets depends on the size of the encoding window, the coding rate and the distribution of erasure in the transmission channel.  The FEC channel may enable the transmission of information related to the need of supplementary symbols to adapt the level of reliability.  Partial and full reliability could be envisioned. Full reliability: The receiver may hold symbols until the decoding of source packets is possible.  In particular, if the codec does not enable a subset of the linear system to be inverted, the receiver would have to wait for a certain minimum amount of repair packets before it can recover all the source packets. Partial reliability: The receiver cannot deliver source packets that could not have been decoded to the upper layer.  If the size of the encoding window (for Sliding Window Coding) and the size of the blocks (for Block Coding) are large, the chances of recovering the erased symbols would increase.  However, this would impact on memory requirements and the cost of encoding and decoding processes. 2.5. </ins> Traffic from or to different end users may share various types of bottlenecks.  When such a shared bottleneck does not implement some coding rate of a FEC mechanism could be adapted based on inputs from the application and the trade-off between latency and packet loss. Partial reliability impacts the type of FEC and type of codec that  <ins> can be used, such as discussed in subsec:def_code. </ins> 3.7. example, the reliability offered by FEC may be sufficient, with no retransmission required.  This depends on application needs and the trade-off between latency and loss.  Partial reliability impacts the  <ins> type of FEC and type of codec that can be used, such as discussed in subsec:def_code. </ins> 4.7. partial reliability only.  In this case, FEC may provide an unnecessary service if it is not aware of the reliability requirements.  Partial reliability impacts the type of FEC and type  <ins> of codec that can be used, such as discussed in subsec:def_code. </ins> 5.7. (1) reducing goodput when useless repair symbols are transmitted and (2) helping to recover from transmission and congestion losses.  <ins> 6.2.1. There is a trade-off related to the amount of redundancy to add, as a function of the transport layer protocol and application requirements. RFC8095 describes the mechanisms provided by existing IETF protocols such as TCP, SCTP or RTP.  RFC8406 describes the variety of coding techniques.  The important level of combinations makes the determination of an optimum parameters derivation very complex.  This depends on application requirements and deployment context. Appendix C of RFC8681 describes how to tune the parameters for target use-case.  However, this discussion does not integrate congestion- controlled end points. Research question 1 : "Is there a way to dynamically adjust the codec characteristics depending on the transmission channel, the transport protocol and application requirements ?" Research question 2 : "Should we apply specific per-stream FEC mechanisms when multiple streams with different reliability needs are carried out ?" 6.2.2. Recovering lost symbols may hide congestion losses from the congestion control.  Disambiguating acked packets from rebuilt packets would help the sender adapts its sending rate accordingly. There are opportunities for introducing interaction between congestion control and coding schemes to improve the quality of experience while guaranteeing fairness with other flows. Some existing solutions already propose to disambiguate acked packets from rebuilt packets QUIC-FEC.  New signaling methods and FEC- recovery-aware congestion controls could be proposed. Research question 3 : "Should we quantify the harm that a coded flow would induce on a non-coded flow ? How can this be reduced while still benefitting from advantages brought by FEC ?" Research question 4 : "If transport and FEC senders are not collocated, if the FEC is applied only on the last mile, would this raise fairness issues ?" Research question 5 : "Should we propose a generic API to allow dynamic interactions between a transport protocol and a coding scheme ? This should consider existing APIs between application and transport layers." </ins> 6.3.