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

Commentary: These are the most significant changes that this proposes : fig . 1 : because of Francois ' change to sender - receiver , it is now odd ( in the western world ) to have the sender on the right and the receiver on the left . I flipped this around . I also changed " network measurements " to " network information " everywhere . I know , I started this " network measurements " thing , but I think the term excludes explicit information ( ECN ) . I adjusted the phrasing everywhere . because I explain what " network information " is where we introduce fig.1 , this item is now removed from the list of newly introduced things below fig . 2 . security considerations now mention unfairness that one could get in the FEC - below - transport case only . 
 I see a major scoping problem in these sections . What does this document really aim at ? It is said earlier : This document discusses how FEC and CC relate . Here we see architectural discussions on advantages / drawbacks instead . There is also the additional idea of how it relates to transport reliability mechanism which is ( in theory ) out of scope . I 'd like to see more info about what concretely can be done ( examples ) . The case of QUIC and what was already proposed here to let FEC and CC work together is pretty interesting . I also think the application ( as data source ) is potentially involved in the big picture : an application generating a real - time data flow is not the same as an application generating background traffic . In the first case we could end up with situations where it 's just impossible to carry traffic by adding a certain redundancy , given the network conditions . It means that without adapting the data flow there is probably no solution . In the second case ( which includes François 's experiments with tail losses ) 
 item 1 : I think this is now addressed by careful phrasing in the para that mentions reliability , in PR . Item 2 : I agree but I 'd greatly prefer if we could postpone this to the next version . I think we should include multipath considerations too , so this will be quite a bit of work . Item 3 : I agree ... someone should write something :) 
   addressed by PR Open for next submission I 'd like to see more info about what concretely can be done ( examples ) . The case of QUIC and what was already proposed here to let FEC and CC work together is pretty interesting . I also think the application ( as data source ) is potentially involved in the big picture : an application generating a real - time data flow is not the same as an application generating background traffic . In the first case we could end up with situations where it 's just impossible to carry traffic by adding a certain redundancy , given the network conditions . It means that without adapting the data flow there is probably no solution . In the second case ( which includes François 's experiments with tail losses ) 
 I am not sure I completely get the last item though . More specifically , I do n't know what to say about this in this draft about the relations between coding and the congestion control . We could state that the application can provide information about importance or deadline concerning its data , but I think the optimal FEC pattern , with or without congestion , will likely depend on the application 's requirements in the end ? Does anybody have a clearer idea on what we could state on this ? Let 's discuss this here before writing ? 
 I think you 're trying to find a solution , whereas we 're only describing a situation . The latter is simpler : we can basically repeat what  has told us : " an application generating a real - time data flow is not the same as an application generating background traffic . In the first case we could end up with situations where it 's just impossible to carry traffic by adding a certain redundancy , given the network conditions . It means that without adapting the data flow there is probably no solution . " Just point it out . 
 Looks good to me . Thank you ! 
 The application requirements aspect have been covered by PR
FEC coding is a reliability mechanism that is distinct and separated
from the loss detection of congestion controls.  Using FEC coding can
be a useful way to better deal with transfer tail losses or with
networks with 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.  That being said, this document does not aim
at proposing FEC coding solutions characterization guidelines:
comparing FEC Schemes without considering congestion control can be
relevant if the goal is to compare those schemes only.
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.
There are cases where deploying FEC coding improves the quality of
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.
Coding is a reliability mechanism that is distinct and separated 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.
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.  That being said, this document does not aim
at proposing FEC coding solutions characterization guidelines:
comparing FEC Schemes without considering congestion control can be
relevant if the goal is to compare those schemes only.
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.
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 source packets (from a sender to a receiver) and potential
information signaling the packets that have been received (from the
receiver to the sender).  The Forward Erasure Correction channel
carries repair packets (from the sender to the receiver) and a
potential information signaling the packets that have been repaired
(from the receiver to the sender).  It is worth pointing out that
there are cases where these channels are not separated.
fig:sep-channel presents the notations that will be used in this
document and introduces the Congestion Control (CC) and Forward
Erasure Correction (FEC) channels.  The Congestion Control channel
carries source packets from a sender to a receiver, and packets
signaling information about the network (number of packets received
vs. lost, ECN marks, etc.) from the receiver to the sender.  The
Forward Erasure Correction channel carries repair packets (from the
sender to the receiver) and potential information signaling which
packets have been repaired (from the receiver to the sender).  It is
worth pointing out that there are cases where these channels are not
separated.
'network measurements' (input control plane for the transport
including CC): refers to the information a ongestion control can
obtain from a network (e.g.  TCP can estimate the latency, the
loss rate and 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 measurements'.
'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 (packet to work upon, and signaling from the
receiver about losses and/or repaired packets) are distinct from the
inputs to CC.  The latter calculates a sending rate or window from
network measurements, 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.
The inputs to FEC (packets to work upon, and signaling from the
receiver about losses and/or repaired packets) 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.
This approach requires that the transport protocol does not include a
reliability (e.g., based on lost packet retransmition).  This
approach is relevant with UDP.
While CC is in principle independent of other transport functions
such as reliability, we note that CC is often embedded in reliable
transfer protocols (e.g.  TCP).  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.
The advantage of this approach is that it can enable conjoint
optimization between the CC and the FEC.  Moreover, the transmission
of repair packets does not add congestion in potentially congested
networks but help repair lost packets (such as tail losses).
The drawback of this approach is that it may not result in much gains
as opposed to classical CC retransmissions mechanisms and it costs
bandwidth that could have been exploited to transmit source packets.
The coding ratio needs to be carefully designed.
The advantage of this approach is that it can enable conjoint
optimization between the CC and the FEC.  Moreover, the transmission
of repair packets does not add congestion in potentially congested
networks but helps repair lost packets (such as tail losses).
The drawback of this approach is that it may not result in much gains
as opposed to classical retransmission mechanisms and it costs
bandwidth that could have been exploited to transmit source packets.
The coding ratio needs to be carefully designed.
fig:fec-below presents an architecture where FEC is below the
transport.  The repair packets are sent on top of what is allowed by
the congestion control.  Examples of the solution could be adding a
given percentage of the congestion window as supplementary packets or
sending a given amount of repair packets at a given rate.  The
redundancy flow can be decorrelated from the congestion control that
manages source packets: a secondary congestion control could be
introduced underneath the FEC layer, 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.
fig:fec-below presents an architecture where FEC is below the
transport.  The repair packets are sent on top of what is allowed by
the congestion control.  Examples of the solution could be adding a
given percentage of the congestion window as supplementary packets or
sending a given amount of repair packets at a given rate.  The
redundancy flow can be decorrelated from the congestion control that
manages source packets: a secondary congestion control could be
introduced underneath the FEC layer.  The separate congestion control
mechanisms could be made to work together while adhering to
priorities, as in coupled congestion control for RTP media I-D.ietf-
rmcat-coupled-cc.  Another possibility would be to exploit a lower
than best-effort congestion control RFC6297 for repair packets.