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

Commentary: This proposes a complete re - vamp of the document . I would also suggest to completely remove sections 6 and 7 , but rather than doing this yet , I inserted comments that explain why . 
 Le 17/01/2020 à 09:28 , mwelzl a écrit : Yes ! Definitely agree . 
 Le 17/01/2020 à 13:50 , francoismichel a écrit : OK for me .
Coding is a reliability mechanism that is distinct and separated from
the loss detection of congestion controls.  Using coding can be a
useful way to better deal with tail losses or with networks with non-
congestion losses.  However, coding mechanisms could hide congestion
signals to the server.  This memo proposes a discussion on how coding
and congestion signals could interact and proposes best current
practice.
Coding is a reliability mechanism that is distinct and separated from
the loss detection of congestion controls.  Using coding can be a
useful way to better deal with tail losses or with networks with non-
congestion losses.  However, coding mechanisms should not hide
congestion signals.  This memo offers a discussion of how coding and
congestion control interact.
There are cases where deploying coding improves the quality of the
transmission.  As example, the server may hardly detect tail losses
that impact may impact the application layer.  Another example may be
the networks where non-congestion losses are persistent and prevent
the server from exploiting the link capacity.  RFC5681 defines TCP as
a loss-based congestion control and coding mechanisms can hide
congestion signals to the server.
There are cases where deploying coding improves the quality of the
transmission.  As an example, the server may hardly detect tail
losses that impact may impact the application layer [MICHAEL: I don't
understand this.  Why would it not detect them?  And why is detecting
them the problem?].  Another example are networks where non-
congestion losses are persistent and prevent a sender from exploiting
the link capacity.  RFC5681 defines TCP as a loss-based congestion
control; because coding repairs such losses, blindly applying it may
easily lead to an implementation that also hides a congestion signal
to the sender.  It is important to ensure that such information
hiding does not occur.
The proposed recommendations apply for coding at the transport or
application layer and coding for tunnels is out-of-the scope of the
document.
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.  Congestion Control channel
carries data packets (from the server to the client) and a potential
information signaling the packets that have been received (from the
client to the server).  Forward Erasure Correction channel carries
coded packets (from the server to the client) and a potiential
information signaling the packets that have been repaired (from the
client to the server).  It is worth pointing out that there are cases
where these channels are not separated.
The proposed recommendations apply for coding at the transport or
application layer.  Coding for tunnels is out of scope for the
document.
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
carries data packets (from a server to a client) and a potential
information signaling the packets that have been received (from the
client to the server).  The Forward Erasure Correction channel
carries coded packets (from the server to the client) and a
potiential information signaling the packets that have been repaired
(from the client to the server).  It is worth pointing out that there
are cases where these channels are not separated.
As this diagram shows, the inputs to FEC (data to work upon, and
signaling from the receiver about losses and/or repaired blocks) are
distinct from the inputs to CC.  The latter calculates a sending rate
or window from network measurements, and it takes the data to send as
input, sometimes along with application requirements such as upper/
lower rate bounds, periods of quiescence, or a priority.
It is not clear that the ACK signals feeding into a congestion
control algorithm are useful to FEC in their raw form, and vice versa
- information about repaired blocks may be quite irrelevant to a CC
algorithm.  However, there can be meaningful other interactions
(indicated by the horizontal double arrow) between the two entities,
usually as a result of their operation rather than by relaying their
own raw inputs.  For example, the network measurements carried out by
CC can yield a longer-term statistical measure such as a loss ratio
which is useful input for a FEC coding scheme.  Similarly, unequal
error protection using fountain codes can be used to assign different
priorities to blocks of data, and these priorities can be honored by
a CC mechanism.
The document focuses on end-to-end coding, i.e. in cases where coding
is added at the server and client end points.  The discussions should
then consider fairness with non-coding solutions.
The client MUST indicate to the server that one or multiple
packets have been repaired using a coding scheme.  The "repaired
packet" signal does not guarantee that the packet actually needed
to be repaired, since it could have been delayed but not lost.
The rationale behind this solution is the following: the server has
more information on the congestion status and the application
characteristics.  Moreover, congestion control should not be splitted
between multiple entities otherwise non-optimized decisions may be
taken.
The proposed solution applies for coding in the transport and
application layers.  The proposed approach is inline with the one in
I-D.swett-nwcrg-coding-for-quic.  The proposed solution does not
applies for the interaction between coding under the transport layer
(i.e. not end-to-end), such as coding for tunnels.
The document focuses on end-to-end coding, i.e. cases where coding is
added at the server and client end points.  The discussions should
then consider fairness with non-coding solutions.
The client indicates to the server that one or multiple packets
have been repaired using a coding scheme.  The "repaired packet"
signal does not guarantee that the packet actually needed to be
repaired, since it could have been delayed but not lost.
The rationale behind this solution is the following: the server has
more information on the congestion status and the application
characteristics.  Moreover, congestion control should not be split
between multiple entities, as otherwise non-optimized decisions may
be taken.
The proposed solution applies for coding in the transport and
application layers.  The proposed approach is in-line with the one in
I-D.swett-nwcrg-coding-for-quic.  The proposed solution does not
apply for the interaction between coding under the transport layer
(i.e. not end-to-end), such as coding for tunnels.
In this solution, the coded packets are sent on top of what is
allowed by a congestion window.  Examples of the solution could be
adding a given pourcentage of the congestion window as supplementary
packets or sending a given amount of coded packets at a given rate.
The redundancy flow can be decorrelated from the congestion control
that manages source packets : a secondary congestion control can be
introduced, such as in coupled congestion control for RTP media I-
D.ietf-rmcat-coupled-cc.  An example would be to exploit a lower than
best-effort congestion control RFC6297.
The advantage of such solution is that coding would help in
challenges cases where transmission losses are persistent.
The drawback of such solution is that it may result in coding
solutions being unfair towards non-coding solutions.  This solutions
may result in adding congestion in congested networks.
In this solution, the coded packets are sent on top of what is
allowed by a congestion window.  Examples of the solution could be
adding a given percentage of the congestion window as supplementary
packets or sending a given amount of coded packets at a given rate.
The redundancy flow can be decorrelated from the congestion control
that manages source packets: a secondary congestion control can be
introduced, such as in coupled congestion control for RTP media I-
D.ietf-rmcat-coupled-cc.  An example would be to exploit a lower than
best-effort congestion control RFC6297.
The advantage of such a solution is that coding would help in
challenging cases where transmission losses are persistent.
The drawback of such a solution is that it may result in coding
solutions being unfair towards non-coding solutions.  This solutions
may result in adding congestion in congested networks.
The advantage of this solution is that it does not contribute in
adding more congestion than the congestion window allows.  Indeed,
all traffic (source and redundancy) is controlled by one congestion
control only and TCP metrics for fairness can be indifferently
applied in this case.
Delay-based congestion controls ignore packets that have been
repaired with coding.  There is no need to define best current
pratices in this case.  However, more discussions are required for
congestion controls that use loss as congestion signals (potentially
among other congestion detection mechanism).
In this solution, the server reacts to repaired packet signals as to
congestion-implied packet losses.  That being said, this does not
necessarily means that the packets have actually been lost.  The
server may have other means to identify that the packet was just out-
of-ordered and ignore the repaired packet signals.
The advantages of the solution are (1) that coding mechanisms do not
hide congestion signals, such as packets voluntary dropped by a AQM
RFC7567 and (2) packets may be repaired faster than with traditionnal
retransmission mechanisms.
The advantage of this solution is that it does not add more traffic
than the congestion window allows.  Indeed, all traffic (source and
redundancy) is controlled by one congestion control only and TCP
metrics for fairness can be indifferently applied in this case.
The advantages of the solution are (1) that coding mechanisms do not
hide congestion signals, such as packets voluntary dropped by a AQM
RFC7567 and (2) packets may be repaired faster than with a
traditional retransmission mechanisms.
In this solution, the server does not reduce the congestion window
with the same amount when the "repaired packet" signal is received,
i.e. when a packet has been lost but repaired.  Example of this
solution could be based on RFC8511 or considering that recovering an
isolated packet is not an actual sign of congestion.
This is the case for delay-based congestion controls.  The
interaction between delay-based congestion controls and the delay
induced by a coding mechanisms is an open research activity.  That
being said, a potential approach would be that loss-based congestion
control ignores the "repaired packet" signal.
This section provides a summary on the content in previous sections.
The fig:summary sums up some recommendations.  It is worth pointing
out that the "coding without congestion" considers that coded packets
are sent along with original data packets, in opposition with the
solution where coded packets are transmitted only when there is no
more original packets to transmit.  Moreover, the values indicated in
this Figure consider a channel that does not exhibit a high loss
pattern.