Hi ! Some very interesting points here, thanks! A few answers below:
> On 8 Jan 2026, at 12:22, Lucas Pardue <[email protected]> wrote: > > Hi, > > Speaking with only the hat of a QUIC implementation maintainer and addressing > some of the API topic. > > On Wed, Jan 7, 2026, at 13:48, Chris Box wrote: >> Reviving this thread for the new year. >> >> On Sat, 22 Nov 2025 at 17:24, Michael Welzl <[email protected] >> <mailto:[email protected]>> wrote: >> Hi, >> >> These minutes are great, thanks! Seems like it was an interesting >> conversation. >> >> Agreed. My takeaway is that evangelising the benefits of H3 over H2, >> supported by some new public data, would really help. Data on the problem >> areas, with advice on how to handle them is also needed. This can then spur >> development of libraries and encourage shipping with default-on >> configuration. >>>> Need better tools in programming languages to make it easier to use QUIC. >> FWIW, this is why the TAPS WG existed, see RFCs 9621, 9622, 9623. It would >> be great if we could get some momentum towards more implementations, >> specifically ones that use QUIC… surely there’s no easier way for people >> to access QUIC’s features without having to care about the specifics. >> >> I agree the modern Transport Services API should be encouraged. >> https://www.rfc-editor.org/rfc/rfc9623.html#name-existing-implementations >> lists Apple's Network.framework, NEAT and two Python implementations. >> >> I currently have two master students working on implementations that will >> use QUIC, but that’s as much as *I* can offer, from the world of academia. >> >> Thank you for that! >> >> PS: there’s also https://github.com/tfpauly/draft-taps-quic-mapping but it’s >> going stale… >> >> It strikes me as odd that 9621-9623 didn't include support for 9000. Is >> there a reason why the QUIC mapping wasn't seen as important? Sorry for reacting a bit late - so this (“wasn’t seen as important”) is a misconception that comes from the “look” of RFCs 9621-9623, but it’s absolutely not true for how these RFCs were made. QUIC was very much a part of the plan since its existence. … and this is the crux of the matter: some of the text in RFC 9623, about SCTP, even pre-dates the foundation of the QUIC WG! then QUIC came along, and when it was eventually finished, we were at a stage where we didn’t want to delay publication of our RFCs any further. So, we decided that protocol mappings (not “just" QUIC but also HTTP and WebRTC) could be done after these RFCs are published, and even after the WG is closed. See the list, here: https://github.com/ietf-tapswg/api-drafts/issues Tommy Pauly started a doc on QUIC mapping: https://github.com/tfpauly/draft-taps-quic-mapping last I talked to him, he said his lack of activity isn’t lack of interest: it’s lack of cycles…. so I guess what this would need is someone with 1) QUIC expertise and 2) cycles, and it could be finished relatively quickly. > From my experience, API development and maintenance are a huge cost center. > While an API definition might do some of the work, theres an iceberg beneath > that. Sure. > The quiche project I maintain provides a low-level Rust library for QUIC, > with a FFI to allow usage from C. Similarly there is a low-level HTTP/3 layer > that sits on top with Rust and FFI APIs. The expectation is that these are > integrated in an application that provides the I/O and event runtime. Its is > common that HTTP applications have their own programming/object model and API > (potentially 1st parh1ty or 3rd party common libraries). > > quiche is used to power several Internet-scale production systems at > Cloudflare. Its used by other folks at scale too, who can name themselves. It > can also be used as a backend for curl. The project is active and embraces > QUIC's innovation capabilities. We regularly tweak the API as we learn from > deployment experience, introduce new IETF work, or run other experiments or > trials. > > quiche is not the only Rust implementation. neqo, quinn, and s2n-quic are > some more-widely known ones, and there are others. > > One of the common anecdotes I've heard over past years is something like "I > really wanted to use quiche but my project is using async Rust which is not > directly supported. I didn't want to have to write ans maintain my own layer, > so I used quinn instead". I'm not going to begrudge people picking software > that lets them get on with life. The lack of a quiche async friendly API was > primarily down to the project maintainers not needing one. In recent years, > that's changed and in the last year we've open sourced "tokio-quiche" [1], > which sits further atop the low-level libs mentioned above. > > As much as it might pain people to hear, I struggle to see what benefit a > TAPS-like interface would provide. It sounds like a tonne of work that would > introduce friction to my ongoing project needs. I have no idea what it would > mean for the applications that build on top it. I doubt we'd use it ourselves > and it would likely become a second class citizen. I have sometimes argued that IETF participants are perhaps the worst examples of TAPS users. The idea of TAPS is to *simplify* access to the features provided by the protocols - which always comes with abstraction, entailing loss of control. The canonical example is unordered message transport. If you don’t care about the order between your messages, and TAPS happens to run over QUIC, it should be able to get them across faster, but - and that’s the crucial bit here - you won’t have to care whether it’s QUIC or TCP or whatever underneath, and you should end up just living with the performance loss in case you get TCP. ( an aside: you CAN be more in control of things, also in TAPS, but the more you insist on “protocol X, using method Y, …”, the less flexibility you get, which really defeats the whole purpose. ) I do think that this kind of simple functionality would be useful for many programmers out there, but I agree: it’s hard to imagine why anyone should *add* this to an existing implementation of a browser or web server or whatever, which already runs QUIC, implements connection racing, and cares about squeezing out the edge of performance of everything, not giving up the slightest bit of control. The whole point is to take care of all of these things below the API, and avoid burdening the broader set of application programmers out there with details such as, for instance, protocol racing. When we started TAPS, Spencer made a comparison with the move from assembly code to compiled languages, IIRC; it is perceived as unnecessary and badly performant by whoever already does everything with assembly, but it’s useful for all others nevertheless. The nature of abstraction… to stay with that metaphor, in the IETF, we’re facing folks with a battery of assembly code, saying “so what?? Why would I?”. Totally valid, just not the right target group. > More recently, I've seen people brand new to the world of QUIC use AI-coding > assistants to quickly build functional prototypes using quiche or > tokio-quiche. I suspect they could switch implementation easily too, if > required. If one of the arguments for TAPS is that it reduces the barrier for > new entrants to try the QUIC protocol, I think that argument is being rapidly > eroded. This will work nicely for simple cases, for sure. It will also work for more elaborate ones, but then it’s going to be much more of “working with AI”. The issue is that TAPS is not just about the API to use the protocol itself, it’s about having the right primitives that allow for simplicity and fall-backs, such that the code above can run over pretty much anything. Sure, creating all of that is also easier with AI-coding, but then that’s repeating the work that my master students are doing: implementing a whole TAPS system (i.e., also mapping functions to protocols, racing, …). They also use AI, like everyone else. > Finally, another statement that others might find controversial. IMHO if you > have a custom application that can just be flipped from TCP to use QUIC by a > couple of lines or flags, I suspect that the application is so simple that > there's going to be very few benefits to QUIC. The new dimensions of > operational considerations will likely kill any enthusiasm gained from a > simple flip-on switch. For more-complicated applications, then its likely > they've already invested in a stack of technologies and build the abstraction > they already need. Another good argument, but again I don’t think you’re completely right. There can be pretty simple cases of just sending messages without an ordering need, and already you get a benefit. Or, using priorities between a group of Connections (as we call them in TAPS). With TAPS, create a Connection to another host. Then, call “clone” on that Connection: if you’re lucky, it’s a stream, meaning that priorities play out, set-up has much less overhead, etc etc - but if it’s TCP, it’s going to be another TCP connection. You don’t need to care. That’s really a different model, and probably not what you want to have within your existing quiche stack. Cheers, Michael > > Cheers > Lucas > > [1] > https://blog.cloudflare.com/async-quic-and-http-3-made-easy-tokio-quiche-is-now-open-source/ > >> >> Chris >
