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
