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

Commentary: I think this PR solves most of the issues that have been raised ( and will close them if we merge this PR ) . What do you think ? 
 I 'm ok with whatever all others decide :) 
 In section 4.6 : With coding , you can recover packets a - priori and a - posteriori , so I do not see any conjoint design between coding and the transport layer : if you replace the retransission mechanism by coding , you are more general as you can also recover packets a - priori and coding can offer full reliability if needed or partial reliability if the full reliability is not necessary . So I do not see any need of a conjoint design here : simply replace the retransmission - based reliability mechanism by the coding - based one . I do not really understand what we are trying to say here talking about a conjoint design . What do you think ? 
 I do n't get it either ... could we just remove this ? 
 Commit in PR could solve it all . 
 It is a bit complicated for me to understand correctly the details of Figure 6 : In my opinion , the app does not sublit packets nor a sending rate to the transport layer , so the two arrows above the sender seem a bit weird for me . The app generally submits data , sometimes messages and maybe a minimal transmission rate but it is the transport layer that packetizes the data and sends packets . I guess that the arriws between the sender and the receiver are the wire or the layers below transport . Thus I would replace " source and/or repair packets " by " packets containing source and/or repair symbols " Did I misunderstand the Figure ? 
 I agree ; I think the " sending rate " arrow can be removed ( I 'd say that the rate is at least implicit , in how fast the application gives data to the stack , but this just complicates matters - no need for this arrow anyway ) . I also think that " source packets " could just be " data " ( next to the arrows on the top ) . This applies to figure 5 too ( " source packets " can be replaced with " data " next to these arrows ) , and in figure 3 , in the top left corner , the arrow could also be called " data " instead of " source packets " . 
 There have been some changes due to the issue - I proposed a commit and commit in pr to clarify the unnecessary arrow . 
 In section 3 , we can read the following : I would emphasize on en in - order delivery which is the real problem for FEC here , as a reliable messaging system without in - order delivery would work . I would thus replace the parenthesis by the following : 
 I agree but I 'd use a different replacement : I think it 's good to point out that this is about reliability from something different than coding , and the in - order issue is more than just a refinement in the bracket . So , I would suggest the following : a fully reliable in - order data transfer service ( e.g. , like TCP ) . 
  with in commit of PR 
 In section 2.4 , we say the following : Either I misunderstood the statement or the sentence is not true . In my opinion , with an equal number of sent repair symbols , if the window / block size is larger , the recovery probability is lower as they are likely more lost source symbols in the window / blocks ( with a fixed number of repair symbols ) . 
 Could be clarified by commit of PR 
 In section 2.4 : Why are we talking about a linear system here ? To be more general on the recovery algorithms that are used , maybe should we use the term " block or window " instead of " linear system " What do you think ? 
 The commit of PR makes it more general . 
 I am not totally sure of the meaning of section 2.3 and Figure 4 . More specifically : are we saying that multiple data streams transiting through one single protocol instance are out of the scope of the document ? Do we consider only one single stream on one single protocol instance ? If this is the case , does that mean that we do not consider QUIC 's use - case ? What makes me think all of this is the following sentence : 
 I hope PR and in particular commit clarifies everything 
 In section This is an echo from a previous issue that was not really addressed or " resolved " . I will rephrase the problem from scratch and let me know if you agree with me or not . :-) We describe the FEC channel ( maybe should we call it the Coding channel as repair symbols could also be sent a - posteriori ) and say that it carries repair symbols while the CC channel carries source packets . What do you think of rephrasing it like the following : " The CC channel carries network packets and the coding channel carries source symbols and repair symbols " ? source symbols are an abstract view on the application ( and sometimes control ) data that we want to protect . For example , several source symbols could be present in a single network packet , or several network packets could form one single source symbol . This is why network packets can be very different than source symbols . This also goes in our vision that CC and NC are separated channels and separated entities : they do not even share the concept of packets . What do you think ? 
 I agree there was some confusion here . I tried to solve this in commit of PR 
 Thank you for this great PR . Only one comment , otherwise this is good for me !
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, Explicit Congestion Notification (ECN) marks, etc.) from
the receiver to the sender.  The Forward Erasure Correction channel
carries repair symbols (from the sender to the receiver) and
information from the receiver to the sender (e.g. signaling which
packets have been repaired, loss rate prior and/or after decoding,
etc.).
fig:sep-channel presents the notations that will be used in this
document and introduces the Forward Erasure Correction (FEC) and
Congestion Control (CC) channels.  The Forward Erasure Correction
channel carries repair symbols (from the sender to the receiver) and
information from the receiver to the sender (e.g. signaling which
packets have been repaired, loss rate prior and/or after decoding,
etc.).  The Congestion Control channel carries network packets from a
sender to a receiver, and packets signaling information about the
network (number of packets received vs. lost, Explicit Congestion
Notification (ECN) marks, etc.) from the receiver to the sender.  The
network packets that are sent by the Congestion Control channel may
be composed of source packets and/or repair symbols.
'source and/or repair symbols' (data plane for both the FEC and
the CC): refers to the data that is transmitted.  The sender can
decide to send source symbols only (meaning that the coding rate
is 0), repair symbols only (if the solution decides not to send
the original source packets) or a mix of both.
'network packets' (output data plane for the CC): refers to the
data that is transmitted by a CC sender to a CC receiver.  The
network packets may contain source and/or repair symbols.
'source and/or repair symbols' (data plane for the FEC): refers to
the data that is transmitted by a FEC sender to a FEC receiver.
The sender can decide to send source symbols only (meaning that
the coding rate is 0), repair symbols only (if the solution
decides not to send the original source symbols) or a mix of both.
The application layer may be composed of several streams above FEC
and transport layers instances.  The different streams could exploit
different paths between the sender and the receiver or not.  The
document considers one application layer stream as input packets
above a combination of FEC and transport layers.  In fig:multi-scope,
each of stream 1 and stream 2 are considered in the scope of the
document but a combination of stream 1 and stream 2 is not.  The case
of multiple application level streams above multiple FEC and
transport layers instances is out of the scope of the document and
not further described.
The application layer may be composed of several streams above FEC
and transport layers instances.  The transport layer may exploit a
multipath mechanism.  The different streams could exploit different
paths between the sender and the receiver or not.  This section
describes what is in the scope of this document in regards with
multi-streams applications and multipath transport protocols.
The different combinations between multi-stream applications and
multipath transport are the following: (1) one application layer
stream as input packets above a combination of FEC and multipath
(Mpath) transport layers (fig:multi-scope-single-stream), and (2)
multiple application layer streams as input packets above a
combination of FEC and multipath (Mpath) or single path (Spath)
transport layers (fig:multi-scope-multi-stream).  In fig:multi-scope-
single-stream, each of stream 1 and stream 2 are considered in the
scope of the document.  In fig:multi-scope-multi-stream, the case
with single path transport is considered in the scope of this
document but the cases with mutipath transport is not.  The case of
multiple application level streams above multiple transport layers
instances is out of the scope of the document and not further
described.
Full reliability: The receiver may hold symbols until the decoding
of source packets is possible.  In particular, if the codec does
not enable a subset of the linear system to be inverted, the
receiver would have to wait for a certain minimum amount of repair
packets before it can recover all the source packets.
Partial reliability: The receiver cannot deliver source packets
that could not have been decoded to the upper layer.  If the size
of the encoding window (for Sliding Window Coding) and the size of
the blocks (for Block Coding) are large, the chances of recovering
the erased symbols would increase.  However, this would impact on
memory requirements and the cost of encoding and decoding
processes.
Full reliability: The receiver may hold symbols until the decoding
of source symbols is possible.  In particular, if the codec does
not enable a subset of the system to be inverted, the receiver
would have to wait for a certain minimum amount of repair packets
before it can recover all the source symbols.
Partial reliability: The receiver cannot deliver source symbols
that could not have been decoded to the upper layer.  For a fixed
size of encoding window (for Sliding Window Coding) or of blocks
(for Block Coding) containing the source symbols, increasing the
amount of repair symbols would increase the chances of recovering
the erased symbols.  However, this would impact on memory
requirements, on the cost of encoding and decoding processes and
on the network overhead.
This approach requires that the transport protocol does not implement
a fully reliable data transfer service (e.g., based on lost packet
retransmission).  QUIC with unreliable datagram extension I-D.ietf-
quic-datagram is an example of a protocol for which this is relevant.
In cases where QUIC traffic is blocked and a fall-back to TCP is
proposed, there is a risk for bad interactions between TCP's full
reliability and coding schemes.  For reliable transfers, coding usage
does not guarantee better performance; instead, it would mainly
reduce goodput.
This approach requires that the transport protocol does not implement
a fully reliable in-order data transfer service (e.g., like TCP).
QUIC with unreliable datagram extension I-D.ietf-quic-datagram is an
example of a protocol for which this is relevant.  In cases where
QUIC traffic is blocked and a fall-back to TCP is proposed, there is
a risk for bad interactions between TCP's full reliability and coding
schemes.  For reliable transfers, coding usage does not guarantee
better performance; instead, it would mainly reduce goodput.
The congestion control mechanism 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 using an unreliable or
partially reliable transport, this approach may reduce the number of
losses perceived by the application.
The congestion control mechanism receives network packets and may not
be able to differentiate repair symbols from actual source ones.  The
relevance of adding coding at the application layer is related to the
needs of the application.  For real-time applications using an
unreliable or partially reliable transport, this approach may reduce
the number of losses perceived by the application.
The application may require partial reliability.  In this case, the
transport and FEC mechanisms could be conjointly designed.  As one
example, the reliability offered by FEC may be sufficient, with no
retransmission required.  This depends on application needs and the
trade-off between latency and loss.  Partial reliability impacts the
type of FEC and type of codec that can be used, such as discussed in
subsec:def_code.
The application may require partial reliability.  The reliability
offered by FEC may be sufficient, with no retransmission required.
This depends on application needs and the trade-off between latency
and loss.  Partial reliability impacts the type of FEC and type of
codec that can be used, such as discussed in subsec:def_code.