Re: QUIC API (was: Re: Small size of core QUIC library to replace TCP for embedded system)

[Robin MARX <[e-mail]>]

Personally, I would agree that creating a general purpose API just for QUIC
would be difficult.
I'm mainly thinking about what the interface for steering stream
multiplexing/prioritization would look like, seeing as the specs are very
light on details for these.
Speccing something out for HTTP/3 should be do-able (and is being
contemplated by some, e.g., https://github.com/hyperium/h3/pull/1), though
potentially not as useful.

I would echo Lucas' reference in thinking that abstracting from QUIC to a
more high-level view of transport features with something like TAPS is more
logical in the long run.
Rather than putting all eggs in one basket, it would be good to get at
least this one egg into that particular basket imo.

Like Lucas and David, I'm also not sure how common/realistic of a use case
the "I want to switch ad-hoc between QUIC implementations" argument will
be.
To me, a common API would be mostly interesting in writing re-usable
high-level coding tutorials and teaching materials to help new devs use the
protocol more quickly.
>From that perspective, you can make an even stronger argument for TAPS imo.

With best regards,
Robin



On Fri, 7 Aug 2020 at 08:39, Christian Huitema <[e-mail]> wrote:

>
> On 8/6/2020 5:58 PM, David Schinazi wrote:
> > In theory, it could mean that one could write an application
> > in such a way that it could swap QUIC implementations.
> > I don't see that happening in practice. The application
> > developer would have to periodically test against these
> > implementations for them to work reliably, so the idea
> > of a drop-in replacement sounds unreal to me.
>
> Yes. We had an example of that when testers wanted to plug their tools
> to different QUIC stacks. Not impossible, but there was a lot of glue
> required.
>
> >
> > Additionally, in 2020, networking APIs are asynchronous.
> > That means that a QUIC API would need to be tied to
> > a specific asynchronous IO model, and those are tied
> > to programming language and library choices. So any
> > API would only work for applications that pick the same
> > language and standard libraries.
>
>
> People today are experimenting with a variety of application--stack
> interactions. I think that's a good thing at this point. Take the
> example of out-of-order delivery: really cool potential, but we have
> very little experience. It might require tight integration with the
> application, dealing with the intricacies of video codecs. I think that
> in the next year or two we will gain some experience and maybe see a
> small number of API models emerge. But attempting standardization before
> that seems very premature.
>
> -- Christian Huitema
>
>
>

-- 

Robin Marx
PhD researcher - web performance
Expertise centre for Digital Media

T [phone] - GSM [phone]

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05