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

[Michael Welzl <[e-mail]>]

> On Aug 7, 2020, at 10:17 AM, Robin MARX <[e-mail]> wrote:
> 
> 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 <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. 

+1

Lucas mentioned RFC 6458. I regularly used this particular RFC as an example to motivate TAPS prior to its “birth”, as the whole point was to make the job easier for application programmers (while enabling protocol evolution below the API).

We did this by identifying what really must be exposed (vs. what can be automated below an API), as opposed to offering absolutely everything a protocol can do (which is what RFC 6458 does). This led to an analysis of the API-relevant bits of TCP, MPTCP, UDP(-Lite), LEDBAT and SCTP (yes, RFC 6458), in RFCs 8303 and 8304, followed by a systematic approach to throw out things that may be automatable (draft-ietf-taps-minset-11, in the RFC Editor queue). This “minimum set” now forms the core of the current TAPS drafts (the API being in draft-ietf-taps-interface). You may notice that QUIC is missing in the list above, because it was still very much in flux at the time these RFCs were done. However, we’re doing our best to support QUIC in a similar way with TAPS.

Some programmers will want fine grain control of everything - the kind of control that RFC 6458 offers. Indeed, for this, I’d also ask whether defining it all in an RFC is worth the effort. Either way, it’s a different egg.

Cheers,
Michael



> 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] <mailto:[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 <http://www.uhasselt.be/>
> Universiteit Hasselt - Campus Diepenbeek
> Agoralaan Gebouw D - B-3590 Diepenbeek
> Kantoor EDM-2.05
>  
>