Draft: draft-irtf-nwcrg-coding-and-congestion-04

Commentary: Small changes , nothing urging , should be easy to merge if you are ok with it :-)
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
becomes impossible to carry traffic.
In the case of an unreliable data transfer, the transport layer
may provide a non-reliable transport service (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
becomes impossible to carry traffic.
For reliable transfers, including redundancy reduces goodput for
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.
For reliable transfers, including redundancy reduces goodput for
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.
If the two FEC and CC channels are decoupled, the endpoint may
exploit different protocols for each channel.  The channels may be
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
repaired symbols that were actually useful in the recovery process of
packets.
QUIC may require a specific type of frame to transport such
information between receiver and sender.
If the two FEC and CC channels are decoupled, the endpoint may
exploit different protocols for each channel.  The channels may be
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
repair symbols that were actually useful in the recovery process of
packets.
There are cases where useless repaired symbols may be transmitted.
These impact on the network load and may reduce the goodput of the
flow without concrete gains.
In this case, the discussion depends on application needs.  The only
case where adding useless repaired symbols does not result in reduced
goodput is when the application needs a limited amount of goodput
(e.g., VoIP traffic).  In this case, the useless repaired symbols
would only impact the amount of data generated in the network.
The sender may exploit the information given by the receiver to
reduce the number of useless repaired symbols and the resulting
goodput reduction.
In this case, the useless repaired symbols only impact the load of
the network without actual gain for the coded flow.
There are cases where useless repair symbols may be transmitted.
These impact on the network load and may reduce the goodput of the
flow without concrete gains.
In this case, the discussion depends on application needs.  The only
case where adding useless repair symbols does not result in reduced
goodput is when the application needs a limited amount of goodput
(e.g., VoIP traffic).  In this case, the useless repair symbols would
only impact the amount of data generated in the network.
The sender may exploit the information given by the receiver to
reduce the number of useless repair symbols and the resulting goodput
reduction.
In this case, the useless repair symbols only impact the load of the
network without actual gain for the coded flow.