Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

[Carsten Bormann <[e-mail]>]

Hi Marie-José,

> <mjm> There are FEC mechanisms to adapt coding dynamically based on acknowledgments for example. In the QUICK implementation we will have flag a RECOVERED packet that could be used to adapt the coding rate. Other implementations or code-specific protocols are also available.

Right.  So a LOOPS variant will still need to be developed.

>> 	• 
>> How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically?
> <mjm> Well the use of FEC (or not) is a design decision.  Of course you need the code (and the libraries). And then the decision will be based on known link condition, goodput, expected performance, type of traffic (video, time sensitive etc.). And finding a tunnel and PEPs if you need to. And it can depend on path statistics and not being end to end. I am not sure you could standardize that decision.

What can be decided unilaterally does not need to be standardized.
Information that needs to be collected in cooperation between both ends to enable this decision (“measurement information”) may need to be standardized.

In any case, the LOOPS stance to setting up the channel is a “controller model”, i.e. we don’t plan to have negotiation or some such in the protocol, but expect a controller to set up both ends in a coordinated way.  This is probably the biggest item that needs to be added to enable host-to-node mode, as the host is less likely to be involved in that controller model (even though it could be, that part would then also need to be standardized).

>> How a sender knows that it shouldn't be doing anything, because anything it does won't help ("first, do no harm")?
> <mjm> Of course in a congested network doing nothing is probably best. Again there is a lot of work on the interaction of coding and congestion control.

Right, which would need to be worked out into a protocol plus at least some basic best current practice algorithms for LOOPS.

> <mjm> Not everyone knows the things but there has been a lot of work in FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the work was done in a research group not a working group. But real implementations exist in famous “networks”. 

Great.  So let’s start to identify those documents that are nearly ready to be used and fit well.  E.g., for NWCRG, I’m aware of:

  "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC)
  Schemes for FECFRAME", Vincent Roca, Belkacem Teibi, 2019-06-18,
  <draft-ietf-tsvwg-rlc-fec-scheme-16.txt>


and possibly (I’m not sure yet LOOPS will be a straightforward application of FECFRAME):

  "Forward Error Correction (FEC) Framework Extension to Sliding Window
  Codes", Vincent Roca, Ali Begen, 2019-01-11,
  <draft-ietf-tsvwg-fecframe-ext-08.txt>

> 
> <mjm> Since most of your questions are about erasure coding (coding for packet loss) is that a direction LOOPS wants to take? Somekind of nwcWG?

In a certain way, very much so.  Now LOOPS is intended to have a retransmission mode, too, which probably would go beyond standard fare of NWCRG.  I’m also not sure that the finer points of measurement that are needed (bilaterally) to enable really good LOOPS implementations (mostly unilaterally) are covered in NWCRG, and I’m also not sure about congestion feedback.  But I wouldn’t mind to call the thing NWCWG, as long as we get to ship the retransmission mode first.

Grüße, Carsten