[LOOPS] LOOPS Comments

[Martin Duke <[e-mail]>]

High-level comments about LOOPS:

This work will be valuable in several use cases, in particular encrypted
transports (or IPSec) running over links with RF losses. I think it would
benefit from a more detailed consideration of what problem(s) you are
trying to solve. A generalized solution will require lots of additional
mitigation mechanisms, which would scale up the work significantly.

The gen-info and problem-opportunities drafts mention a lot of these
concerns, and imply several different mechanisms.

For example:
- Detecting congestion losses vs. RF losses: this is hard, but certain
network architectures can eliminate the problem by, e.g. rate limiting at
the ingress point.
- ECT vs non-ECT traffic: a general solution will have to provide different
mechanisms for both; if it is sufficient to initially support one or the
other, that may be half as much algorithm to design.
- Relatedly, initially requiring the entire LOOPS path to support ECN
marking would reduce the problem space.
- Varying transport behaviors: different flows will have different e2e
latencies, reordering thresholds, and reactions to delay variation and
delay spikes. These will be hard to detect! It may be unavoidable to do a
lot of work here, but limiting the cases where LOOPS can be applied (e.g.
the added delay is a small fraction of the LOOPS segment min delay, which
IIUC would require FEC) would simplify as much as possible. Alternatively,
if there is a means for endpoints to explicitly request the service, then
one can assume that they have configured themselves correctly to leverage
LOOPS.
- Identifying one, or a handful, of tunneling protocols with a good
deployment story before chartering will reduce the risk there is not a
critical mass to do any of them.

One possible minimal increment of work would be: FEC-based LOOPS with a
Geneve encapsulation to be applied only to ECT-marked traffic over a
segment with ECN-enabled routers and a rate limiter at ingress.

I emphasize that the above is only example of a use case that is
constrained enough to present a small group of problems to solve. I'd
encourage the group to zoom in on a similarly constrained use case that
meets demand in the real internet.

A similarly constrained used case would allow you to put in the basic
protocol elements and then recharter to tackle more difficult problems.

Martin