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.

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

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.


2.1. fig:sep-channel presents the notations that will be used in this <del> document and introduces the Congestion Control (CC) and Forward Erasure Correction (FEC) channels.  The Congestion Control channel carries source packets from a sender to a receiver, and packets signaling information about the network (number of packets received vs. lost, Explicit Congestion Notification (ECN) marks, etc.) from the receiver to the sender.  The Forward Erasure Correction channel carries repair symbols (from the sender to the receiver) and </del>  information from the receiver to the sender (e.g. signaling which packets have been repaired, loss rate prior and/or after decoding, <del> etc.). </del>  Inside a host, the CC and FEC entities can be regarded as conceptually separate: coding rate that is used by the FEC solution (i.e.  proportion of transmitted symbols that carry useful data). <del> 'source and/or repair symbols' (data plane for both the FEC and the CC): refers to the data that is transmitted.  The sender can decide to send source symbols only (meaning that the coding rate is 0), repair symbols only (if the solution decides not to send the original source packets) or a mix of both. </del>  The inputs to FEC (incoming data packets without repair symbols, and signaling from the receiver about losses and/or repaired symbols) are 2.3. The application layer may be composed of several streams above FEC <del> and transport layers instances.  The different streams could exploit different paths between the sender and the receiver or not.  The document considers one application layer stream as input packets above a combination of FEC and transport layers.  In fig:multi-scope, each of stream 1 and stream 2 are considered in the scope of the document but a combination of stream 1 and stream 2 is not.  The case of multiple application level streams above multiple FEC and transport layers instances is out of the scope of the document and not further described. </del>  2.4. be envisioned. Full reliability: The receiver may hold symbols until the decoding <del> 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. </del>  2.5. services. This approach requires that the transport protocol does not implement <del> a fully reliable data transfer service (e.g., based on lost packet retransmission).  QUIC with unreliable datagram extension I-D.ietf- quic-datagram is an example of a protocol for which this is relevant. In cases where QUIC traffic is blocked and a fall-back to TCP is proposed, there is a risk for bad interactions between TCP's full reliability and coding schemes.  For reliable transfers, coding usage does not guarantee better performance; instead, it would mainly reduce goodput. </del>  3.1. 3.2. <del> The congestion control mechanism may not be able to differentiate repair symbols from actual source packets.  The relevance of adding coding at the application layer is related to the needs of the application.  For real-time applications using an unreliable or partially reliable transport, this approach may reduce the number of losses perceived by the application. </del>  3.3. 4.6. <del> The application may require partial reliability.  In this case, the transport and FEC mechanisms could be conjointly designed.  As one 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 type of FEC and type of codec that can be used, such as discussed in subsec:def_code. </del>  4.7.

I think this PR solves most of the issues that have been raised (and will close them if we merge this PR). What do you think NAME NAME NAME ?
I'm ok with whatever all others decide :)
In section 4.6: With coding, you can recover packets a-priori and a-posteriori, so I do not see any conjoint design between coding and the transport layer: if you replace the retransission mechanism by coding, you are more general as you can also recover packets a-priori and coding can offer full reliability if needed or partial reliability if the full reliability is not necessary. So I do not see any need of a conjoint design here: simply replace the retransmission-based reliability mechanism by the coding-based one. I do not really understand what we are trying to say here talking about a conjoint design. What do you think ?
I don't get it either... could we just remove this?
Commit URL in PR could solve it all.
It is a bit complicated for me to understand correctly the details of Figure 6 : In my opinion, the app does not sublit packets nor a sending rate to the transport layer, so the two arrows above the sender seem a bit weird for me. The app generally submits data, sometimes messages and maybe a minimal transmission rate but it is the transport layer that packetizes the data and sends packets. I guess that the arriws between the sender and the receiver are the wire or the layers below transport. Thus I would replace "source and/or repair packets" by "packets containing source and/or repair symbols" Did I misunderstand the Figure ?
I agree; I think the "sending rate" arrow can be removed (I'd say that the rate is at least implicit, in how fast the application gives data to the stack, but this just complicates matters - no need for this arrow anyway). I also think that "source packets" could just be "data" (next to the arrows on the top). This applies to figure 5 too ("source packets" can be replaced with "data" next to these arrows), and in figure 3, in the top left corner, the arrow could also be called "data" instead of "source packets".
There have been some changes due to the issue - I proposed a commit URL and commit URL in pr to clarify the unnecessary arrow.
In section 3, we can read the following: I would emphasize on en in-order delivery which is the real problem for FEC here, as a reliable messaging system without in-order delivery would work. I would thus replace the parenthesis by the following:
I agree but I'd use a different replacement: I think it's good to point out that this is about reliability from something different than coding, and the in-order issue is more than just a refinement in the bracket. So, I would suggest the following: a fully reliable in-order data transfer service (e.g., like TCP).
Dealt with in commit URL of PR
In section 2.4, we say the following: Either I misunderstood the statement or the sentence is not true. In my opinion, with an equal number of sent repair symbols, if the window/block size is larger, the recovery probability is lower as they are likely more lost source symbols in the window/blocks (with a fixed number of repair symbols).
Could be clarified by commit URL of PR
In section 2.4 : Why are we talking about a linear system here ? To be more general on the recovery algorithms that are used, maybe should we use the term "block or window" instead of "linear system" What do you think ?
The commit URL of PR makes it more general.
I am not totally sure of the meaning of section 2.3 and Figure 4. More specifically: are we saying that multiple data streams transiting through one single protocol instance are out of the scope of the document ? Do we consider only one single stream on one single protocol instance ? If this is the case, does that mean that we do not consider QUIC's use-case ? What makes me think all of this is the following sentence:
I hope PR and in particular commit URL clarifies everything
In section This is an echo from a previous issue that was not really addressed or "resolved". I will rephrase the problem from scratch and let me know if you agree with me or not. :-) We describe the FEC channel (maybe should we call it the Coding channel as repair symbols could also be sent a-posteriori) and say that it carries repair symbols while the CC channel carries source packets. What do you think of rephrasing it like the following: "The CC channel carries network packets and the coding channel carries source symbols and repair symbols" ? source symbols are an abstract view on the application (and sometimes control) data that we want to protect. For example, several source symbols could be present in a single network packet, or several network packets could form one single source symbol. This is why network packets can be very different than source symbols. This also goes in our vision that CC and NC are separated channels and separated entities: they do not even share the concept of packets. What do you think ?
I agree there was some confusion here. I tried to solve this in commit URL of PR
Thank you for this great PR. Only one comment, otherwise this is good for me !

2.1. fig:sep-channel presents the notations that will be used in this  <ins> document and introduces the Forward Erasure Correction (FEC) and Congestion Control (CC) channels.  The Forward Erasure Correction channel carries repair symbols (from the sender to the receiver) and </ins> information from the receiver to the sender (e.g. signaling which packets have been repaired, loss rate prior and/or after decoding,  <ins> etc.).  The Congestion Control channel carries network packets from a sender to a receiver, and packets signaling information about the network (number of packets received vs. lost, Explicit Congestion Notification (ECN) marks, etc.) from the receiver to the sender.  The network packets that are sent by the Congestion Control channel may be composed of source packets and/or repair symbols. </ins> Inside a host, the CC and FEC entities can be regarded as conceptually separate: coding rate that is used by the FEC solution (i.e.  proportion of transmitted symbols that carry useful data).  <ins> 'network packets' (output data plane for the CC): refers to the data that is transmitted by a CC sender to a CC receiver.  The network packets may contain source and/or repair symbols. 'source and/or repair symbols' (data plane for the FEC): refers to the data that is transmitted by a FEC sender to a FEC receiver. The sender can decide to send source symbols only (meaning that the coding rate is 0), repair symbols only (if the solution decides not to send the original source symbols) or a mix of both. </ins> The inputs to FEC (incoming data packets without repair symbols, and signaling from the receiver about losses and/or repaired symbols) are 2.3. The application layer may be composed of several streams above FEC  <ins> and transport layers instances.  The transport layer may exploit a multipath mechanism.  The different streams could exploit different paths between the sender and the receiver or not.  This section describes what is in the scope of this document in regards with multi-streams applications and multipath transport protocols. The different combinations between multi-stream applications and multipath transport are the following: (1) one application layer stream as input packets above a combination of FEC and multipath (Mpath) transport layers (fig:multi-scope-single-stream), and (2) multiple application layer streams as input packets above a combination of FEC and multipath (Mpath) or single path (Spath) transport layers (fig:multi-scope-multi-stream).  In fig:multi-scope- single-stream, each of stream 1 and stream 2 are considered in the scope of the document.  In fig:multi-scope-multi-stream, the case with single path transport is considered in the scope of this document but the cases with mutipath transport is not.  The case of multiple application level streams above multiple transport layers instances is out of the scope of the document and not further described. </ins> 2.4. be envisioned. Full reliability: The receiver may hold symbols until the decoding  <ins> of source symbols is possible.  In particular, if the codec does not enable a subset of the 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 symbols. Partial reliability: The receiver cannot deliver source symbols that could not have been decoded to the upper layer.  For a fixed size of encoding window (for Sliding Window Coding) or of blocks (for Block Coding) containing the source symbols, increasing the amount of repair symbols would increase the chances of recovering the erased symbols.  However, this would impact on memory requirements, on the cost of encoding and decoding processes and on the network overhead. </ins> 2.5. services. This approach requires that the transport protocol does not implement  <ins> a fully reliable in-order data transfer service (e.g., like TCP). QUIC with unreliable datagram extension I-D.ietf-quic-datagram is an example of a protocol for which this is relevant.  In cases where QUIC traffic is blocked and a fall-back to TCP is proposed, there is a risk for bad interactions between TCP's full reliability and coding schemes.  For reliable transfers, coding usage does not guarantee better performance; instead, it would mainly reduce goodput. </ins> 3.1. 3.2.  <ins> The congestion control mechanism receives network packets and may not be able to differentiate repair symbols from actual source ones.  The relevance of adding coding at the application layer is related to the needs of the application.  For real-time applications using an unreliable or partially reliable transport, this approach may reduce the number of losses perceived by the application. </ins> 3.3. 4.6.  <ins> The application may require partial reliability.  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 type of FEC and type of codec that can be used, such as discussed in subsec:def_code. </ins> 4.7.


Abstract <del> This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG).  The scope of the document is end-to-end communications: coding for tunnels is out-of-the scope of the document. </del> Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  Using coding can be a useful way to better deal with tail losses or with networks with non- congestion losses.  However, coding mechanisms should not hide congestion signals.  This memo offers a discussion of how coding and <del> congestion control interact. </del>  <del> 1. </del>  <del> This document represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. </del>  There are cases where deploying coding improves the quality of the <del> transmission.  As an example, the server may hardly detect tail losses that impact may impact the application layer [MICHAEL: I don't understand this.  Why would it not detect them?  And why is detecting them the problem?].  Another example are networks where non- congestion losses are persistent and prevent a sender from exploiting the link capacity.  RFC5681 defines TCP as a loss-based congestion control; because coding repairs such losses, blindly applying it may easily lead to an implementation that also hides a congestion signal to the sender.  It is important to ensure that such information hiding does not occur. </del>  Coding is a reliability mechanism that is distinct and separated from <del> the loss detection of congestion controls.  This memo discusses simple best practices on how coding and congestion control mechanisms could coexist.  One objective is to help the research community </del>  consider congestion control aspects when proposing coding solutions. <del> The proposed recommendations apply for coding at the transport or application layer.  Coding for tunnels is out of scope for the document. </del>  2. fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward Erasure Correction (FEC) channels.  The Congestion Control channel <del> carries data packets (from a server to a client) and a potential </del>  information signaling the packets that have been received (from the client to the server).  The Forward Erasure Correction channel carries coded packets (from the server to the client) and a Inside a host, the CC and FEC entities can be regarded as conceptually separate: <del> As this diagram shows, the inputs to FEC (data to work upon, and signaling from the receiver about losses and/or repaired blocks) are distinct from the inputs to CC.  The latter calculates a sending rate or window from network measurements, and it takes the data to send as input, sometimes along with application requirements such as upper/ lower rate bounds, periods of quiescence, or a priority. </del>  It is not clear that the ACK signals feeding into a congestion control algorithm are useful to FEC in their raw form, and vice versa algorithm.  However, there can be meaningful other interactions (indicated by the horizontal double arrow) between the two entities, usually as a result of their operation rather than by relaying their <del> own raw inputs.  For example, the network measurements carried out by CC can yield a longer-term statistical measure such as a loss ratio which is useful input for a FEC coding scheme.  Similarly, unequal error protection using fountain codes can be used to assign different priorities to blocks of data, and these priorities can be honored by a CC mechanism. </del>  3. added at the server and client end points.  The discussions should then consider fairness with non-coding solutions. <del> 4. </del>  <del> The solution can be described as follows: [MICHAEL: So far, it hasn't been clear that we're going to describe a "solution".  A solution to which problem?  I thought we're only discussing how FEC and CC relate.] </del>  <del> The client indicates to the server that one or multiple packets have been repaired using a coding scheme.  The "repaired packet" signal does not guarantee that the packet actually needed to be repaired, since it could have been delayed but not lost. </del>  <del> The server must be able to detect the "repaired packet" signal. The base solution does not describe how the congestion control reacts to such signal. </del>  <del> The rationale behind this solution is the following: the server has more information on the congestion status and the application characteristics.  Moreover, congestion control should not be split between multiple entities, as otherwise non-optimized decisions may be taken. </del>  <del> The proposed solution applies for coding in the transport and application layers.  The proposed approach is in-line with the one in I-D.swett-nwcrg-coding-for-quic.  The proposed solution does not apply for the interaction between coding under the transport layer (i.e. not end-to-end), such as coding for tunnels. </del>  5. <del> This section presents solutions for a server to add application coding. 5.1. In this solution, the coded packets are sent on top of what is allowed by a congestion window.  Examples of the solution could be adding a given percentage of the congestion window as supplementary packets or sending a given amount of coded packets at a given rate. The redundancy flow can be decorrelated from the congestion control that manages source packets: a secondary congestion control can be introduced, such as in coupled congestion control for RTP media I- D.ietf-rmcat-coupled-cc.  An example would be to exploit a lower than best-effort congestion control RFC6297. The advantage of such a solution is that coding would help in challenging cases where transmission losses are persistent. The drawback of such a solution is that it may result in coding solutions being unfair towards non-coding solutions.  This solutions may result in adding congestion in congested networks. </del>  <del> 5.2. </del>  <del> In this solution, the coded packets are sent within what the congestion window allows, such as in CTCP.  Examples of the solution would be sending coded packets when there is no more data to transmit or preferably send coded packets instead of the following packets in the send buffer. The advantage of this solution is that it does not add more traffic than the congestion window allows.  Indeed, all traffic (source and redundancy) is controlled by one congestion control only and TCP metrics for fairness can be indifferently applied in this case. The main drawback is the decrease of goodput if coded packets are sent but are not used at the client side. </del>  6. <del> [MICHAEL: I would remove this section entirely: it only adds to confusion.  If the inputs are seen as distinct, and we say that the raw inputs shouldn't be shared, then why would one even think about what delay-based CC does with this input?  It's just not the right input.]  Delay-based congestion controls ignore packets that have been repaired with coding.  There is no need to define best current pratices in this case.  However, more discussions are required for congestion controls that use loss as congestion signals (potentially among other congestion detection mechanism). 6.1. [MICHAEL: As above, lets remove all of this please.  This text gets in the way of a clean separation.]  In this solution, the server reacts to repaired packet signals as to congestion-implied packet losses.  That being said, this does not necessarily mean that the packets have actually been lost.  The server may have other means to identify that the packet was just out-of-order and ignore the repaired packet signals. The advantages of the solution are (1) that coding mechanisms do not hide congestion signals, such as packets voluntary dropped by a AQM RFC7567 and (2) packets may be repaired faster than with a traditional retransmission mechanisms. The drawback of this solution is that, if there is a high non- congestion loss rate, the congestion control throughput may decrease drastically.  Reporting this amount of loss to a server may reduce the application goodput when there is no actual congestion. 6.2. [MICHAEL: this is even just a terrible idea.  There's no good rationale to back off less when a packet is repaired.]  In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. The advantage of the solution is that in cases where there is no actual congestion, coding could help in improving the transmission without ignoring congestion signals. The main drawback is the precised design of the solution and its interaction with AQM mechanisms RFC7567.  Moreover there may be fairness issues since AIMD convergence may not be guaranteed. 6.3. [MICHAEL: as above, also here, the signals are discussed as going into both blocks, leading to a strange unification of things that shouldn't be together.  Let's remove this.  Also, the idea of ignoring packet loss for CC is appalling anyway.]  This is the case for delay-based congestion controls.  The interaction between delay- based congestion controls and the delay induced by a coding mechanisms is an open research activity.  That being said, a potential approach would be that loss-based congestion control ignores the "repaired packet" signal. The advantage of this solution is that coding would provided substantial benefits in cases where there are transmission losses. However, this solution hides potential congestion losses, making it unfair to other congestion controls. 7. </del>  <del> [MICHAEL: I'm sorry to say that I find this table to be in the same style, of wrongly mixing things together, and would like to see it removed altogether.]  This section provides a summary on the content in previous sections.  The fig:summary sums up some recommendations. It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit. Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </del>  <del> 8. </del>  This memo includes no request to IANA. <del> 9. </del>  There is no security considerations required for this document.

Thanks so much for doing this! If you incorporate my comments, you've written exactly what I wanted to do, you've just taken the work from me :)
SD: We discussed in many RFC congestion control. I encourage you to include scalable congestion control and the IETF history on the reaction to ECN signals. EL: Good point.
I was talking to Gorry Fairhurst afterwards, and Gorry told me what I SHOULD have said, was that the sender should perform whatever its response to congestion would be - if it's an old-style sender, treat recovery as loss, but if it supports scalable congestion control (L4S is one example), it doesn't have to treat recovery as loss - it just needs to do something appropriate.
Gorry's point sounds like "the congestion control reaction is what it is, it has nothing to do with coding", and I'd agree with that. I would therefore not talk much about different types of cc. in the document, as this may just add more confusion.
I think that this is covered by the current version of the document. "The server MUST be able to detect the "repaired packet" signal. The base solution does not describe how the server reacts to such signal."
I may have forgotten things over the holidays, so I'm not sure how clear the document is on that ... but I don't like the sentence that you quote because it sounds like "repaired packet" is a different kind of signal than "lost (and not repaired) packet". For congestion control, that distinction shouldn't exist. I see coding and CC as two separate layers, benefiting from different signals.
If I remember well, we formulated this sentence this way : 1) to start reactions and discussions as it is quite a strong claim as Nico said it during the meeting 2) adding the "repaired" signal does not seem to me to interfere with the other signals: it is just an additional signal that can be ignored by the congestion control. A "repaired" packet does not imply a lost packet (the repair could be due to re-ordering), a lost packet will be determined by the loss detection mechanism. So in my opinion, we can have different cases for repaired packets : a lost and repaired packet: the packet has been both repaired and detected as lost (the loss detection may happen before of after the loss detection, it does not matter). Even if the packet is repaired, it can still be marked as lost by the loss detection mechanism because "repair" does not mean the same as an acknowledgement. a non-lost repaired packet (re-ordering implied the repair of the packet but the original packet has been received afterwards) A loss-based congestion control will likely attach itself to the "lost packet" event that will be triggered regardless of the fact that the packet has been repaired, so I don't think it will be perturbated in any way by the "repaired packet" event. In my opinion, a congestion control mechanism could also attach itself to the "repaired" event to do whatever it wants with this additional signal (I have no idea on what it could do with this signal, but a new congestion control could define some heuristics based on the different signals occuring during the connection). I'm saying this with QUIC in mind, it may be more difficult to not mix the "repaired" and "lost" events with TCP (but is seems doable to me a-priori).
I think I'll insist on this point. This is exactly the clarity that's missing in this document: because coding and congestion control are discussed as a conflated whole, it sounds as if, e.g., the difference between "lost but repaired" and "lost but not repaired" might matter to a congestion control mechanism. You even suggest that a new control could do something useful with it; why?? What value does it add, when a congestion control mechanism tries to find the right sending rate based on how full the network is? The two are really entirely separate and should be discussed and presented as such. Implementations may produce the signals you describe, such that their senders can then pick them apart to do what is most reasonable; that doesn't change the fact that conceptually, these are completely separate and discussing them as a combo makes it all confusing and even misleading. This is exactly the confusion the NWCRG has been dealing with for so long. Let's please clear this up once and for all and split these beasts.
I think we need to be sure about the current scope of the draft then. The main idea we wanted to bring with the other guys (correct me if I'm wrong) was to avoid interferences between the coding and congestion control mechanism, especially avoiding a receiver that simply ACKs recovered packets, making the sender think that they have been successfully received. I agree with you, defining a "repaired" signal may lead to think that we consider those two mechanisms as whole. So why defining a "repaired" signal instead of saying that "acknowledging a recovered packet should not be done" ? We discussed this with NAME and NAME and we concluded that defining the "repaired" signal seemed easier to incorporate within a protocol such as TCP compared to the other solution that requires major design changes. With QUIC, we can incorporate the two solutions without any problem. I agree that the current state of the draft is misleading I am OK to change that. We need however to keep in mind the feasibility of the solution on existing protocols. When we started to elaborate the draft with NAME and NAME (again, correct me if I'm wrong) and until now, we decided that determining what the congestion control behaviour should be was out-of-scope for the document. The scope was just the following: we should not hide the recovery/loss signal so that the already existing congestion control mechanisms react the exact same way to losses whether there is coding or not. For the rest, we did not take any decision. This is why you will see many different behaviours described in the current section 6. of the draft (e.g. 6.2.). Until now, we never discussed whether these solutions are good or bad, as they are congestion control behaviours and we are working on the coding component (more specifically what signalling should be done between coded hosts). We just presented them. Because the approach of the document was to avoid interferences between the coding and congestion control mechanisms, not to decide what a congestion control should do or what set of signals it should or should not use. But don't get me wrong, I am not saying that using the "repaired" signal for a congestion control is a good idea. I am fine with the idea of recommending to not use such a signal in congestion controls, but to me, it redefines the scope of the document and might imply other groups than the nwcrg.
I think what I'm suggesting is less problematic than you may believe. To me, some parts of the draft are currently messy because of how they mix the two things - e.g. fig. 2 really hurts my feelings, as a cc. person :) Don't get me wrong, I agree with many things in the draft, and with most of what you say in your comments here too - e.g. this: "especially avoiding a receiver that simply ACKs recovered packets, making the sender think that they have been successfully received." is definitely an important goal! This statement from your comment best describes why we seem to have a disconnect: " I agree that the current state of the draft is misleading I am OK to change that. We need however to keep in mind the feasibility of the solution on existing protocols." because what I'm proposing changes implementation feasibility in no way. This is just conceptual - how we talk about things. Coding can (sigh... if it MUST... ) fit into TCP because TCP does error control, not because TCP does congestion control. I can see one useful input from coding to cc: an "importance" (or urgency?) associated with a data block. I can see useful inputs from cc to coding: network measurements (which is what cc carries out). That's how these things should be described IMO - conceptually separate blocks with interfaces. Implementations can definitely build a compound "repaired" signal which has a meaning to both blocks at the same time, and I don't object to giving implementation examples or advice after introducing things cleanly and separately. But these, concept and implementation, are also two separate things. As for the scope, that's nothing to worry about. This is not about telling a cc. mechanism what to do - it's about explaining the relationship between coding and cc, and that won't change if we re-structure things as I suggest. I'm beginning to think that I should just make a PR where I update everything the way I think it should be, and then we can have a much more focused discussion? Would that be ok? (next week or so... probably not before)
100% agree. I'm beginning to think that I should just make a PR where I update everything the way I think it should be, and then we can have a much more focused discussion? Would that be ok? (next week or so... probably not before) Perfect for me, I do not plan to modify the draft during that time anyway.
+1 I think that the separation of the "congestion" and "coding" channels can help in clarifying there is a difference here. +1 We need to make that clear in the document. (next week or so... probably not before) Ok - I may do some update on master branch before next week
Just to be clear "lost but repaired" is an erased packet rebuilt at destination, erased means it thus can be either a reordered or a lost packet.
Okay, but then there's also the case of "lost but NOT repaired", which is also an erased packet, i.e. either reordered or lost. These two cases are, and should absolutely be, the same for a congestion controller. This is why I don't like feeding "repaired" into a CC.
OK I think I see the problem : you are on the CC-side and we are on the NC-side :) First, I recall we agreed that there are two different signaling paths: one for CC one for NC. A lost but not repaired packet is an erased packet and we don't have any supplementary info at the sender side to provide because the CC will provide it. A lost but rebuilt is a lost packet lost or reordered and we must provide the info at the sender side because the CC won't provide it.
Oh yeah, I see that you (NCers) need the signal! But it needs to be separate from the CC signal. I'm glad to see that you say this was agreed - and the early part of the draft reflects that, but later in the draft (from section 6) things get really mixed up, which is why propose to remove sections 6 and 7.
Not only, when I say "/A lost but rebuilt is a lost packet lost or reordered and we must provide the info at the sender side because the CC won't provide it./" means that the NC receiver needs to alert the sender CC that a lost or a reorder (following the CC flavor used) occurred. This allows the sender to react in a compliant manner as TCP will do. One possible solution would be the NC receiver marks ECN when a packet is rebuilt to inform the sender as explained in my previous NWCRG talk : URL
That's very implementation oriented. Of course, if you want to hack your stuff into TCP and leverage TCP ACKs yet convey that CC. should reduce its rate, you can use tricks like ECN. I would prefer to first discuss these things as entirely conceptually separate - and then, once it's all neat and clean, discuss possible implementation strategies such as this one.
Agree, I showed this just to be sure we lay on the same thread and that all of us (whatever the point of view is from CC or NC) are speaking the same language.
ACK!
One question still remains, what do we do with section 6 which is also implementation oriented and cross-layer. As far as I understand your point, we should not speak or propose such cross-layer schemes as both layers : CC and NC should remain independent right ? Furthermore I'm not happy with the beginning "Delay-based congestion controls ignore packets that have been repaired with coding.". If we lay on the same logic, delay-based should not ignore these packets as a rebuilt one, following the code used and (n,k) length might artificially increase the e2e delay. In that case, one could argue that a rebuilt packet implicitly signal a rebuilt packet to the sender as the delay increase, but this really depends on the kind of code used and its parameters. The more I read this section the more I think we should reconsider it.
cross-layer schemes as both layers : CC and NC should remain independent right ? Yes - I think we CAN then have a section (a new one! I would really rather just dump the current text of sections 6 and 7) that VERY carefully discusses how to implement things together. But then there would have to be text saying that this is implementation only, still the signals are conceptually separate, something like that. For the next version of the draft, I wouldn't even do that but just clean things up (i.e., remove these sections). controls ignore packets that have been repaired with coding.". If we lay on the same logic, delay-based should not ignore these packets as a rebuilt one, following the code used and (n,k) length might artificially increase the e2e delay. In that case, one could argue that a rebuilt packet implicitly signal a rebuilt packet to the sender as the delay increase, but this really depends on the kind of code used and its parameters. You should look at my pull request. Let's see if this URL survives copy+pasting: URL Here, this paragraph now begins with: "[MICHAEL: I would remove this section entirely: it only adds to confusion." :-)
Got all your comments from sections 6-7 and others, I think I see what you mean. Let's restart first considering this comment -> [MICHAEL: So far, it hasn't been clear that we're going to describe a "solution". A solution to which problem? I thought we're only discussing how FEC and CC relate.] Let's re-discuss only how FEC and CC relate, this is what we attempted to do but may be badly.
So I guess the way ahead is to discuss - in the PR - what changes to the PR are desired. If I don't hear any more details by next week, I'll submit an update to the PR where, instead of commenting that sections 6 and 7 should be removed (and why), these sections are gone. What do y'all think about the new diagram, on page 4, and the two paragraphs just below it? This captures how I think about things. Mainly, my take-away is that yes, there may be meaningful interaction between FEC and CC, but no, it's not obviously a matter of sharing the "raw inputs". Instead, e.g. (as one example I'm mentioning), unequal error protection can be an input to CC, as a result of what a fountain code produces. ( an example: chapter 8 of this Ph.D. thesis: URL ... yes, this is me showing off a little, trying to make the point that I'm not COMPLETELY coding illiterate :-) only 90% ! )
There is a fundamental difference between UEP and what we are targeting here, the application of UEP is similar to AL-FEC so there is no interaction at all with a CC as both work at the application layer and I think nothing really new to discuss. Furthermore, UEP needs information about the flow data packet itself which is not our case as we are flow agnostic. In brief, this draft does not tackle AL-FEC. The problem is the use of FEC, RLNC, Tetrys or Sliding Window Code (RFC8680 and 81) below or inside the transport layer. The diagram page 4 shows such AL-FEC application (BTW I would change "information about repaired block" by "information about repaired ratio" to be generic and compliant with SW codes). Consider that you reverse both blocks FEC and CC in your figure, do you see what happens in that case ?
This is getting more interesting. About UEP: interaction at all with a CC as both work at the application layer and I think nothing really new to discuss I think that UEP can assign different priorities to blocks of data, such that they can be more or less important, which could lead to a CC decision to treat some of them with LBE, for example? (RFC8680 and 81) below or inside the transport layer. while I'm admittedly thinking "above". But I placed them next to each other to avoid having to make a layering decision, as it's about separating functionality more than it is about which one is on top of which (which strikes me as more of an implementation decision and less conceptual). "information about repaired block" by "information about repaired ratio" to be generic and compliant with SW codes ACK, will do! About the diagram on page 4: both blocks FEC and CC in your figure, do you see what happens in that case ? No, I don't get it - the idea was to show them side by side so they don't convey a sequence of operation. So in my interpretation, changing their position won't change anything. Or what do you mean?
I think I get a good take-away from this conversation: I keep talking about separating functionality, you keep talking about layering. And, I think we all agree that we want a section discussing implementation possibilities. So, my proposal is to discuss layering there, regarding the transport layer where CC is usually done. 1) FEC above transport, 2) FEC inside transport, 3) FEC below transport. Then we can have a discussion about various issues in this section, but this way it's a clean framework for such text.
I like your proposition of layering. I think that the problem of the first version of the draft was that we tried to consider everything at once. This should be a lot more clear with such a séparation.
Great! I wanted to do it now but I'm running out of time... early next week, promise!
Le 17/01/2020 à 09:22, mwelzl a écrit : Perfect ! I think we start to converge.
Sorry for my late answer - I was sick at the end of the week and could hardly manage all I wanted to deal with .. I caught up with the discussions and think there are some things that we all agree on. I will then merge the pull request so that we can separately work on the document.
I have tried to clean and reorganize the document based on what I think we agree on. See PR Let me know what you think. In case you agree, I guess I can merge it with master so that we have a new basis to go on with.
Once PR is merged to master, I propose to close this issue.
GREAT, thanks!!!

Abstract  Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  Using coding can be a useful way to better deal with tail losses or with networks with non- congestion losses.  However, coding mechanisms should not hide congestion signals.  This memo offers a discussion of how coding and  <ins> congestion control can coexist. </ins>  <ins> This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG).  The scope of the document is end-to-end communications: coding for tunnels is out-of-the scope of the document. </ins>  <ins> 1. </ins> There are cases where deploying coding improves the quality of the  <ins> transmission.  As an example, it may take time for the server to detect tail losses and this would impact the experience of applications using short flows.  Another example are networks where non-congestion losses are persistent and prevent a sender from exploiting the link capacity. </ins> Coding is a reliability mechanism that is distinct and separated from  <ins> the loss detection of congestion controls.  RFC5681 defines TCP as a loss-based congestion control; because coding repairs such losses, blindly applying it may easily lead to an implementation that also hides a congestion signal to the sender.  It is important to ensure that such information hiding does not occur. This memo offers a discussion of how coding and congestion control can coexist.  One objective is to help the research community </ins> consider congestion control aspects when proposing coding solutions.  <ins> This document represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard.  The proposed recommendations apply for coding at the transport or application layer.  Coding for tunnels is out of scope for the document. </ins> 2. fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward Erasure Correction (FEC) channels.  The Congestion Control channel  <ins> carries data packets (from a server to a client) and potential </ins> information signaling the packets that have been received (from the client to the server).  The Forward Erasure Correction channel carries coded packets (from the server to the client) and a Inside a host, the CC and FEC entities can be regarded as conceptually separate:  <ins> fig:sep-entities shows a example where FEC is on top of the CC, but interactions between the FEC and CC are possible.  In this example, the inputs to FEC (data to work upon, and signaling from the receiver about losses and/or repaired blocks) are distinct from the inputs to CC.  The latter calculates a sending rate or window from network measurements, and it takes the data to send as input, sometimes along with application requirements such as upper/lower rate bounds, periods of quiescence, or a priority. </ins> It is not clear that the ACK signals feeding into a congestion control algorithm are useful to FEC in their raw form, and vice versa algorithm.  However, there can be meaningful other interactions (indicated by the horizontal double arrow) between the two entities, usually as a result of their operation rather than by relaying their  <ins> own raw inputs. </ins> 3. added at the server and client end points.  The discussions should then consider fairness with non-coding solutions.  <ins> 3.3. </ins>  <ins> sec:notations presents that FEC and CC can be seen as two separate channels.  In practice, implementations may mix the signals that are exchanged on these channels.  This document discusses how FEC and CC relate.  [NK: We may want to later add that we provide recommendations - but for the moment, we may just list the server side coding solutions in the layering approach without providing recommendations for each case] </ins>  <ins> 4. </ins>  <ins> fig:fec-above illustrates the FEC above the transport case. </ins>  <ins> fig:fec-above presents an architecture where FEC is on top of the transport.  The coded packets are sent within what the congestion window allows. </ins>  <ins> TODO : ADD MORE TEXT </ins> 5.  <ins> fig:fec-in illustrates the FEC within the transport case. </ins>  <ins> fig:fec-in presents an architecture where FEC is within the transport.  The coded packets are sent within what the congestion window allows, such as in CTCP.  Examples of the solution would be sending coded packets when there is no more data to transmit or preferably send coded packets instead of the following packets in the send buffer. </ins>  <ins> TODO : ADD MORE TEXT </ins> 6.  <ins> fig:fec-below illustrates the FEC below the transport case. </ins>  <ins> fig:fec-below presents an architecture where FEC is below the transport.  The coded packets are sent on top of what is allowed by the congestion control.  Examples of the solution could be adding a given percentage of the congestion window as supplementary packets or sending a given amount of coded packets at a given rate.  The redundancy flow can be decorrelated from the congestion control that manages source packets: a secondary congestion control could be introduced underneath the FEC layer, such as in coupled congestion control for RTP media I-D.ietf-rmcat-coupled-cc.  An example would be to exploit a lower than best-effort congestion control RFC6297. </ins>  <ins> 7. </ins> This memo includes no request to IANA.  <ins> 8. </ins> There is no security considerations required for this document.


2. <del> This section describes the components in satellite system that lays on SATCOM systems dedicated to broadband Internet access that follows </del>  the DVB standards.  A high-level description of a multi-gateway <del> satellites network is provided.  There are multiple SATCOM systems, </del>  such as those dedicated to broadcasting TV or to IoT applications: depending on the purpose of the SATCOM system, ground segments are specific.  In this context, the increase of the available capacity RFC8406: End-to-End Coding (E2E), Network Coding (NC), Intra-Flow Coding (IntraF), Inter-Flow Coding (InterF), Single-Path Coding (SPC) and Multi-Path Coding (MPC).  This document refers to coding as both <del> End-to-End Coding and Network Coding, to cover cases where where recoding operation at intermediate nodes are or not.  From the UDP/IP </del>  packetization to the channel coding, link layer coding is required so that the physical-layer knows what coding scheme to use.  Following the taxonomy document RFC8406, channel and link codings are gathered techniques at a wider scale in satellite telecommunications systems. Even though this document focuses on satellite systems, it is worth <del> pointing out that the some scenarios proposed may be relevant to other wireless telecommunication systems.  As one example, the generic architecture proposed in fig:sat_gateway may be mapped to cellular networks as follows: the 'network function' block gather some of the functions of the Evolved Packet Core subsystem, while the 'access gateway' and 'physical gateway' blocks gather the same type of functions as the Universal Mobile Terrestrial Radio Access Network.  This mapping extends the opportunities identified in this draft since they may be also relevant for cellular networks. </del>  7.

A few document nits… Section 2, 1st and 2nd Sentences “in satellite system” should be “in a satellite system”. Not clear what “lays” means here. “multi-gateway satellites network” should be “multi-gateway satellite network”. (Most of the uses cases have nothing to do with multi-gateway, though.) Section 3, 2nd Sentence Delete the duplicate “where”. Section 6, 2nd Sentence “that the some scenarios” should be “that some scenarios”.
Thanks for having identified the NITS. Closed by PR

2.  <ins> This section describes the components in a satellite system based on SATCOM systems dedicated to broadband Internet access that follows </ins> the DVB standards.  A high-level description of a multi-gateway  <ins> satellite network is provided.  There are multiple SATCOM systems, </ins> such as those dedicated to broadcasting TV or to IoT applications: depending on the purpose of the SATCOM system, ground segments are specific.  In this context, the increase of the available capacity RFC8406: End-to-End Coding (E2E), Network Coding (NC), Intra-Flow Coding (IntraF), Inter-Flow Coding (InterF), Single-Path Coding (SPC) and Multi-Path Coding (MPC).  This document refers to coding as both  <ins> End-to-End Coding and Network Coding, to cover cases where recoding operation at intermediate nodes are or not.  From the UDP/IP </ins> packetization to the channel coding, link layer coding is required so that the physical-layer knows what coding scheme to use.  Following the taxonomy document RFC8406, channel and link codings are gathered techniques at a wider scale in satellite telecommunications systems. Even though this document focuses on satellite systems, it is worth  <ins> pointing out that some scenarios proposed may be relevant to other wireless telecommunication systems.  As one example, the generic architecture proposed in fig:sat_gateway may be mapped to cellular networks as follows: the 'network function' block gather some of the functions of the Evolved Packet Core subsystem, while the 'access gateway' and 'physical gateway' blocks gather the same type of functions as the Universal Mobile Terrestrial Radio Access Network. This mapping extends the opportunities identified in this draft since they may be also relevant for cellular networks. </ins> 7.


Coding enables E2E reliable communication over DTN with adaptive re- encoding, as proposed in THAI15.  In this case, the use-cases <del> proposed in subsec:varying would legitimate the usage of coding </del>  within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding inside a Consultative Committee for Space Data Systems (CCSDS)

Just corrected legitimize.
legitimate -> legitimize. This entire section is unnecessary. With this draft on a multi-gateway satellite system and DVB, you're talking about geostationary satellites which are always visible. Little disruption. 600ms or so delay is coped with by Internet protocols (RFC829 SATNET work etc.) So, not a significant delay issue either. It's out of scope for the abstract. And geostationary satellites generally don't use CCSDS for broadband; TDRSS is so much a special case. Since we're not standards track, References aren't split informative/normative -- but given the DVB starting point, I'd expect to see more DVB-S references. EN 302 307, which details extensions of the original satellite transmission standard DVB-S (EN 300 421), etc.
We need to discuss this point. Just corrected legitimize in

Coding enables E2E reliable communication over DTN with adaptive re- encoding, as proposed in THAI15.  In this case, the use-cases  <ins> proposed in subsec:varying would legitimize the usage of coding </ins> within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding inside a Consultative Committee for Space Data Systems (CCSDS)


The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: <del> ACM : Adaptative Coding and Modulation; </del>  BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; <del> CPE: Customer Premise Equipment; </del>  COM: COMmunication; ETSI: European Telecommunications Standards Institute; <del> FEC: Forward Erasure Correction; </del>  FLUTE: File Delivery over Unidirectional Transport; NORM: NACK-Oriented Reliable Multicast; <del> PEP: Performance Enhanced Proxy RFC3135 - a typical PEP for </del>  satellite communications include compression, caching and TCP acceleration;

ACM : Adaptative Coding and Modulation; -- Adaptive. This error repeats. CPE: Customer Premise Equipment; -- Premises. (My premise is that this is unfortunate.) FEC: Forward Erasure Correction;-- FEC is traditionally Error. Redefining industry terms to suit your network coding case won't help. FLUTE: File Delivery over Unidirectional Transport;-- just ref RFC6726. bit of a pointless inclusion imo. PEP: Performance Enhanced Proxy [RFC3135]-- the title of RFC3135 is perfectly clear that it's Enhancing and the word 'Enhanced' does not appear in that document. This is not the sort of thing WGLC is for. PLFRAME - see below. Odd to see mention of PLFRAME but not FECFRAME, which is a more direct translation of the packet data.
I have corrected the accronyms in PR We do not mention FECFRAME because it is an internal format and we focus on what is exchanged between access and physical gateways.

The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows:  <ins> ACM : Adaptive Coding and Modulation; </ins> BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer;  <ins> CPE: Customer Premises Equipment; </ins> COM: COMmunication; ETSI: European Telecommunications Standards Institute;  <ins> FEC: Forward Error Correction; </ins> FLUTE: File Delivery over Unidirectional Transport; NORM: NACK-Oriented Reliable Multicast;  <ins> PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for </ins> satellite communications include compression, caching and TCP acceleration;


8. <del> Security considerations are inherent to any access network.  SATCOM systems introduce standard security mechanisms.  On the specific scenario of NC in SATCOM systems, there are no specific security considerations. </del>

The way it's said may call for comments during SecDir review. I'd rather say: Security considerations are inherent to any access network, and in particular SATCOM systems. The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected togething in an Inter-Flow coding approach, see section 3). However this is not specific to the SATCOM use-case and this document does not further elaborate on it.
Thanks for this suggestion. Closed by PR

8.  <ins> Security considerations are inherent to any access network, and in particular SATCOM systems.  The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected togething in an Inter-Flow coding approach, see section sec:use_cases).  However this is not specific to the SATCOM use-case and this document does not further elaborate on it. </ins>


opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems. <del> We have noticed an active research activity on coding and SATCOM in the past.  That being said, not much has actually made it to industrial developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems. </del>  This document follows the taxonomy of coding techniques for efficient network communications RFC8406.

"We have noticed an active research activity on coding and SATCOM in the past." -- if it's active, it's not in the past. if it's in the past, it's not active. Do you mean 'in the past we have noticed'? that's redundant.
You are right. This leads to some confusion. We propose to change as in PR

opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems.  <ins> We notice an active research activity on coding and SATCOM.  That being said, not much has actually made it to industrial developments. In this context, this document aims at identifying opportunities for further usage of coding in these systems. </ins> This document follows the taxonomy of coding techniques for efficient network communications RFC8406.


that the physical-layer knows what coding scheme to use.  Following the taxonomy document RFC8406, channel and link codings are gathered in the PHY layer coding and are out of the scope of this document.  fig:existing_network presents the status of the reliability schemes deployment in satellite systems. discussions. X2 embodies the physical-layer, applied to the PLFRAME, to <del> optimize the satellite capacity usage.  At the physical layer, FEC mechanisms can be exploited. </del>  Reliability is an inherent part of the physical-layer and usually achieved by using coding techniques.  Based on public information,

John Border: Forward Error Correction (FEC) coding below the network layer takes us a long way. At the same time, I think network coding has a lot to offer re reducing retransmission delay when the FEC coding is not enough. I do see that the referenced taxonomy document includes Forward Erasure Correction. This “FEC” is described as an application layer technique. The overlapping use of “FEC” is unfortunate for those of who work down at the lower layers. In any case, it is not always clear which “FEC” the document is referring to.
I understand that there is some confusion on the usage of the accronym. We have clarified in the document that "Following the taxonomy document [RFC8406], channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." We have added in PR that this document considers FEC above the network layer.

that the physical-layer knows what coding scheme to use.  Following the taxonomy document RFC8406, channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. <ins> This document considers FEC as coding mechanisms above the network layer only. </ins> fig:existing_network presents the status of the reliability schemes deployment in satellite systems. discussions. X2 embodies the physical-layer, applied to the PLFRAME, to  <ins> optimize the satellite capacity usage.  At the physical layer, other coding mechanisms can be exploited. </ins> Reliability is an inherent part of the physical-layer and usually achieved by using coding techniques.  Based on public information,


this scenario in fig:rel_multi. A multicast flow (M) is forwarded to both satellite terminals A and <del> B.  However packet Ni (resp.  Nj) get lost at terminal A (resp.  B), </del>  and terminal A (resp.  B) returns a negative acknowledgment Li (resp. Lj), indicating that the packet is missing.  Then either the access gateway or the multicast server includes a repair packet (rather than feedback link is available, or File Delivery over Unidirectional Transport (FLUTE) RFC6726 otherwise.  Note that both NORM and FLUTE are limited to block coding, none of them supporting sliding window <del> encoding schemes RFC8406. </del>  4.3.

Answer to issue
John Border: Section 4.2, 2nd Paragraph "Unidirectional" implies (to me) no ACKs. Without ACKs, FLUTE must do repair in such a way as to not need to know exactly what was lost. This seems different enough to me to be explained separate from NORM.
Our objective is not to discuss about NORM and FLUTE, which is out of scope of the document. We cite these protocols as possible usage example. Also note that although FLUTE is unidirectional, the RFC keeps a door open proposing bidirectional communications for security purpose and to enable full reliability transfer. As a result, we move this sentence at the end of this section as a complementary material and completed the FLUTE description.

this scenario in fig:rel_multi. A multicast flow (M) is forwarded to both satellite terminals A and  <ins> B.  However packet Ni (resp.  Nj) gets lost at terminal A (resp.  B), </ins> and terminal A (resp.  B) returns a negative acknowledgment Li (resp. Lj), indicating that the packet is missing.  Then either the access gateway or the multicast server includes a repair packet (rather than feedback link is available, or File Delivery over Unidirectional Transport (FLUTE) RFC6726 otherwise.  Note that both NORM and FLUTE are limited to block coding, none of them supporting sliding window  <ins> encoding schemes RFC8406.  Note that although FLUTE is defined as an unidirectional protocol, the RFC proposes a bidirectional communication method to enable full reliability transfer and for security purpose. </ins> 4.3.


<del> Network coding and satellites </del>  draft-irtf-nwcrg-network-coding-satellites-05 Abstract This memo details a multi-gateway satellite system to identify <del> multiple opportunities on how network coding techniques could be deployed at a wider scale. </del>  1. transmission losses within a negligible delay compared to link delay. However, when retransmissions are triggered, this leads to an non- negligible additional delay in particular over GEO link.  Further <del> exploiting coding schemes at application or transport layers is an </del>  opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems. The notations used in this document are based on the taxonomy <del> document RFC8406: End-to-End Coding (E2E), Network Coding (NC), Intra-Flow Coding (IntraF), Inter-Flow Coding (InterF), Single-Path Coding (SPC) and Multi-Path Coding (MPC).  Following the taxonomy document RFC8406, channel and link codings are gathered in the PHY layer coding and are out of the scope of this document.  This document considers FEC as coding mechanisms above the network layer only. </del>  fig:existing_network presents the status of the reliability schemes deployment in satellite systems. <del> X1 embodies the source coding that could be used at application level for instance within QUIC or other video streaming applications.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </del>  <del> X2 embodies the physical-layer to optimize the satellite capacity usage.  At the physical layer, other coding mechanisms can be exploited. </del>  <del> We notice an active research activity on coding and SATCOM.  That being said, not much has actually made it to industrial developments. In this context, this document aims at identifying opportunities for further usage of coding in these systems. </del>  The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: for a bi-directional Internet access can be found in SAT2017. Some functional blocks aggregate the traffic of multiple users. <del> Coding schemes could be applied on both single and aggregated </del>  traffic. 3. <del> This section details use-cases where coding schemes could improve the overall performance of a SATCOM system (e.g. considering a more </del>  efficient usage of the satellite resource, delivery delay, delivery ratio). discussed in the TCPM working group I-D.ietf-tcpm-converters. To cope with packet loss (due to either end-user mobility or <del> physical-layer impairments), coding could be introduced in both the CPE and at the concentrator. </del>  3.4. <del> This use-case considers the usage of coding to cope with cases where channel condition can change in less than a second and where the physical-layer codes could not guarantee a Quasi-Error-Free (QEF) transmission. </del>  The architecture is recalled in fig:varying_capa.  In these cases, Adaptative Coding and Modulation (ACM) may not adapt the modulation may change over time (Q/V bands, Ka band, etc.).  Depending on the use-case (e.g. very high frequency bands, mobile users) or depending on the deployment use-cases (e.g. performance of the network between <del> each individual block), the relevance of adding coding is different. </del>  3.5. SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2 <del> and layer-1 encapsulations.  PEP could host coding mechanisms and </del>  thus support the use-cases that have been discussed in this document. Deploying coding schemes at the TCP level in these equipment could be 4.2. Related to the foreseen virtualized network infrastructure, coding <del> schemes could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This trend can also be seen in cellular networks, making these discussions </del>  extendable to other deployment scenarios I-D.chin-nfvrg-cloud-5g- core-structure-yang.  As one example, the coding VNF functions deployment in a virtualized environment is presented in I-D.vazquez- proposed in subsec:varying would legitimize the usage of coding within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding <del> inside a Consultative Committee for Space Data Systems (CCSDS) architecture has been specified in CCSDS-131.5-O-1.  A research challenge would be on how such coding can be integrated in the IETF DTN stack. </del>  5.

A first sentence says quasi-error-free is usually guarranteed thanks to redundancy, while the following sentence tends to say the opposite. Not very clear.The intro fails to clarify the targets. Among them there is "coding to recover from packet losses" (to avoid confusion with bit-error corrections), but also "coding to improve the usage of radio resource". You should also clarify better what is meant by coding: it's not a content coding (e.g., to compress a video flow) but rather a computation of linear combination of packets. Say since the begining you'll rely on RFC8406 whenever possible. Parts of the text currently in section 3 (1st paragraph) deserve to be moved here.Typo: s/to cope from/to cope with/
We have updated the introduction structure and changed the usage of coding in the whole document. We hope this is better. cf PR and PR
this is cherrypicking, not discussing link/channel FEC (Error) or ACK. the heading should really be 'of network coding schemes'. "to cover cases where where"? At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error? "Based on public information, coding does not seem to be widely used at higher layers." it isn't, and that section can be reduced to just that sentence.
Vincent in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.
We think that these comments have been assessed with PR
"In this context, this document aims at identifying opportunities for further usage of coding in these systems." again, network coding. this pretending that link and channel FEC don't exist and that "coding", i.e. network coding, is somehow new is irksome.
Closed by PR

<ins> Coding techniques for satellite systems </ins> draft-irtf-nwcrg-network-coding-satellites-05 Abstract This memo details a multi-gateway satellite system to identify  <ins> multiple opportunities on how coding techniques could be deployed at a wider scale. </ins> 1. transmission losses within a negligible delay compared to link delay. However, when retransmissions are triggered, this leads to an non- negligible additional delay in particular over GEO link.  Further  <ins> exploiting coding techniques at application or transport layers is an </ins> opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems. The notations used in this document are based on the taxonomy  <ins> document RFC8406: Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. FEC (also called Application-Level FEC) operate above the network layer. This document considers coding (or coding techniques or coding schemes) as a linear combination and not as a content coding (e.g., to compress a video flow). </ins> fig:existing_network presents the status of the reliability schemes deployment in satellite systems.  <ins> X1 embodies the source coding techniques that could be used at application level for instance within QUIC or other video streaming applications.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </ins>  <ins> X2 embodies the physical-layer techniques exploited in SATCOM systems (note that other coding techniques can be exploited). This is out of the scope of the document. </ins>  <ins> We notice an active research activity on coding techniques and SATCOM.  That being said, not much has actually made it to industrial developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems. </ins> The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: for a bi-directional Internet access can be found in SAT2017. Some functional blocks aggregate the traffic of multiple users.  <ins> Coding techniques could be applied on both single and aggregated </ins> traffic. 3.  <ins> This section details use-cases where coding techniques could improve the overall performance of a SATCOM system (e.g. considering a more </ins> efficient usage of the satellite resource, delivery delay, delivery ratio). discussed in the TCPM working group I-D.ietf-tcpm-converters. To cope with packet loss (due to either end-user mobility or  <ins> physical-layer impairments), coding techniques could be introduced both at the CPE and at the concentrator. </ins> 3.4.  <ins> This use-case considers the usage of coding techniques to cope with cases where channel condition can change in less than a second and where the physical-layer codes could not guarantee a Quasi-Error-Free (QEF) transmission. </ins> The architecture is recalled in fig:varying_capa.  In these cases, Adaptative Coding and Modulation (ACM) may not adapt the modulation may change over time (Q/V bands, Ka band, etc.).  Depending on the use-case (e.g. very high frequency bands, mobile users) or depending on the deployment use-cases (e.g. performance of the network between  <ins> each individual block), the relevance of adding coding techniques is different. </ins> 3.5. SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2  <ins> and layer-1 encapsulations.  PEP could host coding techniques and </ins> thus support the use-cases that have been discussed in this document. Deploying coding schemes at the TCP level in these equipment could be 4.2. Related to the foreseen virtualized network infrastructure, coding  <ins> techniques could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This trend can also be seen in cellular networks, making these discussions </ins> extendable to other deployment scenarios I-D.chin-nfvrg-cloud-5g- core-structure-yang.  As one example, the coding VNF functions deployment in a virtualized environment is presented in I-D.vazquez- proposed in subsec:varying would legitimize the usage of coding within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding  <ins> techniques inside a Consultative Committee for Space Data Systems (CCSDS) architecture has been specified in CCSDS-131.5-O-1.  A research challenge would be on how such coding can be integrated in the IETF DTN stack. </ins> 5.


SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2 <del> and layer-1 encapsulations.  PEP could host coding techniques and thus support the use-cases that have been discussed in this document. </del>  Deploying coding schemes at the TCP level in these equipment could be relevant and independent from the specific characteristics of a <del> SATCOM link.  However, there is a research issue in the recurrent trade-off in SATCOM systems: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE while optimizing capacity usage ? </del>  4.2.  Related to the foreseen virtualized network infrastructure, coding techniques could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This to a virtualized SATCOM terminals is the management of limited buffered equipments. <del> 4.3. </del>  In the context of the deep-space communications, establishing communications from terrestrial gateways to satellite platforms can

This section deserves a small introduction where you explain that you discuss a few topics, without trying to be exhaustive. Section 5.1 Are PEP part of "Network Functions"? What's their position in the architecture of Fig. 1?I don't understand why the question on code rate to use is in a challenge called "increased deployability". I'd rather put it in a challenge on dynamic adaptation (which is not identified).
Corrected and answered in PR

SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2  <ins> and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus support use-cases that have been discussed in this document. </ins> Deploying coding schemes at the TCP level in these equipment could be relevant and independent from the specific characteristics of a  <ins> SATCOM link.  This leads to research question on the interaction between coding schemes and TCP congestion controls. </ins> 4.2. <ins> The recurrent trade-off in SATCOM systems remains: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE while optimizing capacity usage ? 4.3. </ins> Related to the foreseen virtualized network infrastructure, coding techniques could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This to a virtualized SATCOM terminals is the management of limited buffered equipments.  <ins> 4.4. </ins> In the context of the deep-space communications, establishing communications from terrestrial gateways to satellite platforms can


Abstract <del> This memo details a multi-gateway satellite system to identify multiple opportunities on how coding techniques could be deployed at a wider scale. </del>  1.

abstract This memo details a multi-gateway satellite system to identify multiple opportunities on how network coding techniques could be deployed at a wider scale. this is talking about network coding, and this draft needs to be perfectly clear throughout that it is doing so, otherwise people who know and use other coding and have had little use for network coding previously will simply stop reading. Blurring the coding case is not helping your cause. I called this out previously. This is important.
Vincent: Abstract: The current abstract is not sufficiently detailed: which type of coding? Do you refer to FEC or NC (say so) since it may also be used for other types of coding. The notion of "wider scale" also suggests it is already deployed (is it the case?), or that it may be used outside of the multi-gateway satellite system itself. On the whole, this abstract is pretty ambiguous.
abstract must mention the origin. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG).
We have rephrased the whole abstract and we think PR cover this issue.

Abstract  <ins> This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG).  This document follows the taxonomy document RFC8406 and considers coding as a linear combination of packets that operate above the network layer.  In this context, this memo details a multi-gateway satellite system to identify use-cases where coding is relevant.  As example, coding operating above the network layer can be exploited to cope from residual losses or provide reliable multicast services.  The objective is to contribute to a larger deployment of such techniques in SATCOM systems.  This memo also identifies open research issues related to the deployment of coding in SATCOM systems, such as the interaction between congestion controls and coding techniques. </ins> 1.


acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME <del> with additional information (e.g. related to synchronization); </del>  QEF: Quasi-Error-Free; VNF: Virtual Network Function.  2. This section describes the components in a satellite system based on 3. This section details use-cases where coding techniques could improve <del> the overall performance of a SATCOM system (e.g. considering a more </del>  efficient usage of the satellite resource, delivery delay, delivery ratio). This use-case is mostly relevant for when mobile users are considered or when the chosen band induce a required physical-layer coding that may change over time (Q/V bands, Ka band, etc.).  Depending on the <del> use-case (e.g. very high frequency bands, mobile users) or depending on the deployment use-cases (e.g. performance of the network between </del>  each individual block), the relevance of adding coding techniques is different.

Introduction physical-layer reliability mechanisms -- hyphenate adjectival terms style: e.g. should be in a clause separated by commas, not brackets. 500 ms one-way delivery delay (or path -- i.e. not propagation)
Intro must do the same, clarifying also it's not a standard, and give an estimation of the support it collected during discussion within the group. For instance (taken from rfc 8406): This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. .
I think PR solves the issue.

acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME  <ins> with additional information (e.g., related to synchronization); </ins> QEF: Quasi-Error-Free; VNF: Virtual Network Function. <ins> This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. </ins> 2. This section describes the components in a satellite system based on 3. This section details use-cases where coding techniques could improve  <ins> the overall performance of a SATCOM system (e.g., considering a more </ins> efficient usage of the satellite resource, delivery delay, delivery ratio). This use-case is mostly relevant for when mobile users are considered or when the chosen band induce a required physical-layer coding that may change over time (Q/V bands, Ka band, etc.).  Depending on the  <ins> use-case (e.g., very high frequency bands, mobile users) or depending on the deployment use-cases (e.g., performance of the network between </ins> each individual block), the relevance of adding coding techniques is different.