Change:
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> <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. <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> <ins> fig:fec-above present an architecture where FEC is on top of the transport. </ins> <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> <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 <del> transfer protocols (e.g.  TCP).  This approach requires that the </del> <ins> transfer protocols (e.g.  TCP).  This approach may require that the </ins> 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> <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> <del> 3.2. </del> <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> <del> fig:fec-in illustrates the FEC within the transport case. </del> <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 <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> <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

Discussion:
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!