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

Commentary: I agree with all your comments . I think we could have a chat at some point to discuss the sentence that has been deleted . 
 Cool . About discussing : anytime ! 
 : what do you think of this PR ? I think this solves the current open issues of the document and once we agree , we could publish this , send an email to the list and advertise the document in other research groups . 
 I like the PR and I agree with you . Others ? 
 Fine for me 
 This is an IRTF document how is this relating to current research and where ? CC and NC are essentially two competing control loops - there is a lot of heritage on that topic ( outside networking too ) - what can NC / CC learn from that - any research questions ? My experience with NC is that the most gains are in low loss networks ( far from network capacity ) - where in fact CC protocols over react- is there research on appropriate metrics ? Most of the gain seems to be in last - mile / access networks - any other research ? -All of this to say that the draft should be clearer on the type of research that is needed again when the performance is impacted 2 conflicting control loops . 
 I think the draft touches upon quite a number of research ideas / possibilities , but they 're " hidden " in the structure perhaps ... so I believe this is a matter of making them explicit , let them stand out - perhaps a section towards the end that summarizes pulls them together and summarizes ? 
 It would be good . Thanks .      , Ph.D. 
 I think this is covered by the research questions in the dedicated section - see PR 
 From  's email : While working on RFC 8681 on sliding window codes , we tried to find appropriate parameter derivation techniques . It turned out to be quite difficult . You can have a look at the discussion here : 
 Feedback from IETF110 : Refer to existing RFC Same as far issue , the impact of the type of codes ( block vs sliding ) , size of the blocks , etc . 
 The research question section has been modified in PR 
 From  's email : * * Section 3.6 : I would say that partial reliability essentially impacts the type of FEC and type of codec you can use . If your codec does not enable a subset of the linear system to be inverted , but instead waits to have the perfect expected rank to invert and recover missing packets , you wo n’t achieve partial reliability . Partial reliability also impacts the way you use a block FEC : in that case , I ’d say use small block sizes , so that you can solve one of them but not necessarily all of them … except that it will also lower the robustness in front of long loss periods . This is typically where sliding window codes do offer a key advantage . ( see ) 
 Feedback from IETF110 meeting : Mention the difference between block and sliding window codes , the impact of the size of the blocks , etc . 
 Propose closure with PR 
    I am following the evolution of this draft and while the issues are starting to be well covered this is RG document so while I approve of the changes it would be nice to highlight the research that is still needed .       comment : I agree , and I think that we could approach this by trying to find at least one published example of research per category - ideally the " best " per category . This would show , wherever we find something , what the SoA is - research could focus on improving this SoA. Also , it would probably give us some holes - e.g. , I do n't think there 's any much research on ( e2e ! ) FEC " below the transport " , especially using multiple CC instances as hinted on in the draft . These holes would let us identify missing research . 
 I see two examples of FEC below the transport , maybe am I forgetting other ones . SUNDARARAJAN ,   , SHAH ,  , MÉDARD ,  , et al . Network coding meets TCP : Theory and implementation . Proceedings of the IEEE , 2011 , vol . 99 , no 3 , p. 490 - 512 . ( ) There is a variant with MPTCP ( ) Tetrys ( ) can be used below the transport as a tunnel as discussed here : For the use of FEC inside the transport I know that there is a use of FEC with RTP and WebRTC , I saw it in the source code of some browsers but I do n't know a well - cited research paper about this . There are RFCs however : and this very short article : For QUIC , I know three articles proposing FEC inside the transport :  ,  , De Coninck , Q. , & Bonaventure ,  ( 2019 , May ) . QUIC - FEC : Bringing the benefits of Forward Erasure Correction to QUIC . In 2019 IFIP Networking Conference ( IFIP Networking ) ( pp . 1 - 9 ) . IEEE . ( ) -use of a RECOVERED frame to indicate when a packet is recovered and does not hide the losses to the congestion control GARRIDO , Pablo , SANCHEZ , Isabel , FERLIN ,  , et al . rQUIC : Integrating FEC with QUIC for Robust Wireless Communications . In : 2019 IEEE Global Communications Conference ( GLOBECOM ) . IEEE , 2019 . p. 1 - 7 . ( ) -they seem to hide the congestion - induced losses to cubic using FEC to increase their bitrate ( but no clear discussion on that ) PALMER ,  , KRÜGER ,  , CHANDRASEKARAN ,  , et al . The quic fix for optimal video streaming . In : Proceedings of the Workshop on the Evolution , Performance , and Interoperability of QUIC . 2018 . p. 43 - 49 . ( ) -No clear discussion on what is done regarding the congestion control ( i.e. are the recovered pacekts  or not ? ) . I am not really into this one as they basically state that using TCP for video streaming does not work well in general even with cases under 1 % of losses and make claims such as this one : Do not hesitate if you have other references . I think one good research " advice " we could point out is to include a discussion concerning the impact of the proposed FEC solution on the congestion control , especially loss - based congestion control such as cubic . There is often no discussion on that . 
 A new section on open research questions has been 
 Some more , I think they 're all " Inside transport " : Flach ,  , Dukkipati , N. , Terzis , A. ,  , B. , Cardwell , N. , Cheng , Y. , Jain , A. ,  , S. ,    , E. , and   , " Reducing Web Latency : the Virtue of Gentle Aggression " , Proceedings of the 2013 ACM SIGCOMM , 2013 . ( I think that 's the same work as the now - expired draft - flach - tcpm - fec )   ,   , Claussen H ,    meets FEC : Supporting latency - sensitive applications over heterogeneous networks . IEEE / ACM Transactions on Networking . 2018 Aug 29;26(5):2005 - 18 . ( this extends the Flach et al idea of " instant recovery " to MPTCP )   , Lundqvist H ,    end - to - end FEC for improving TCP performance over wireless links . In2004 IEEE International Conference on Communications ( IEEE Cat . No . 04CH37577 ) 2004 Jun 20 ( Vol . 7 , pp . 4023 - 4027 ) . IEEE .   ,   ,    using adaptive FEC to improve throughput performance in high - latency environments . IEICE Transactions on Communications . 2018 . 
 For a high - level overview of this research , see :
Block Coding: Coding technique where the input Flow must first be
segmented into a sequence of blocks; FEC encoding and decoding are
performed independently on a per-block basis.
Sliding Window Coding: general class of coding techniques that
rely on a sliding encoding window.
The decoding scheme may not be able to decode all the symbols.  The
chance of decoding the erased packets depends on the size of the
encoding window, the coding rate and the distribution of erasure in
the transmission channel.  The FEC channel may enable the
transmission of information related to the need of supplementary
symbols to adapt the level of reliability.  Partial and full
reliability could be envisioned.
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.
The application may require partial reliability.  In this case, the
coding rate of a FEC mechanism could be adapted based on inputs from
the application and the trade-off between latency and packet loss.
Partial reliability impacts the type of FEC and type of codec that
can be used.
The application may require partial reliability.  In this case, the
coding rate of a FEC mechanism could be adapted based on inputs from
the application and the trade-off between latency and packet 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.  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.
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 transport or application layer above the FEC channel may require
partial reliability only.  In this case, FEC may provide an
unnecessary service if it is not aware of the reliability
requirements.  Partial reliability impacts the type of FEC and type
of codec that can be used.
The transport or application layer above the FEC channel may require
partial reliability only.  In this case, FEC may provide an
unnecessary service if it is not aware of the reliability
requirements.  Partial reliability impacts the type of FEC and type
of codec that can be used, such as discussed in subsec:def_code.
For the FEC above transport case, there is a trade-off related to the
amount of redundancy to add, as a function of the transport layer
protocol and application requirements.
For the FEC within transport case, recovering lost symbols may hide
congestion losses from the congestion control.  Some existing
solutions already propose to disambiguate acked packets from rebuilt
packets QUIC-FEC.  New signaling methods and FEC-recovery-aware
congestion controls could be proposed.
For the FEC below transport case, there are opportunities for
introducing interaction between congestion control and coding schemes
to improve the quality of experience while guaranteeing fairness with
other flows.  New signaling methods and FEC-recovery-aware congestion
controls could be proposed.  An open question also resides in the
relevance of FEC when there are multiple streams that exploit the FEC
channel.
There is a trade-off related to the amount of redundancy to add, as a
function of the transport layer protocol and application
requirements.
RFC8095 describes the mechanisms provided by existing IETF protocols
such as TCP, SCTP or RTP.  RFC8406 describes the variety of coding
techniques.  The important level of combinations makes the
determination of an optimum parameters derivation very complex.  This
depends on application requirements and deployment context.
Appendix C of RFC8681 describes how to tune the parameters for target
use-case.  However, this discussion does not integrate congestion-
controlled end points.
Recovering lost symbols may hide congestion losses from the
congestion control.  Disambiguating acked packets from rebuilt
packets would help the sender adapts its sending rate accordingly.
There are opportunities for introducing interaction between
congestion control and coding schemes to improve the quality of
experience while guaranteeing fairness with other flows.
Some existing solutions already propose to disambiguate acked packets
from rebuilt packets QUIC-FEC.  New signaling methods and FEC-
recovery-aware congestion controls could be proposed.