Original text:
The proposed document considers FEC coding at the transport or application layer for an end-to-end unicast data transfer.  The typical application scenario that is considered in the current <del> version of the document is a client browsing the web.  This memo may be extended to cases with multiple paths. </del>  This document represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); Inside a host, the CC and FEC entities can be regarded as conceptually separate: <del> fig:sep-entities provides more details than fig:sep-channel by focusing on the sender-side.  Some elements are introduced: </del>  'network information' (input control plane for the transport including CC): refers not only to the network information that is including CC): refers to the rate at which a congestion control decides to transmit packets, based on 'network information'. <del> 'signaling about losses and/or repaired packets' (input control plane for the FEC): refers to the information a FEC sender can obtain from a FEC receiver about the performance of the FEC solution as seen from the receiver. </del>  'coding rate' (output control plane for the FEC): refers to the coding rate that is used by the FEC solution. inputs to CC.  The latter calculates a sending rate or window from network information, and it takes the packet to send as input, sometimes along with application requirements such as upper/lower <del> rate bounds, periods of quiescence, or a priority. 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 - information about repaired blocks may be quite irrelevant to a CC algorithm. </del>  3. <del> This section discusses how FEC and CC can relate in different cases (FEC above the transport, FEC within the transport, FEC below the transport). </del> 3.1. <del> fig:fec-above illustrates the FEC above the transport case. </del>  <del> fig:fec-above presents an architecture where FEC is on top of the transport.  The repair packets are sent within what the congestion window allows. The advantage of this approach is that the FEC does not contribute to adding congestion in the network. </del>  While CC is in principle independent of other transport functions such as reliability, we note that CC is often embedded in reliable <del> transfer protocols (e.g.  TCP).  This approach requires that the </del>  transport protocol does not implement a fully reliable data transfer <del> service (e.g., based on lost packet retransmission).  UDP is an example of a protocol for which this approach is relevant. </del>  <del> 3.2. </del>  <del> fig:fec-in illustrates the FEC within the transport case. </del>  fig:fec-in presents an architecture where FEC is within the transport.  The repair packets are sent within what the congestion <del> window allows, such as in CTCP.  Examples of the solution would be sending repair packets when there is no more data to transmit or preferably send repair packets instead of the following packets in the send buffer. </del>  The advantage of this approach is that it can enable conjoint optimization between the CC and the FEC.  Moreover, the transmission bandwidth that could have been exploited to transmit source packets. The coding ratio needs to be carefully designed. <del> 3.3. </del>  <del> fig:fec-below illustrates the FEC below the transport case. </del>  fig:fec-below presents an architecture where FEC is below the transport.  The repair packets are sent on top of what is allowed by <del> 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 repair 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.  The separate congestion control mechanisms could be made to work together while adhering to priorities, as in coupled congestion control for RTP media I-D.ietf- rmcat-coupled-cc.  Another possibility would be to exploit a lower than best-effort congestion control RFC6297 for repair packets. </del>  The advantage of this approach is that it can result in performance gains when there are persistent transmission losses along the path. already congested networks.  The coding ratio needs to be carefully designed. <del> 4. </del>  This memo includes no request to IANA. <del> 5. </del>  FEC and CC schemes can contribute to DoS attacks.  This is not specific to this document.

Reviewer comments:
Looks good to me !
I see a major scoping problem in these sections. What does this document really aim at? It is said earlier: This document discusses how FEC and CC relate. Here we see architectural discussions on advantages/drawbacks instead. There is also the additional idea of how it relates to transport reliability mechanism which is (in theory) out of scope. I'd like to see more info about what concretely can be done (examples). The case of QUIC and what was already proposed here to let FEC and CC work together is pretty interesting. I also think the application (as data source) is potentially involved in the big picture: an application generating a real-time data flow is not the same as an application generating background traffic. In the first case we could end up with situations where it's just impossible to carry traffic by adding a certain redundancy, given the network conditions. It means that without adapting the data flow there is probably no solution. In the second case (which includes François's experiments with tail losses)
item 1: I think this is now addressed by careful phrasing in the para that mentions reliability, in PR . Item 2: I agree but I'd greatly prefer if we could postpone this to the next version. I think we should include multipath considerations too, so this will be quite a bit of work. Item 3: I agree... someone should write something :)
Item 1 addressed by PR Open for next submission I'd like to see more info about what concretely can be done (examples). The case of QUIC and what was already proposed here to let FEC and CC work together is pretty interesting. I also think the application (as data source) is potentially involved in the big picture: an application generating a real-time data flow is not the same as an application generating background traffic. In the first case we could end up with situations where it's just impossible to carry traffic by adding a certain redundancy, given the network conditions. It means that without adapting the data flow there is probably no solution. In the second case (which includes François's experiments with tail losses)
I am not sure I completely get the last item though. More specifically, I don't know what to say about this in this draft about the relations between coding and the congestion control. We could state that the application can provide information about importance or deadline concerning its data, but I think the optimal FEC pattern , with or without congestion, will likely depend on the application's requirements in the end ? Does anybody have a clearer idea on what we could state on this ? Let's discuss this here before writing ?
I think you're trying to find a solution, whereas we're only describing a situation. The latter is simpler: we can basically repeat what Vincent has told us: "an application generating a real-time data flow is not the same as an application generating background traffic. In the first case we could end up with situations where it's just impossible to carry traffic by adding a certain redundancy, given the network conditions. It means that without adapting the data flow there is probably no solution." Just point it out.
Looks good to me. Thank you !
The application requirements aspect have been covered by PR
The current version of hte draft seems to go for a more "server" side discussion. We should not forget to speak about the client.
I agree - but maybe delay this until the next version of the draft?
I have pushed some content with some more details on the server side solutions. I think we may be soon ready to either submit this version or had a small section on the receiver side. It can be very simple IMHO: " The receiver must not use CC channel signals to acknowledge the recovery of data packets with the coding schemes. The information on recovered packets must be reported on the FEC channel."
I agree with both approaches. I'd vote for shipping it as-is (better to have a more useful discussion on the receiver side - surely we can come up with something more for the next version of the draft?)
Thanks for the feedback - I would vote the same. Any other thoughts ?
This is done in PR
LGTM modulo a minor suggestion, but that was from a quick glance only... can't dedicate more time this round, sorry!

Revised text:
The proposed document considers FEC coding at the transport or application layer for an end-to-end unicast data transfer.  The typical application scenario that is considered in the current  <ins> version of the document is a client browsing the web or watching a live video.  This memo may be extended to cases with multiple paths. </ins> This document represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); Inside a host, the CC and FEC entities can be regarded as conceptually separate:  <ins> fig:sep-entities-srv and fig:sep-entities-clt provide more details than fig:sep-channel.  Some elements are introduced: </ins> 'network information' (input control plane for the transport including CC): refers not only to the network information that is including CC): refers to the rate at which a congestion control decides to transmit packets, based on 'network information'.  <ins> 'signaling repaired packets' (input control plane for the FEC): refers to the information a FEC sender can obtain from a FEC receiver about the performance of the FEC solution as seen from the receiver. </ins> 'coding rate' (output control plane for the FEC): refers to the coding rate that is used by the FEC solution. inputs to CC.  The latter calculates a sending rate or window from network information, and it takes the packet to send as input, sometimes along with application requirements such as upper/lower  <ins> rate bounds, periods of quiescence, or a priority.  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 - information about repaired blocks may be quite irrelevant to a CC algorithm. The choice of the adequate transport layer may be related to application requirements: In the case of an unreliable data transfer, the transport layer may implement a non-reliable transport layer (e.g.  UDP or DCCP RFC4340 or a partially reliable transport protocol such as SCTP with partial reliability RFC3758).  Depending on the amount of redundancy and network conditions, there could be cases where it ends up being impossible to carry traffic. In the case of a reliable data transfer, the transport layer may implement a retransmission mechanism to guarantee the reliability of the file transfer (e.g.  TCP).  Depending on how the FEC and CC functions are scheduled (FEC above CC, FEC in CC, FEC below CC), the impact of a reliable transport on the FEC reliability mechanisms is different. </ins> 3.  3.1.  <ins> fig:fec-above present an architecture where FEC is on top of the transport. </ins>  <ins> 3.2. </ins> While CC is in principle independent of other transport functions such as reliability, we note that CC is often embedded in reliable  <ins> transfer protocols (e.g.  TCP).  This approach may require that the </ins> transport protocol does not implement a fully reliable data transfer  <ins> service (e.g., based on lost packet retransmission), otherwise this could lead to spurious retransmissions.  UDP is an example of a protocol for which this approach is relevant. </ins>  <ins> The advantage of this approach is that the FEC does not contribute to adding congestion in the network.  When a congestion control is implementedd at the transport layer, the repair packets are sent within what the congestion window allows. </ins>  <ins> 4. 4.1. </ins> fig:fec-in presents an architecture where FEC is within the transport.  The repair packets are sent within what the congestion  <ins> window allows, such as in CTCP. 4.2. </ins> The advantage of this approach is that it can enable conjoint optimization between the CC and the FEC.  Moreover, the transmission bandwidth that could have been exploited to transmit source packets. The coding ratio needs to be carefully designed.  <ins> Examples of the solution would be sending repair packets when there is no more data to transmit or preferably send repair packets instead of the following packets in the send buffer. 5. </ins>  <ins> 5.1. </ins> fig:fec-below presents an architecture where FEC is below the transport.  The repair packets are sent on top of what is allowed by  <ins> the congestion control. 5.2. </ins> The advantage of this approach is that it can result in performance gains when there are persistent transmission losses along the path. already congested networks.  The coding ratio needs to be carefully designed.  <ins> Examples of the solution could be adding a given percentage of the congestion window as supplementary packets or sending a given amount of repair 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.  The separate congestion control mechanisms could be made to work together while adhering to priorities, as in coupled congestion control for RTP media I-D.ietf-rmcat-coupled-cc.  Another possibility would be to exploit a lower than best-effort congestion control RFC6297 for repair packets. 6. </ins> This memo includes no request to IANA.  <ins> 7. </ins> FEC and CC schemes can contribute to DoS attacks.  This is not specific to this document.