On Wed, Sep 30, 2020 at 3:52 PM Olivier Bonaventure < [email protected]> 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.
