Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room

[Carsten Bormann <[e-mail]>]

Hi Stu,

I think there are a number of people on the list who have a similar background with TCP acceleration, where the prominence of the SCPS-TP protocol varies.  (For me, SCPS-TP was mainly an interesting specification to look at and use as a quarry and source of ideas for our own, more optimized protocols.)  Traditional PEPs were as good as they were because:

(1) they had more intricate (and timely) knowledge of the critical path segment than the end-to-end protocol could have,
(2) techniques such as TCP splitting allowed mitigating some (but not all) of the latency induced performance issues end-to-end protocols exhibited over high-latency links.

With increasing use of encryption inside the transport layer, (2) is going away (and will probably only come back when encrypted transports such as QUIC start talking to halfway-houses in the network, without giving up the other benefits of encryption).  This reduces the benefit from the introduction of SCPS-TP segments into a sequence of split TCP segments.
(1) will stay relevant for those industries where that knowledge can be provided (satellite links, vehicular links, maybe more general wireless links).

What LOOPS is trying to do is providing a protocol that can help even in the absence of both (1) and (2).  One useful aspect here may be the aggregation of traffic, which is quite effective against tail loss events (and generally can provide a more reasonable basis for measurements), but also may make it less interesting to interact specifically with each end-to-end transport flow.  Fixing path segments outside “the critical” segment (e.g., a WiFi segment before going wide-area) can also help against mutual exacerbation of their problems.

So LOOPS is not trying to replace PEPs that benefit from (2) (and still do from (1), today).  It could still be run profitably over critical path segments where a forklift upgrade of PEP infrastructure is not feasible right away.  It is just one more tool in the toolkit that can be used to assemble a useful end-to-end path for some networking requirements, in particular where there already is a good reason to run a tunnel.  Probably later than sooner, it might also help with running such tunnels over multiple paths, but we are not proposing that the LOOPS activity should be actively looking into that just yet (even though some of us have been doing this in their day jobs for a decade or so now).

The fact that recovering packets can lead to reordering makes life harder for a LOOPS-like protocol.  As we saw in Singapore, we have quite different views on how much LOOPS could benefit from a general trend towards more reordering-robust end-to-end protocols.  LOOPS also could itself be made robust against reordering within its path segment — this needn’t involve (partial) resequencing at the LOOPS egress, where we again have different views on how useful that could be.

So yes, thanks for reminding us that SCPS-TP is good background material for optimizing path segments, but you are also right that we have to be aware of the limitations to its applicability in the LOOPS space.

I’m certainly interested in looking at more robust end-to-end protocols as well (including multipoint — reopening the discussion of NORM with a view to 2020’s networks and applications is very interesting!), and there already is a lot of attention to how QUIC could evolve to be more synergistic with efforts spent inside the network.  Ultimately, the applications will need to be part of the picture, evolving the transport abstractions (just as DTN did in a nicely radical way).  So LOOPS is just a start.  Much of what could be done beyond LOOPS is research - maybe it is also worth thinking about coordinating some of that, by posing the right questions.  E.g., for reliable multicast, we had the idea of using router assist, which from today’s perspective also would benefit from COINRG-like computing in the network.

Please do keep us informed about interesting developments in the greater design space here. 
As a proposed IETF WG, LOOPS itself will need to focus on a more narrow set of problems and opportunities, and this is the time to discuss whether we got that narrowing right in the current charter proposal [1].

Grüße, Carsten

[1]: https://github.com/loops-wg/charter/tree/post-105