"Proxying" multipath usecases and application scheduling

[Matt Joras <[e-mail]>]

Following up from Martin Thomson's excellent summary of the BoF-esque
multipath QUIC interim, I thought I'd start a discussion extracting a
couple things I saw as important takeaways from the presentation and
subsequent questions.

As David noted, there were essentially two categories of usecases
presented. The first, embodied by the Apple and Alibaba presentations, were
essentially existing applications that can benefit from a transport with
the capability to simultaneously utilize multiple paths. For these it
seemed everyone agreed that in order for multiple paths to be useful the
application has to have input into the scheduling decisions on these paths.
For example, the application knows how it wants to trade off latency of
delivery and overall throughput of delivery for application data.

The second set of usecases utilized multipath "in the network". ATSSS and
the two variants of Hybrid Access Networks presented fall into this
category. In this scheme application data is transparently proxied over
multiple paths. This would include things like TCP flows, which could be
intercepted in the traditional way TCP PEPs operate, as well as UDP
(including QUIC) datagrams. Both types of traffic would be scheduled along
the multiple paths towards the "other end" of the proxy, where it
presumably re-enters the general Internet towards the destination endpoint.

Prior to the meeting this latter set of usecases always felt concerning to
me, and the meeting did an excellent job of crystallizing my concerns. As
others have said, a great benefit of QUIC has been its ability to "cut
through" the meddling of things like TCP PEPs, which are often making
transport-level decisions that harm the goals of the endpoint application.
While the in-network multipath schemes cannot meddle with QUIC flows as
much as TCP PEPs, I am still very concerned about the consequences of
utilizing them.

We seem to have established that application input is necessary to achieve
the benefits from utilizing multiple paths, as there is not one "best" way
to schedule data. These proxyng solutions have no way to act on application
concerns, and rather have to devise scheduling policies solely from
network-level information, ignorant of signals from the application. Does
this not inevitably lead to pathological scheduling decisions and
applications which are helpless to do anything about it?

The obvious counterpoint is that these proxies, through advent of being
embedded "in the network", have access to information which the endpoint
does not, e.g. about the state of the paths. An argument can be made that
because of this they can make proactive decisions, rather than relying on
the endpoint to react to changes. This is of course true, but completely
ignores the fact that without the application context, it is impossible for
the proxy to make an optimal scheduling decision.

If the only benefit to running such proxies "in the network" is their
extended knowledge of network conditions, wouldn't a better path forward to
have endpoints engaging in "native" multipath? To solve the information
gap, i.e. the fact that the "network knows more", could we not develop
mechanisms for signalling this information proactively to endpoints?

Now these concerns may not sound QUIC-specific, but I think it is still
relevant to the working group for the following reason. Usecases are very
important towards driving design of something like a multipath protocol. It
seems to me that one of the two major categories of usecases for a
multipath QUIC is, by design, incompatible with some of the core tenets of
QUIC as an application-enhancing transport protocol. As Martin said, we
obviously can't stop anyone from utilizing multipath in this way, and it of
course does not serve as a reason to not design a multipath QUIC, but it
seems to me something we should all keep in mind as we consider such
designs. I am very curious to hear others' opinions in this direction and
thanks for sitting through this wall of text.

Matt Joras