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

[Lucas Pardue <[e-mail]>]

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

> Lucas,
>
> >
> > Personally, I think starting on a basis of ignoring QUIC transport's
> > core method of exchanging application data is a bad idea.
>
> I'm not suggesting that. I suggest that we first agree on the basic
> multipath mechanisms without taking too much time to discuss different
> and diverging application requirements. These mechanisms obviously need
> to take into account the core characteristics of QUIC. One example is
> that in contrast with MPTCP, MPQUIC acknowledgements do not necessarily
> need to be transmitted over the same "path" as the data that they
> acknowledge. This gives more freedom to an MPQUIC implementation than an
> MPTCP one. Another example are the flow control frames. Once we agree on
> these application-independent mechanisms, then we can start to discuss
> about policies and how to handle them.
>

Seems like tail wagging the dog? If an "integrated assembly of application
and MPQUIC" as a whole has no clue how to send stream data then deciding
the best way to send ACKs is an afterthought.

To put it a different way, the problem is about packetization over time
windows, before worrying about path selection. I get worried when I read
draft-deconinck-quic-multipath and it says

> TODO: Add a companion document discussing the packet scheduling and path
management considerations.

I appreciate that could be a placeholder, so I'm trying to find out if the
knowledge and experience of MPTCP does actually help in anyway bootstrap
understanding of independent streams in a transport.