Original text:
application requirements: In the case of an unreliable data transfer, the transport layer <del> may implement a non-reliable transport layer (e.g.  UDP or DCCP </del>  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 repair lost packets (such as tail losses). For reliable transfers, including redundancy reduces goodput for <del> large file transfers but the amount of repaired symbols can be adapted, e.g. depending on the congestion window size.  There is a trade-off between the cost in capacity used to transmit source packets and the benefits brought out by transmitting repair symbols (e.g. unlocking the receive buffer if this is limiting).  The coding ratio needs to be carefully designed.  For small files, sending repair symbols when there is no more data to transmit could help to reduce the transfer time.  In general, sending repair symbols could avoid a silent period between the transmission of the last packet in the send buffer and 1) firing the retransmission of lost packets, or 2) the transmission of new packets. </del>  This discussion section is extended in sec:fairness. coupled and one single protocol may be exploited.  In both cases, the receiver can differentiate source packets and repair symbols.  The receiver may indicate both the number of source packets received and <del> repaired symbols that were actually useful in the recovery process of </del>  packets. <del> QUIC may require a specific type of frame to transport such information between receiver and sender. </del> 6.3.3. The congestion control may not know what is going on in the network 6.5. <del> There are cases where useless repaired symbols may be transmitted. </del>  These impact on the network load and may reduce the goodput of the flow without concrete gains. 6.5.1. In this case, the discussion depends on application needs.  The only <del> case where adding useless repaired symbols does not result in reduced </del>  goodput is when the application needs a limited amount of goodput <del> (e.g., VoIP traffic).  In this case, the useless repaired symbols would only impact the amount of data generated in the network. </del>  6.5.2. The sender may exploit the information given by the receiver to <del> reduce the number of useless repaired symbols and the resulting goodput reduction. </del>  6.5.3. <del> In this case, the useless repaired symbols only impact the load of the network without actual gain for the coded flow. </del>  7.

Reviewer comments:
Small changes, nothing urging, should be easy to merge if you are ok with it :-)

Revised text:
application requirements: In the case of an unreliable data transfer, the transport layer  <ins> may provide a non-reliable transport service (e.g.  UDP or DCCP </ins> 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 repair lost packets (such as tail losses). For reliable transfers, including redundancy reduces goodput for  <ins> large file transfers but the amount of repair symbols can be adapted, e.g. depending on the congestion window size.  There is a trade-off between the cost in capacity used to transmit source packets and the benefits brought out by transmitting repair symbols (e.g. unlocking the receive buffer if this is limiting).  The coding ratio needs to be carefully designed.  For small files, sending repair symbols when there is no more data to transmit could help to reduce the transfer time.  In general, sending repair symbols could avoid a silent period between the transmission of the last packet in the send buffer and 1) firing the retransmission of lost packets, or 2) the transmission of new packets. </ins> This discussion section is extended in sec:fairness. coupled and one single protocol may be exploited.  In both cases, the receiver can differentiate source packets and repair symbols.  The receiver may indicate both the number of source packets received and  <ins> repair symbols that were actually useful in the recovery process of </ins> packets.  6.3.3. The congestion control may not know what is going on in the network 6.5.  <ins> There are cases where useless repair symbols may be transmitted. </ins> These impact on the network load and may reduce the goodput of the flow without concrete gains. 6.5.1. In this case, the discussion depends on application needs.  The only  <ins> case where adding useless repair symbols does not result in reduced </ins> goodput is when the application needs a limited amount of goodput  <ins> (e.g., VoIP traffic).  In this case, the useless repair symbols would only impact the amount of data generated in the network. </ins> 6.5.2. The sender may exploit the information given by the receiver to  <ins> reduce the number of useless repair symbols and the resulting goodput reduction. </ins> 6.5.3.  <ins> In this case, the useless repair symbols only impact the load of the network without actual gain for the coded flow. </ins> 7.