Ian,
I'm very receptive to Jana's arguments, but I think it's also worth
understanding how much work we believe this will be for the QUIC WG.
Many fairly complex multipath problems have already been dealt with by
supporting connection migration in QUIC v1, such as path validation and
linkability between flows. Multiple packet number spaces during the
handshake means that implementations already have some ability to have
multiple loss recovery contexts, though they may not be easily adaptable
to multipath.
Scheduling seems like a big problem, but it's not clear to me that the
QUIC working group should be attempting to solve that. I'd argue we
should make that explicitly out of scope if we took on this work.
I agree, this is what MPTCP did as well.
The existing draft(draft-deconinck-quic-multipath-05
<https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) adds
ADD_ADDRESS/REMOVE_ADDRESS frames and modifies the ACK,
NEW_CONNECTION_ID, and RETIRE_CONNECTION_ID frames. It also adds what
appears to be a debugging frame(UNIFLOWS) and a single transport
parameter to indicate support and indicate the max number of uniflows.
Having sets of CIDs per path seems an unfortunate complication to me,
but I haven't thought about it enough. The two new frames and
modifications to the ACK frame are simple enough.
Is there MORE work QUIC WG would have to do than what's described in the
draft? If so, can people outline that work?
I certainly think MP-QUIC is a cleaner solution than MP-TCP.
I lean towards keeping multipath in scope, and I'd be willing to spend
time improving a proposal if it was adopted. One reason is that I never
want to be forced to support MP-TCP because there is no MP-QUIC. I also
don't think this has to be designed with HTTP in mind, even if that was
the focus of QUIC v1. MASQUE/VPNs are a more compelling use case to me.
I agree, the multipath VPN use case is probably more useful in the short
term than HTTP/3 over MPQUIC
Olivier
