Hi Ted, (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. 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.
