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

[Lucas Pardue <[e-mail]>]

On Wed, Sep 30, 2020 at 3:17 PM Olivier Bonaventure <
[e-mail]> wrote:

> Lucas,
>
> > It's this special sauce that concerns me. > I don't know how I'd
> objectively measure that the MP-QUIC design and all
> > the implementation effort would actual result in improvement. For
> > instance, more bandwidth via aggregation can still be misused; some
> > types of streams will be more latency sensitive than others. Putting the
> > decision making into the transport library could also be seen as black
> box.
>
> I would suggest that we start by considering MPQUIC as a blackbox as we
> did with MPTCP. This worked well and getting the multipath mechanisms
> will be easy.
>
> > I also want to draw some parallels between uniflows and the HTTP/2
> > priority tree. The tree was a fully expressive model that allowed a
> > client to hint to the server about the relationship between streams. The
> > problem of actioning this signal was left up to the server. Deployment
> > experience reveals that getting this well-tuned, just for a single TCP
> > connection, is hard. Some implementers just never got around to fixing
> > some serious and easily detectable performance problems.
> >
> > Presenting a bunch of uniflows to a sever and leaving it responsible for
> > using them properly seems to me quite a similar problem.
>
> That's a policy decision and policy can be very complex. In MPTCP, we
> have very limited support for policies:
> - clients use a path manager to decide when they create subflows
> - servers basically never create subflows (due to NATs and firewalls)
> - clients and servers can use the backup bit to indicate that a subflow
> should only be used if all the non-backup subflows failed or have problems
>
> We discussed multiple times how to exchange policies over MPTCP. It
> turned out that this was very difficult given the middleboxes. In the
> end, MPTCP does not support the exchange of policies and the current
> deployments embed the policies on the hosts that use MPTCP with a
> specific path manager. This works well enough.
>
> For MPQUIC, the situation could be different as there will be no direct
> inteference from middleboxes that modify options. We could exchange
> information such as the priority of a flow, mapping streams to flows,
> rtt preference, capping flows, ... My fear is that if we open this, the
> discussion could never stop and result in something similar that is too
> complex to implement. I would suggest to focus initially on very simple
> policies that are implemented locally (i.e. the application that uses
> QUIC would control when and how to advertise addresses and when and how
> to create flows, QUIC implementations could include different packet
> schedulers) and discuss the possibility of exchanging this policy
> information for a revision of MPQUIC.
>
>
Defining the capability, presenting little evidence to support its
applicability and punting on the problems is exactly what got HTTP/2
priorities into the pickle that it's in.

Personally, I think starting on a basis of ignoring QUIC transport's core
method of exchanging application data is a bad idea.

Cheers,
Lucas