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

[Carsten Bormann <[e-mail]>]

> I skimmed the drafts, but might be missing some context still ... LOOPS seems like it is intended for “dumb" subnetworks, but could be potentially harmful over "smarter" subnetworks.

If the path segment already tries to be “helpful”, there might indeed be an adverse interaction.  Or the “help” might only be available or effective for certain transport protocols, and LOOPS can still do something useful for those not (yet!) covered (for instance, this could be QUIC).  Also, the “help” might be geared towards close interaction with the transport, and adding a tunnel layer could interfere with this.  So whether running LOOPS on a Sat PEP is useful in any way or even detrimental depends a lot on how up-to-date that PEP is.  Note that the entity running LOOPS may not be the entity running the Sat PEP, so it may not have control over the PEP situation.

Running LOOPS on the path segments from host to Sat and from the Sat to host can remove the need for some costly (in bandwidth and latency) retransmissions on the Sat link itself.  

> For satellite links, there is the capability to do per-frame adaptive coding and modulation (based on traffic classification).  When the lower layer offers service tailored for the needs of each packet already, LOOPS doing something up above is possibly at odds with this.  It’s easy to imagine scenarios where this leads to actual performance degradation, positive feedback loops, or other problems, so I'm interested in what people have done or been thinking about in this regard.

LOOPS is not meant as pixie dust that you sprinkle indiscriminately over your network.
The cost is not entirely trivial and the benefits depend on the characteristics of both the path and the traffic.
You should have a reason to use LOOPS.
See above for some potential reasons to use LOOPS on top of Sat PEPs.

Grüße, Carsten