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. > 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. -- Christian Huitema
