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

Commentary: Never say what follows : There is no security considerations required for this document . There are security considerations in most documents , because it does change something ( which is fortunate ) and therefore it can introduce threats . Here CC and FEC coding rate could be leveraged to create DoS. Although it 's not specific to this document , saying the opposite is not appropriate . 
 Done in PR 
 I appreciate to see these three sections , but I think they should be grouped as subsections of a single one entitled : " Recommendations depending on the CC versus FEC layering " or something like that . And adding a small introduction text would be fine too . There 's really an ambiguity about what is coded data : does it include source data packets or not ? And why data rather than packets ? Have a look at our terminology RFC and stick with it . I do not agree about the following wording : The drawback of this approach is that it is useless if the transport guarantees data delivery by retransmitting packets . This is only a drawback if one is stupid enough to do FEC protection on top of a reliable transport protocol . I 'd rather say : Of course , this approach requires that that the transport protocol does not include a reliability ( e.g. , based on lost packet retransmition ) . This approach is perfectly fine with UDP which is pretty usual . This is suggested in the figure ( " sending rate or window " ) , but not detailed in text . There is preferably a feedback between CC and FEC entities . 
 Covered in PR 
 Section 3.1 is pretty concise . What type of " transmission " ? In intro you say that tunnels are out of scope , which should be clarified and justified here . Do you restrict yourself to transport protocols ( where CC is usually found ) ? Do you want to extend to application protocols as well ( with the difficulty of defining what is an application protocol , since we see more and more protocols on top of UDP ) . Do you consider multipaths ? Do you keep multicast as out of scope as there is a dedicated CC that is pretty different ? A new idea is introduced here , that of " fairness with non - coding solutions " . It should prominently mentioned in abstract and introduction as well . I 'm surprised to see " Section 3.3 . Objective of the document " at this moment in the document . Please put it before . The first two sentences about mixing the CC and FEC channels should also be moved at the end of section 2 , it does not belong to the objectives . 
 About fairness : I 'd rather say that this only concerns the case in section 6 , FEC below the transport , and should be discussed only there . 
 This section may not be relevant if we move all the discussions of the scope in the Introduction . This is what has been done in PR 
 Mention of fairness has been removed and the present focus of the draft is unicast single path transfer . 
 A detail : arrows are missing in fig . 1 . Or perhaps it is indicated by the use of { and } , but in that case it 's not very clear . Using plural is also preferable . A detail : there is no " coded data " but " coded packets" . It is said : " signaling from the receiver about losses and/or repaired blocks " The use of " blocks " here is erroneous , we talk about packets . I 'd also suggest that you change the mention " information about repaired ratio " in fig . 2 by what you say here , in the text . What exact information is given back to the FEC entity really depends on the use - case , but I like the way it 's written in the text : it 's some information about what is lost and what is recovered thanks to FEC coding . It is said : However , there can be meaningful other interactions ( indicated by the horizontal double arrow ) between the two entities , There is no horizontal double arrow ! And I can not really decide whether entities refer to client / server or CC / FEC . typo : potiential = potential 
 Thanks . Updated in PR 
 Minor comment : It is said ( 2nd sentence ): ... for the server to detect tail losses ... Make it clear that in this document , the server sends data . Ambiguous : One objective is to help the research community consider congestion control aspects when proposing and comparing coding solutions . I 'd rather say : Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems . Rationals : this is another objective ; comparing FEC Schemes without considering congestion control makes sense if the goal is to compare those schemes only . 
 Thanks . This is covered in PR 
 I do not understand : This document can help the comparison of FEC schemes by identifying at which level they are operating with respect to the transport congestion control . What does " the comparison of FEC schemes " refer to ? Between one another ? I guess this is not the intent ( and this is explained later on ) . Global comment , title including : using " coding " without any further information , is ambiguous . I 'd prefer FEC coding or erasure correction coding , at least in the abstract / introduction . 
 The intent is indeed to help the comparison of different FEC schemes . There are cases where a FEC scheme A hide losses to a congestion control , while a FEC scheme B do not . Comparing A and B is not fair . The comment on using " coding " is dealt with in PR
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 can coexist.  This document can help the
comparison of FEC schemes by identifying at which level they are
operating with respect to the transport congestion control.
This document is the product of the Coding for Efficient Network
Communications Research Group (NWCRG).  The scope of the document is
end-to-end communications: coding for tunnels is out-of-the scope of
the document.
There are cases where deploying coding improves the quality of the
transmission.  As an example, it may take time for the server to
detect tail losses and 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 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.
This memo offers a discussion of how coding and congestion control
can coexist.  One objective is to help the research community
consider congestion control aspects when proposing and comparing
coding solutions.
This document represents the collaborative work and consensus of the
Coding for Efficient Network Communications Research Group (NWCRG);
it is not an IETF product and is not a standard.  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 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.
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.  This document can
help the comparison of FEC schemes by identifying at which level they
are operating with respect to the transport congestion control.
This document is the product of the Coding for Efficient Network
Communications Research Group (NWCRG).  The scope of the document is
end-to-end communications: FEC coding for tunnels is out-of-the scope
of the document.
There are cases where deploying FEC coding improves the quality of
the transmission.  As an example, when a server transmits data to a
client, it may take time for the server 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.
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.
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.
This document represents the collaborative work and consensus of the
Coding for Efficient Network Communications Research Group (NWCRG);
it is not an IETF product and is not a standard.  The document
follows the terminology proposed in the taxonomy document RFC8406.
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 server to a client) and potential
information signaling the packets that have been received (from the
client to the server).  The Forward Erasure Correction channel
carries repair packets (from the server to the client) and a
potential 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.
fig:sep-entities provides more details than fig:sep-channel by
focusing on the server side.  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.
This section describes the scope of the document.
The document focuses on reliable transmissions.
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.
fig:fec-above presents an architecture where FEC is on top of the
transport.  The coded packets are sent within what the congestion
window allows.
The drawback of this approach is that it is useless if the transport
guarantees data delivery by retransmitting packets.
fig:fec-in presents an architecture where FEC is within the
transport.  The coded packets are sent within what the congestion
window allows, such as in CTCP.  Examples of the solution would be
sending coded packets when there is no more data to transmit or
preferably send coded packets instead of the following packets in the
send buffer.
The advantage of this approach is that it can enable conjoint
optimization between the CC and the FEC.  Moreover, the transmission
of coded 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 non coded data
packets.  The coding ratio needs to be carefully designed.
fig:fec-below presents an architecture where FEC is below the
transport.  The coded 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 coded 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.
'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).
'requirements' (input control plane for the transport including
CC): refers to application requirements such as upper/lower rate
bounds, periods of quiescence, or a priority.
'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'.
'signaling about losses and/or repaired packets' (input control
plane for the FEC): refers to the information a FEC server can
obtain from a FEC client about the performance of the FEC solution
as seen from the client.
'coding rate' (output control plane for the FEC): refers to the
coding rate that is used by the FEC solution.
'source and/or repair packets' (data plane for both the FEC and
the CC): refers to the packets that are transmitted.  There can
only be source packets (if the coding rate is 0), repair packets
(if the solution decides not to send the original source packets)
or a mix of both.
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.
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 presents an architecture where FEC is on top of the
transport.  The repair packets are sent within what the congestion
window allows.
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.
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 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.
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.
FEC and CC schemes can contribute to DoS attacks.  This is not
specific to this document.