[saag] Re: The state of QUIC (Re: Re: [radext] Cyber Official Speaks Out, Reveals Mobile Network Attacks in U.S.)

[Watson Ladd <[e-mail]>]

On Fri, May 17, 2024 at 1:41 PM John Mattsson
<[e-mail]> wrote:
>
> Watson Ladd:
>
> >Their implementation efforts will take years to bear fruit
>
>
>
> I remember the controversy you talk about, but reading the OpenSSL blog it seems like OpenSSL 3.4 which will release no later than 31 October 2024 will more or less complete the implementation of QUIC in OpenSSL. Do you think that implementation will have significant problems?

I think a new, relatively untested implementation of a very complex
protocol (and an incomplete one at that: no H/3) will have issues. I'm
not sure I've been impressed OpenSSL's quality code and thoughtful API
design, but that's besides the main point:

Even if the implementation had no issues, QUIC (on Unix systems)
changes the relation between the kernel visible objects (sockets), and
requests and connections. While you could write an HTTP/1.1 server
that has one process do accept, then fork a worker that drives TLS and
blocks to handle requests, QUIC makes that (very limited)
implementation strategy no longer viable. Instead the server has to
concurrently accept new requests, manage internal connection state,
and answer requests that exist while getting packets on one UDP
socket. Writing concurrent programs in C is hard. Adapting existing
ones to be concurrent is even harder.

Sincerely,
Watson Ladd