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

[Lucas Pardue <[e-mail]>]

Thanks for the additional context on TAPS and SCTP.

The interesting thing for me in this context is the diversity of current
QUIC implementations in terms of programming language (and language
bindings), operating system support, and design paradigms. Which were
mentioned up thread by others.

Using Cloudflare quiche as an example, it is written in Rust and provides C
bindings. It is independent of UDP socket and operates a bit like Kazuho's
description of a push encoder; the application sets up a QUIC context
(connection), feeds in application-layer data, and is presented a QUIC
packet to be sent. This happens in the application's event loop of choice.

Quiche provides a transport API layer and an HTTP/3 API layer the
integrates on the top. Rust applications that use quiche can use Rust's
network layer and benefit from it's cross platform support; we have example
applications that work across Linux, Windows, MacOS, iOS, Android.
Applications that use the C bindings have more work to do, mainly due to
the difference between UDP socket programming.

There are a already a large collection of QUIC implementations in different
languages and using different paradigms. I think that diversity has
benefits. I struggle to see how defining a common QUIC layer API would
actually work out in practice but maybe I just lack vision.

To give an example, an HTTP application is unlikely to write its own HTTP/3
mapping on top of QUIC. They'll rely on a mapping layer and chances are
that it has a preferred integration with a QUIC layer. It would be
interesting to poll the maintainers of such libraries to see if they
perceive value in substitution, because chances are they are the ones that
would have to rewrite both sides of the API boundary to make this a reality.

Lucas