Re: "Proxying" multipath usecases and application scheduling

[David Schinazi <[e-mail]>]

On Fri, Oct 23, 2020 at 5:54 PM Mirja Kuehlewind <mirja.kuehlewind=
[e-mail]> wrote:

> Hi Matt,
>
>
>
> I think this discussion rather would belong on the MASQUE list and I guess
> we already had some of this before chartering MASQUE but let me reply to a
> couple of comments below.
>

As per the MASQUE charter, multipath is out of scope for MASQUE. I'd
personally suggest we keep all multipath QUIC conversations on the QUIC
list for now.


> *From: *QUIC <[e-mail]> on behalf of Matt Joras <
> [e-mail]>
> *Date: *Friday, 23. October 2020 at 22:10
> *To: *IETF QUIC WG <[e-mail]>
> *Subject: *"Proxying" multipath usecases and application scheduling
>
>
>
> 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.
>
>
>
> Application input is needed if and only if there is actually a tradeoff to
> make. However, there are many scenarios where one can actually chose
> between a link that is better than the other, regarding both delay and
> latency, and then the decision is easy and the same for all applications.
>

Could you elaborate? Choosing between links applies to connection
migration, multipath is a much more complex beast.


> 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.
>
>
>
> Intercepting TCP and tunneling is far not the same thing. There are many
> functions today that tunnel your traffic in some way in some network.
> Traffic is rerouted or EMCP is used to choose a path. These functions are
> needed for network management and network resilience and it’s explicitly
> the role of the end-to-end transport to adapt to changing network
> conditions and  handle these situations.
>
>
>
>
>
> 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.
>
>
>
> Again for me this is by far not the same and threating everything that is
> done with your flows in the network the same seems just oversimplifying it.
>
>
>
> 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.
>
>
>
> There are cases where there is actually a best way, whenever one path is
> better than the other without having to make tradeoff, and as I said in my
> other mail its usually not only application input that is needed to make a
> decision. E.g. Christoph brought this example that mobile data should be
> avoided and of course it also depends on the network condition, and that’s
> where congestion control comes into play.
>
>
>
>
>
> 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.
>
>
>
> Again there are scenarios where there is clearly a better path, or where
> there is a strong desire for the network to avoid usage of a certain. E.g.
> in the hybrid access case, some operators lease one of the links from
> another operator. I think it’s understandable that they only offer dual
> connectivity if they have a way to minimize usage of the more expensive
> line. There are many scenario where network management decision need to be
> made independent of application characteristics.
>
>
>
> And regarding ATSSS is already exists (based on MPTCP for TCP and ATSSS-LL
> for other traffic) and will be used, similar as other techniques that
> impact routing. I think it’s understandable that operator try to utilize
> all available resources and usually that actually means that more capacity
> and a better is available for the user/the operator’s costumer. We can
> argue about the best technical way to make use of these resources but a)
> the final decision about ATSSS will be made in 3GPP and not the IETF and b)
> having an explicit proxy setup where the client can decide to use as it or
> not, as it is done also in other masque use case, seems to me actually a
> good approach (or at minimum better than what we have right now).
>

When you say "ATSSS will be used", do you have references? I'm not aware of
any smartphone provider planning to support ATSSS but I might have missed
it.


> 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?
>
>
>
> I guess you can make the same proposal in the other direction: why cannot
> the endpoints tell the network what the application needs? I think this is
> a discussion to have in the APN BoF, however, we had this discussion many
> times and the short answer is trust. Might probably is a longer answer as
> well and there is a lot of disagreement.
>

End-user privacy?

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.
>
>
>
> I think that is a way to broad statement and far too simplified. There
> have been so many discussions in the IETF including in the QUIC working and
> we clearly don’t have agreement about what the right level of cooperation
> is because there is just not a simple solution. I fully understand the pain
> we had with TCP. I’ve been working so long on ECN and am still sad how this
> good idea git killed in its infancy because of a buggy home router
> implementation that badly interfered. However, I personally also still
> believe that there is a way to further optimize and better utilize the
> resource we have if there is some cooperation between the network and
> endpoints. Anyway that’s my view on a different topic and not the point of
> this discussion.
>
>
>
> 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 think we should not consider this to make a decision on multipath
> support in QUIC because as you said you can’t stop it. The only thing you
> can achieve for ATSSS is that 3GPP may design some proprietary way to
> realize this function which will further increase complexity in an already
> complex system. However, that also an different discussion to have.
>
>
>
> I’m been trying here to mainly explain what 3GPP is doing on ATSSS in
> order to get this group some understand of what the requirements are.
> However, I mainly just think we should simply have multipath support in
> QUIC because a modern protocol should be able to utilize the fact that more
> and more devices have connectivity to multiple network paths. I think using
> path migration for handovers is a bit a hack and not the real solution
> because it’s actually not easy for an endpoint without further network
> knowledge to detect when it is the right time to switch. Having a more
> complete multipath feature were you have two congestion controllers and can
> get measurements from both paths does help that problem and we do have good
> experience with that for MPTCP.
>

I'll point out that "we should simply have multipath support in QUIC" is
very optimistic, I really do not expect this to be simple.

David


> Mirja
>
>
>
>
>
> I am very curious to hear others' opinions in this direction and thanks
> for sitting through this wall of text.
>
>
>
> Matt Joras
>