Just to chime in here ... On Thu, Oct 8, 2020, 02:58 Olivier Bonaventure < [email protected]> wrote:
> 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. > What the QUIC charter says now about this, for single-path QUIC, is "The first of these is the core transport work, which will describe the wire format, along with the mechanisms for connection establishment, stream multiplexing, data reliability, loss detection and recovery, congestion control, and options negotiation. Work on congestion control will describe use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this group. QUIC is expected to support rapid, distributed development and testing of features." That's actually stronger than the initial approved charter, which said the working group would describe the use of an *existing* congestion controller. If Experimental is on the table, I note that https://datatracker.ietf.org/doc/rfc6356/ has been Experimental since 2011, which shouldn't be a problem. So I think this argues for doing an Experimental QUIC multipath document. Best, Spencer 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 >
