Re: Preparing for discussion on what to do about the multipath extension milestone

[Matt Joras <[e-mail]>]

Olivier, some questions/replies inline to your response to Lucas. In
general I have similar concerns about coordination, and I am wondering
whether MPQUIC is trying to solve too many problems at once.

On Sun, Oct 4, 2020 at 2:17 PM Olivier Bonaventure <
[e-mail]> wrote:

> Lucas,
>
> > +1 to the suggestion to discuss use cases, it is helpful for clarity.
> > And thanks Christoph for sharing some specific ones.
> >
> > For the use cases "Siri" and "Apple Music", since I'm not experienced
> > with multipath there's a gap in my understanding of how the proposal in
> > draft-deconinck-quic-multipath would be used to satisfy these use cases.
> > For instance, is the behaviour client-driven, server-driven or does it
> > require coordination? Would anyone be so kind as to share _an example_
> > of how uniflows would be used within a QUIC connection that uses a
> > request/response paradigm for data exchange.
>
>
> Let me try with a simple example on a moving smartphone. The application
> will send small amounts of data and receive variable amounts of data
> (depending on the type of requests).
>
I want to start by saying this is a real usecase, and a problem we see very
obviously through quality of experience outliers for people using our
products.

>
> We create a sending and a receiving uniflow on both the Wi-Fi and the
> cellular interface. The smartphone has two sending uniflows and the
> server as well.
>
> To send a short request, the client duplicates it over its two sending
> uniflows since it does not know which of the two uniflows will be the best.
>
> To return the response, the server could use the same scheduler if the
> response is short. However, if the response is long, this is not very
> efficient since data is sent over two paths. It could then use both
> paths to send the data and get the lowest delay to deliver the response.
> This could be modulated by policies if the user pays on a per volume
> basis over one path and not over the other.
>
This somewhat hand-waves away the scheduling problem. Most Internet traffic
flows in the direction of server -> client, where typical mobile clients
are obviously the ones with potentially multiple interfaces to the
Internet. The client also has the most information about the likely quality
of the first radio hop into the access network (e.g. signal quality). The
client also _may_ know about things like data pricing. However, the server
is the one which is responsible for scheduling most data across these
paths. To make good, proactive (rather than reactive) scheduling decisions
the server needs to be fed this information as input to its scheduler. This
seems a difficult thing to achieve in practice, and without it I wonder
whether the complexity of "full" multipath will be worth it until we solve
the signalling problem. What Ian is suggesting above, I think, is
essentially an Active/Passive extension to the existing connection
migration mechanisms we have today. What are your thoughts on this as an
initial direction? It would allow operators a way to solve this particular
problem with only mild modifications to the core protocol. Said another
way, I think in theory an omniscient packet scheduler can make very
intelligent decisions which would definitely benefit application quality.
In practice though I have concerns about how effective these schedulers
will be versus the naive approach which could be thought of as
"Active/Passive" or "Failover", eschewing bandwidth aggregation entirely.
I'd also like to echo what Kazuho said, which is that "Multipath" can mean
many things, and I'd prefer we narrow down the problem we want to solve in
the WG, which will drive our design direction.

>
> Another example is the hybrid access network scenario with a DSL and an
> LTE path. There, the objective is to send data over the LTE path only
> when the DSL is full.
>
> In this case, the solution would differ. The client would first create
> sending and receiving uniflows over the DSL path. It then monitors the
> usage of this path. As long as the DSL is not fully used for some period
> of time (e.g. one or a few seconds), all data flows over the DSL path.
> Once the DSL path is saturated, the client creates a receiving uniflow
> (and possibly a sending one if the DSL upstream is saturated) over the
> LTE path. The second path can be used to offload traffic. In practice,
> the client and the server use a priority scheduler to always prefer the
> DSL over the LTE path, see
>
>
> https://inl.info.ucl.ac.be/publications/increasing-broadband-reach-hybrid-access-networks.html

For these usecases, are you imagining that they would largely be used
internally for Internet operators? I always struggle with the hybrid access
examples, as they seem to assume a lot of knowledge about the underlying
networks that typical endpoints can't simply intuit from the ether. The
linked paper seems to suggest MPTCP as a proxy solution, which I gather is
largely the usecase things like ATSSS have for MPQUIC. However, as a mobile
application how do I know the DSL link is "full" and thus that I should
create a uniflow over the LTE path? The same question applies to the
server. It would be awesome if clients and servers had more active
information about the underlying network's state rather than being
reactive, but beyond things like ECN this seems difficult to achieve in
practice. If the Hybrid Access Network usecase of multipath presupposes a
deployment in an operator's network then I would argue it is somewhat
antithetical to the goals of QUIC, which deliberately puts more control at
the endpoints.

>
>
> Another usecase is a device that has a high-speed satellite downlink
> (but very slow upling) and a low-speed cellular connection. In this
> case, it can use two receiving uniflows (one cellular and one satellite)
> and one sending one (over the cellular). Requests are sent over the
> cellular path and responses are received over the satellite uniflow and
> acks are sent over the cellular uniflow.
>
>
> There is a generic discussion on schedulers in
>
> https://datatracker.ietf.org/doc/html/draft-bonaventure-iccrg-schedulers-01
>
>
>
> Olivier
>
> >  > Another question, and perhaps this is getting increasingly off-topic,
> > but now that we are getting into designing "significant" extensions, I
> > think it is worth asking whether this should be an extension at all.
> > I.e. should MPQUIC be a core feature of QUICv2?
> >
> > I tried to spin that out into another thread [1]. IIRC someone
> > previously suggested that MP-QUIC could start as an experimental version
> > of it's own. I can't find a citation for that though sorry.
> >
> >
> > [1]
> https://mailarchive.ietf.org/arch/msg/quic/p2II8y3y1FXy4kWMSuf1lgAXaFA/

Matt Joras