Change:
I propose some rewording and talk about sender and receiver instead of server and client. The sender is not always the server and it could be confusing to assume the sender as being a server (e.g. in ssh it is the inverse). Let me know if you disagree on this.
Au contraire, I disliked the client-server thing from the beginning and thought we should move it to sender-receiver some day! So thanks a LOT for doing this!
LGTM, thanks for this!

Discussion:
1. There are cases where deploying FEC coding improves the quality of <del> the transmission.  As an example, when a server transmits data to a client, it may take time for the server to detect tail losses (i.e. tail loss can refer to losses at the tail end of transactions).  This would impact the experience of applications using short flows. Another example are networks where non-congestion losses are persistent and prevent a sender from exploiting the link capacity. </del> <ins> the transmission.  As an example, it may take time for the sender to detect tail losses (i.e. tail loss can refer to losses at the tail end of transactions).  This would impact the experience of applications using short flows.  Another example are networks where non-congestion losses are persistent and prevent a sender from exploiting the link capacity. </ins> Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  RFC5681 defines TCP as a

fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward Erasure Correction (FEC) channels.  The Congestion Control channel <del> carries source packets (from a server to a client) and potential </del> <ins> carries source packets (from a sender to a receiver) and potential </ins> information signaling the packets that have been received (from the <del> client to the server).  The Forward Erasure Correction channel carries repair packets (from the server to the client) and a </del> <ins> receiver to the sender).  The Forward Erasure Correction channel carries repair packets (from the sender to the receiver) and a </ins> potential information signaling the packets that have been repaired <del> (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. </del> <ins> (from the receiver to the sender).  It is worth pointing out that there are cases where these channels are not separated. </ins> Inside a host, the CC and FEC entities can be regarded as conceptually separate: fig:sep-entities provides more details than fig:sep-channel by <del> focusing on the server side.  Some elements are introduced: </del> <ins> focusing on the sender-side.  Some elements are introduced: </ins> 'network measurements' (input control plane for the transport including CC): refers to the information a ongestion control can

decides to transmit packets, based on 'network measurements'. 'signaling about losses and/or repaired packets' (input control <del> plane for the FEC): refers to the information a FEC server can obtain from a FEC client about the performance of the FEC solution as seen from the client. </del> <ins> 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.