Re: [LOOPS] LOOPS Comments

Hi,

Thank you very much for your comments.
FWIW, I very much agree with them - your ECT comment in particular: that would make things a lot easier for LOOPS, and who knows, maybe it could even help incentivize ECN deployment?

Cheers,
Michael

> On May 13, 2020, at 6:01 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> 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
> -- 
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops