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

[Olivier Bonaventure <[e-mail]>]

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