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

Commentary: We should change the word " bandwidth " with " capacity " .  is strongly linked to the physical layer , in our case , this is " Network Bandwith " . So either " Capacity " or " Network Bandwith " . 
 Removed the occurence of bandwidth in pR
FEC coding is a reliability mechanism that is distinct and separate
from the loss detection of congestion controls.  Using FEC coding can
be a useful way to 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.
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.
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 quickly repair the
loss via retransmission).  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; because 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.
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 to also 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.
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.
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 that is 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.
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.
'network information' (input control plane for the transport
including CC): refers not only to the network information that is
explicitly signaled from the receiver, but all the information a
congestion control obtains from a network (e.g.  TCP can estimate
the latency and the available capacity at the bottleneck).
'network information' (input control plane for the transport
including CC): refers not only to the network information that is
explicitly signaled from the receiver, but all the information a
congestion control obtains from a network (e.g., TCP can estimate
the latency and the available capacity at the bottleneck).
'sending rate (or window)' (output control plane for the transport
including CC): refers to the rate at which a congestion control
decides to transmit packets, based on 'network information'.
'sending rate (or window)' (output control plane for the transport
including CC): refers to the rate at which a congestion control
decides to transmit packets based on 'network information'.
The inputs to FEC (packets to work upon, and signaling from the
receiver about losses and/or repaired symbols) are distinct from the
inputs to CC.  The latter calculates a sending rate or window from
network information, and it takes the packet 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.
The inputs to FEC (incoming data packets (without repair symbols),
and signaling from the receiver about losses and/or repaired symbols)
are distinct from the inputs to CC.  The latter calculates a sending
rate or window from network information, and it takes the packet 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.
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
ends up being impossible to carry traffic.
In the case of a reliable data transfer, the transport layer may
implement a retransmission mechanism to guarantee the reliability
of the file transfer (e.g.  TCP).  Depending on how the FEC and CC
functions are scheduled (FEC above CC, FEC in CC, FEC below CC),
the impact of a reliable transport on the FEC reliability
mechanisms is different.
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 a reliable data transfer, the transport layer may
implement a retransmission mechanism to guarantee the reliability
of the file transfer (e.g.  TCP).  Depending on how the FEC and CC
functions are scheduled (FEC above CC, FEC in CC, FEC below CC),
the impact of reliable transport on the FEC reliability mechanisms
is different.
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.
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, the usage of coding
does not guarantee better performance and would mainly reduce goodput
for large files transfers.
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
following the congestion window.  This approach can result in
improved quality of experience for latency sensitive applications
such as VoIP.
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.
The advantage of this approach is that it can enable conjoint
optimization between the CC and the FEC.  Moreover, the transmission
of repair symbols does not add congestion in potentially congested
networks but helps repair lost packets (such as tail losses).
For reliable transfers, including redundancy reduces goodput for
large files 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 bandwidth that could have been
exploited to transmit source packets and the advantages that are
brought 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.
The advantage of this approach allows a joint optimization between
the CC and the FEC.  Moreover, the transmission of repair symbols
does not add congestion in potentially congested networks but helps
repair lost packets (such as tail losses).
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.
In this case, including redundancy adds congestion without reducing
goodput but leads to potential fairness issues.  Indeed, the
effective bitrate is 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.
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.
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.
The addition of coding within the flow do not impact on how the coded
and non-coded flows interact.  This interaction would mainly depend
on the congestion controls embedded in each host.
The addition of coding within the flow may impact on 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.
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 residential access.
This document considers fairness as an index to quantify the impact
of the addition of coded flows 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.
The addition of coding within the flow does not impact on the
interaction between coded and non-coded flows.  This interaction
would mainly depend on the congestion controls embedded in each host.
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 flags, to reduce the impact on the
non-coded flows (see subsec:cc-recov-inter-below).
The objective of this subsection is to destribe potential
interactions between the congestion control and the recovered
symbols.
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 objective of this subsection is to describe potential
interactions between the congestion control and the recovered
symbols.
The congestion control may not be able to differentiate repair
symbols from actual source packets.  The relevance of adding coding
at the application layer is related to the needs of the application.
For real-time applications, this approach may reduce the amount of
retransmission.  The usage of a non-reliable transport is more
adequate in this case.
If the two FEC and CC channels are decoupled, the endpoint may
exploit specific protocol for each of the channel.  The channels may
be coupled and one single protocol may be exploited.  In both cases,
the receiver can differenciate source packets and repair symbols.
The receiver may indicate the amount of source packets that have been
received and the amount of repaired symbols that were actually useful
in the recovery process of packets.
The congestion control may not be able to differentiate repair
symbols from actual source packets.  The relevance of adding coding
at the application layer is related to the needs of the application.
For real-time applications, this approach may reduce the number of
retransmission.  The usage of a non-reliable transport is more
adequate in this case.
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.
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 sheme 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.  An example would be a
receiver to indicate that a packet has been recovered by using ECN
signals of TCP.
This section discuss to what extent interaction between the
congestion control and the coding rates are possible.
The coding rate applied at the application layer mainly depends on
the available capacity given by the congestion control underneath.
Adapting the coding rate to the minimum required data rate of the
application may help to reduce packet losses and improve quality of
experience.
This section discusses to what extent the interaction between the
congestion control and the coding rates is possible.
The coding rate applied at the application layer mainly depends on
the available capacity given by the congestion control underneath.
Adapting the coding rate to the minimum required data rate of the
application may reduce packet losses and improve the quality of
experience.
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 be able to
indicate the sender the amount 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 increasing 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 transmission
rate of the congestion control.
The coding rate in this case can be tuned depending on the amount of
recovered symbols and the rate of which data are transmitted by the
sender.  The coding scheme is not aware of the congestion control
implementation, making it hard for the coding scheme to apply the
relevant coding rate.
There are cases where useless repaired symbols may be transmitted.
These have an 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 have an impact on the amount of data generated in the
network.
The sender may be able to exploit the information given by the
receiver to reduce the amount of useless repair packets and the
resulting goodput reduction.
In this case, the useless repaired symbols only have an impact on the
load of the network without actual gain for the coded flow.
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.
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, the coding rate can be tuned depending on the number of
recovered symbols and the rate at which the sender transmits data.
The coding scheme is not aware of the congestion control
implementation, making it hard for the coding scheme to apply the
relevant coding rate.
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 repair packets 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.
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 advice when
evaluating coding mechanisms.
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.
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.