Howdy, On Wed, Oct 7, 2020 at 2:33 PM Martin Duke <[email protected]> wrote:
> 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. > > That's the key thing I think we need, so I'm glad we agree at least up to here. > 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. > I continue to disagree here, largely because what you can do about scheduling, congestion control, etc. varies among the different transports. There are certainly common research topics, and if we were describing an RG, I'd agree that a dedicated group with a scope that included all of them would be a good result. But for a working group, the engineering constraints and opportunities are sufficiently different that I don't think any of them are well served by being lumped together. You might get a common solution, but there's a real possibility that it would be the least common denominator. Just my opinion, of course. Ted
