Re: Take multipath to a BoF

[Olivier Bonaventure <[e-mail]>]

Martin,
> 
> (no hats here)
> 
>     If we had no sense of the use cases, then a  non-wg-forming BoF to
>     discuss them might be a useful step.  I've seen enough of them on
>     this and other threads to not believe that's needed, but I also
>     won't object if other folks want that.  But ultimately, *I think the
>     work has to remain part of the core transport work on QUIC*. 
>     Without that, I think you get MP-QUIC as a distinct transport from
>     QUIC, rather than enabling QUIC to both path switch and run over
>     concurrent paths.  That's a substantially worse outcome, at least in
>     my opinion. I don't work for Apple, but I will champion them for a
>     moment without speaking for them:  I am convinced by their use cases
>     alone that this work is worth doing in the IETF.
> 
> 
> Depending on what you mean, I'm not sure I agree with the bolded part. 
> There is almost certainly some amount of protocol (frame types, etc) 
> that have to be defined in QUIC, and I agree that this should happen in 
> the WG.

Totally agree


> But there are other more interesting problems (scheduling, congestion 
> control, etc) that are applicable to all the failover-capable transports 
> (MPTCP, SCTP, QUIC). I could be persuaded otherwise, but I think the 
> latter is best done not in QUIC, but instead either in TSVWG or a WG 
> purpose-build to do so.

The work on congestion control typically happens within ICCRG. MPTCP 
adopted the coupled congestion control RFC6356 which is a variant of 
NewReno adopted to the multipath scenario. Improvements have been 
proposed in the scientific literature and implemented but not documented 
in RFCs. Some work on ICCRG in making CUBIC multipath ready would make 
sense and would naturally apply to different transport protocols (MPTCP, 
QUIC, SCTP), possibly with minor changes.

For the schedulers and path managers, there are two different points to 
consider: the algorithms and the require protocol messages. It is 
possible to document generic algorithms that are applicable to different 
protocols. A first step in this direction is
https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-01
that was targeted at iccrg in March but could be moved elsewhere
A similar document could be written about path management.
However, in both cases, the protocol messages need to be defined in 
their respective working groups. Given that there are no middlebox 
interferences with MPQUIC, it will be possible to define more precise 
messages in MPQUIC than in MPTCP.


Olivier