Change:
bandwidth that could have been exploited to transmit source packets. The coding ratio needs to be carefully designed. <del> 3.3. </del> <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> <del> fig:fec-below illustrates the FEC below the transport case. </del> <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 <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> <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.

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!