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

Commentary: we could mention latency sensitive application such as  . 
 done in PR 
    You should define what you mean by fairness . I remember endless discussions about fairness in NC with   amongst others . 
 Thank you for the comment . We have proposed something in PR
The advantage of this approach is that the FEC overhead does not
contribute to congestion in the network.  When congestion control is
implemented at the transport layer, the repair symbols are sent
within what the congestion window allows.  This approach can result
in improved quality of experience for latency sensitive and non
reliable applications.
The advantage of this approach is that the FEC overhead does not
contribute to congestion in the network.  When congestion control is
implemented at the transport layer, the repair symbols are sent
within what the congestion window allows.  This approach can result
in improved quality of experience for latency sensitive applications
such as VoIP.
The objective of this section is to further discuss how adding coded
flows impacts on non-coded flows when they share the same bottleneck.
This section assumes that the non-coded flows respond to congestion
signals from the network.
The contract between the client and the operator may guarantee a
minimum data-rate (e.g. mobile networks).  However for residential
accesses, the data-rate can be guaranteed for the customer premises
equipment, but not necessarily for the client.  The quality of
service that guarantees fairness between the different clients can be
seen as a policy concern I-D.briscoe-tsvarea-fair.
Two clients in a residential access.
This document considers fairness as how adding coded flows impacts on
non-coded flows when they share the same bottleneck.  This document
does not aim at contributing to the definition of fairness at a wider
scale.  This document assumes that the non-coded flows respond to
congestion signals from the network.
This section provides a simplified state-of-the art of the activities
related to congestion control and coding.  The objective is to
identify open research questions and contribute to advices when it
comes to evaluate coding mechanisms.
For the FEC within transport case: I-D.swett-nwcrg-coding-for-
quic, QUIC-FEC, RFC5109.
For the FEC below transport case: NCTCP, I-D.detchart-nwcrg-
tetrys.
The research questions should be mapped following the oranization of
this document.  In all these three use-cases, a open questions
remains and is inherent to the usage of coding.  There is a trade-off
between reducing goodput, helping recovering from transmission and
congestion losses, being fair in respect with non-coded flows and
avoiding transmitting useless repaired symbols.
For the FEC above transport case, there is a trade-off between the
amount of redundancy to add, as a function of the transport layer
protocol and application requirements.
For the FEC within transport case, the addition of coding may hide
congestion losses and proposing methods to signal such events to end
point could be propose.
For the FEC below transport case, there are opportunities for
introducing interaction between congestion control and coding schemes
to improve the quality of experience while guarantee fairness with
other flows.  An open question also resides on the relevance of the
FEC when there are multiple streams that exploit the FEC channel.
The contribution to research questions should be mapped following the
oranization of this document.  Otherwise, this may lead to wrong
assumptions on the validity of the proposal and wrong ideas about the
relevance of coding for a given use case.
The discussion provided in this document aim at encouraging the
research community to also consider congestion control aspects when
proposing and comparing FEC coding solutions in communication
systems.  As one example, this draft proposes discussions on the
impact of the proposed FEC solution on the congestion control,
especially loss-based congestion control such as CUBIC.