Hi, Christian, On Fri, Oct 23, 2020 at 5:19 PM Christian Huitema <[email protected]> wrote:
> > On 10/23/2020 3:10 PM, Spencer Dawkins at IETF wrote: > > I'm probably starting to sound like a broken record, but we chartered > > TAPS in 2014 to think about hiding bizarre transport attributes from > > applications (among other things) using an abstract application > > programming interface, and I note > > that https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ is > > now targeting Propose Standard, > > and > https://tools.ietf.org/html/draft-ietf-taps-interface-09#section-5.2.13 > > is about multipath. > > > I think you are hearing practical reasons to not do what TAPS is > proposing, and instead to use the close coupling between the application > and the QUIC implementation to make better transport decisions. In > practice, application code is developed for a specific implementation of > QUIC, and that implementation gets ported to all platforms that provide > UDP sockets or equivalent. > I'm sorry, I wasn't clear in my e-mail. I think where we are, is that there are two flavors of applications - the kind that would do better than a general purpose transport with multiple paths, and the kind that doesn't need to handle the paths in detail. I was thinking of the second category. I could usefully have included that caveat in my note. > > Has anyone been looking at this? TAPS has been chugging away since > > before QUIC was chartered, and certainly didn't want to do anything to > > slow QUICv1 work down, but now that QUICv1 is past Publication > > Requested, should we be? > > > It's a free world. Of course you can do that. Whether that's useful is > for you to decide. > Sure. I was mostly looking at the author list for https://datatracker.ietf.org/doc/draft-ietf-taps-interface/, and wondering if anyone was already doing that. Best, Spencer > -- Christian Huitema > >
