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

Commentary: Looks good to me ! 
 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 
 The current version of hte draft seems to go for a more " server " side discussion . We should not forget to speak about the client . 
 I agree - but maybe delay this until the next version of the draft ? 
 I have pushed some content with some more details on the server side solutions . I think we may be soon ready to either submit this version or had a small section on the receiver side . It can be very simple IMHO : " The receiver must not use CC channel signals to acknowledge the recovery of data packets with the coding schemes . The information on recovered packets must be reported on the FEC channel . " 
 I agree with both approaches . I 'd vote for shipping it as - is ( better to have a more useful discussion on the receiver side - surely we can come up with something more for the next version of the draft ? ) 
 Thanks for the feedback - I would vote the same . Any other thoughts ? 
 This is done in PR 
 LGTM modulo a minor suggestion , but that was from a quick glance only ... ca n't dedicate more time this round , sorry !
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.  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 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.
'signaling about losses and/or repaired packets' (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 packets' (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.
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.
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.
This section discusses how FEC and CC can relate in different cases
(FEC above the transport, FEC within the transport, FEC below the
transport).
fig:fec-above illustrates the FEC above the transport case.
fig:fec-above presents an architecture where FEC is on top of the
transport.  The repair packets are sent within what the congestion
window allows.
The advantage of this approach is that the FEC does not contribute to
adding congestion in the network.
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.
fig:fec-in illustrates the FEC within the transport case.
fig:fec-in presents an architecture where FEC is within the
transport.  The repair packets are sent within what the congestion
window allows, such as in CTCP.  Examples of the solution would be
sending repair packets when there is no more data to transmit or
preferably send repair packets instead of the following packets in
the send buffer.
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.  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.
fig:fec-above present an architecture where FEC is on top of the
transport.
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 may require that the
transport protocol does not implement a fully reliable data transfer
service (e.g., based on lost packet retransmission), otherwise this
could lead to spurious retransmissions.  UDP is an example of a
protocol for which this approach is relevant.
The advantage of this approach is that the FEC does not contribute to
adding congestion in the network.  When a congestion control is
implementedd at the transport layer, the repair packets are sent
within what the congestion window allows.
fig:fec-in presents an architecture where FEC is within the
transport.  The repair packets are sent within what the congestion
window allows, such as in CTCP.
fig:fec-below illustrates the FEC below the transport case.
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.
Examples of the solution would be sending repair packets when there
is no more data to transmit or preferably send repair packets instead
of the following packets in the send buffer.
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.