Re: [LOOPS] LOOPS Comments

[wangjl50 <[e-mail]>]

 Hi,
 
I agree with starting with the specific transport behavior.
 
LOOPS enabled in-network recovery is most likely to be enable for certain applications, not all traffic. As operator, we can identify the traffic from those applications and  direct them to LOOPS enabled tunnel ingress.
 
Talking about means for endpoints to aware the LOOPS enabled service somewhere in the middle and be correctly configured, I believe it is highly feasible for the direction from the server to the client. We can assume specific behaviors at the server side for, e.g. ECN enablement, DUPACK based loss detection or time-based loss detection.
For applications like gaming ( e.g. Arena Of Valor, a local popular game here), traffic from server to client direction highly affects the experience of customers. In-network recovery would be good to help in this case.
 
A slightly different case is payment. There are very small number of packets in both directions. The host sender (no matter which direction) does not necessarily care about the window adjustment as it is very likely a one-time sending. What matters is simply to save the potential tail loss as soon as possible. In-network recovery could help here without worrying too much about how the e2e sender would detect or react to a loss. As long as the packet is recovered quickly, we are good.  

Best regards
Jianglong Wang

 
From: Martin Duke
Date: 2020-05-14 00:01
To: loops
Subject: [LOOPS] LOOPS Comments
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