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

Commentary: It seems commits have been done while doing my review , I am fine with those changes
FEC coding is a reliability mechanism that is distinct and separate
from the loss detection of congestion controls.  Using FEC coding can
help deal with transfer tail losses or with networks having non-
congestion losses.  However, FEC coding mechanisms should not hide
congestion signals.  This memo offers a discussion of how FEC coding
and congestion control can coexist.  Another objective is to
encourage the research community to also consider congestion control
aspects when proposing and comparing FEC coding solutions in
communication systems.
Forward Erasure Correction (FEC) is a reliability mechanism that is
distinct and separate from the retransmission logic in reliable
transfer protocols such as TCP.  Using FEC coding can help deal with
transfer tail losses or with networks having non-congestion losses.
However, FEC coding mechanisms should not hide congestion signals.
This memo offers a discussion of how FEC coding and congestion
control can coexist.  Another objective is to encourage the research
community to also consider congestion control aspects when proposing
and comparing FEC coding solutions in communication systems.
There are cases where deploying FEC coding improves the performance
of a transmission.  As an example, it may take time for the sender to
detect transfer tail losses (losses that occur at the end of a
transfer, where e.g., TCP obtains no more ACKs to repair the loss via
retransmission quickly).  This would improve 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.
Coding is a reliability mechanism that is distinct and separate from
the loss detection of congestion controls.  RFC5681 defines TCP as a
loss-based congestion control; since FEC 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.
There are cases where deploying FEC coding improves the performance
of a transmission.  As an example, it may take time for the sender to
detect transfer tail losses (losses that occur at the end of a
transfer, where e.g., TCP obtains no more ACKs to repair the loss via
retransmission quickly).  Allowing the receiver to recover such
losses instead of having to rely on a retransmission could improve
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.
Coding is a reliability mechanism that is distinct and separate from
the loss detection of congestion controls.  RFC5681 defines TCP as a
loss-based congestion control; since FEC coding repairs such losses,
blindly applying it may easily lead to an implementation that also
hides a congestion signal from the sender.  It is important to ensure
that such information hiding does not occur.
FEC coding and congestion control can be seen as two separate
channels.  In practice, implementations may mix the signals that are
exchanged on these channels.  This memo offers a discussion of how
FEC coding and congestion control can coexist.  Another objective is
to encourage the research community also to consider congestion
control aspects when proposing and comparing FEC coding solutions in
communication systems.  This being said, this document does not aim
at proposing guidelines for characterizing FEC coding solutions:
comparing FEC Schemes without considering congestion control can be
relevant if the goal is to compare those schemes only.
The proposed document considers FEC coding at the transport or
application layer for an end-to-end unicast data transfer.  The
typical application scenario considered in the current version of the
document is a client browsing the web or watching a live video.  This
memo may be extended to cases with multiple paths.
FEC coding and congestion control can be seen as two separate
channels.  In practice, implementations may mix the signals that are
exchanged on these channels.  This memo offers a discussion of how
FEC coding and congestion control can coexist.  Another objective is
to encourage the research community also to consider congestion
control aspects when proposing and comparing FEC coding solutions in
communication systems.  This document does not aim at proposing
guidelines for characterizing FEC coding solutions.
The proposed document considers an end-to-end unicast data transfer
with FEC coding at the application (above the transport), within the
transport or directly below the transport.  The typical application
scenario considered in the current version of the document is a
client browsing the web or watching a live video.  This memo may be
extended to cases with multiple paths.
'signaling repaired symbols' (input control 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.
'signaling repaired symbols' (input control 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 by the
receiver.
fig:fec-above present an architecture where FEC is on top of the
transport.
fig:fec-above present an architecture where FEC operates on top of
the transport.
This approach requires that the transport protocol does not implement
a reliable data transfer service (e.g., based on lost packet
retransmission).  UDP is an example of a protocol for which this
approach is relevant.  For reliable transfers, coding usage does not
guarantee better performance and would mainly reduce goodput for
large file transfers.
This approach requires that the transport protocol does not implement
a fully reliable data transfer service (e.g., based on lost packet
retransmission).  UDP is an example of a protocol for which this
approach is relevant.  For reliable transfers, coding usage does not
guarantee better performance and would mainly reduce goodput for
large file transfers.
fig:fec-in presents an architecture where FEC is within the
transport.  The repair symbols are sent within what the congestion
window allows, such as in CTCP.
fig:fec-in presents an architecture where FEC operates within the
transport.  The repair symbols are sent within what the congestion
window allows, such as in CTCP.
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 or preferably
sending repair symbols instead of the following packets in the send
buffer could help to reduce the transfer time.  This is because it
could avoid a silent period between the transmission of the last
packet and firing the retransmission of lost packets.
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.
fig:fec-below presents an architecture where FEC is applied end-to-
end below the transport layer, but above the link layer.  Note that
it is common to apply FEC at the link layer, in which it contributes
to the total capacity that a link exposes to upper layers.  This
application of FEC is out of scope of this document.  The repair
symbols are sent on top of what is allowed by the congestion control.
In this case, including redundancy adds congestion without reducing
goodput but leads to potential fairness issues.  The effective
bitrate is indeed higher than the CC's computed fair share due to the
sending of repair symbols and the losses are hidden to the transport
which may cause a problem for loss-based congestion controls, but is
not a problem for delay-based ones.
fig:fec-below presents an architecture where FEC is applied end-to-
end below the transport layer, but above the link layer.  Note that
it is common to apply FEC at the link layer, in which it contributes
to the total capacity that a link exposes to upper layers.  This
application of FEC is out of scope of this document.  In the scenario
considered here, the repair symbols are sent on top of what is
allowed by the congestion control.
In this case, including redundancy adds congestion without reducing
goodput but leads to potential fairness issues.  The effective
bitrate is indeed higher than the CC's computed fair share due to the
sending of repair symbols and the losses are hidden from the
transport.  This may cause a problem for loss-based congestion
detection, but it is not a problem for delay-based congestion
detection.
Examples of the solution could be adding a given percentage of the
congestion window as supplementary symbols or sending a given amount
of repair symbols at a given rate.  The redundancy flow can be
decorrelated from the congestion control that manages source packets:
a separate congestion control could be introduced to manage the
amount of repaired packets to transmit on the FEC channel.  The
separate congestion control instances could be made to work together
while adhering to priorities, as in coupled congestion control for
RTP media RFC8699 in case all traffic can be assumed to take the same
path, or otherwise with a multipath congestion window coupling
mechanism as in Multipath TCP RFC6356.  Another possibility would be
to exploit a lower than best-effort congestion control RFC6297 for
repair symbols.
Examples of the solution could be adding a given percentage of the
congestion window as supplementary symbols or sending a given amount
of repair symbols at a given rate.  The redundancy flow can be
decorrelated from the congestion control that manages source packets:
a separate congestion control entity could be introduced to manage
the amount of repaired packets to transmit on the FEC channel.  The
separate congestion control instances could be made to work together
while adhering to priorities, as in coupled congestion control for
RTP media RFC8699 in case all traffic can be assumed to take the same
path, or otherwise with a multipath congestion window coupling
mechanism as in Multipath TCP RFC6356.  Another possibility would be
to exploit a lower than best-effort congestion control RFC6297 for
repair symbols.
Two clients in residential access.
two clients on a residential access.
The addition of coding within the flow may impact the congestion
control mechanism and hide congestion losses.  Specific interaction
between congestion controls and coding schemes can be proposed (see
subsec:cc-recov-interaction, subsec:cc-nc-interaction and subsec:cc-
useless-interaction).  If no specific interaction is introduced, the
coding scheme may hide congestion losses to the congestion controller
and the description of subsub:fec_below may apply.
In this case, the coding scheme may hide congestion losses to the
congestion controller.  There are cases where this can drastically
reduce the goodput of the non-coded flows.  Depending on the
congestion control, it may be possible to indicate that a packet has
been recovered, e.g. using ECN flag, to reduce the impact on the non-
coded flows (see subsec:cc-recov-inter-below).
The addition of coding within the flow may impact the congestion
control mechanism and hide congestion losses.  Specific interaction
between congestion controls and coding schemes can be proposed (see
subsec:cc-recov-interaction, subsec:cc-nc-interaction and subsec:cc-
useless-interaction).  If no specific interaction is introduced, the
coding scheme may hide congestion losses from the congestion
controller and the description of subsub:fec_below may apply.
In this case, the coding scheme may hide congestion losses from the
congestion controller.  There are cases where this can drastically
reduce the goodput of non-coded flows.  Depending on the congestion
control, it may be possible to signal to the congestion control
mechanism that there was congestion (loss) even when a packet has
been recovered, e.g. using ECN, to reduce the impact on the non-coded
flows (see subsec:cc-recov-inter-below).
If the two FEC and CC channels are decoupled, the endpoint may
exploit specific 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.
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.
The congestion control may not know what is going on in the network
underneath and whether a coding scheme is introduced or not.  The
congestion control may behave as if no coding scheme is introduced.
The only way for a coding channel to indicate that symbols have been
recovered is to exploit existing signaling.  An example would be a
receiver to indicate that a packet has been recovered by using ECN
signals of TCP.
The congestion control may not know what is going on in the network
underneath and whether a coding scheme is introduced or not.  The
congestion control may behave as if no coding scheme is introduced.
The only way for a coding channel to indicate that symbols have been
recovered is to exploit existing signaling that is understood by the
congestion control mechanism.  An example would be to indicate to a
TCP sender that a packet has been recovered (i.e., congestion has
occurred), by using ECN signaling.
In this case, there is an important flexibility in the trade-off
between reducing goodput, helping recovering from transmission and
congestion losses, being fair in respect with non-coded flows.  Such
as explained in subsec:cc-recov-inter-in, the receiver may indicate
the sender the number of packets that have been received or
recovered.  The sender may exploit this information to tune the
coding ratio.  As one example of flexibility of this case, coupling
an increased transmission rate with an increasing or decreasing
coding rate could be envisioned.  A server may use increasing coding
rate as a probe of the channel capacity and adapt the congestion
control transmission rate.
In this case, there is an important flexibility in the trade-off,
inherent to the use of coding, between (1) reducing goodput when
useless repair symbols are transmitted and (2) helping to recover
sooner from transmission and congestion losses.  As explained in
subsec:cc-recov-inter-in, the receiver may indicate to the sender the
number of packets that have been received or recovered.  The sender
may exploit this information to tune the coding ratio.  As one
example of flexibility of this case, coupling an increased
transmission rate with an increasing or decreasing coding rate could
be envisioned.  A server may use an increasing coding rate as a probe
of the channel capacity and adapt the congestion control transmission
rate.
The sender may exploit the information given by the receiver to
reduce the number of useless repair packets and the resulting goodput
reduction.
The sender may exploit the information given by the receiver to
reduce the number of useless repaired symbols and the resulting
goodput reduction.
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 to recover from / 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 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 research questions should be mapped following the organization of
this document.  In all these three use-cases, open questions remain.
There is a general trade-off, inherent to the use of coding, between
(1) reducing goodput when useless repair symbols are transmitted and
(2) helping to recover from transmission and congestion losses.
For the FEC above transport case, there is a trade-off related to the
amount of redundancy to add, as a function of the transport layer
protocol and application requirements.
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 guaranteeing fairness with
other flows.  An open question also resides in the relevance of FEC
when there are multiple streams that exploit the FEC channel.
The contribution to research questions should be mapped following the
organization 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 aims 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 congestion control, especially
loss-based congestion control mechanisms.  When a research work aims
at improving the throughput by hiding the packet loss signal from the
congestion control, the authors should 1) discuss the advantages of
using the proposed FEC solution compared to replacing the congestion
control by one that ignores a portion of the encountered losses, 2)
critically discuss the impact of hiding packet loss from the
congestion control mechanism.