Skip to main content


I just learned there is a #QUIC in the #Linux kernel effort: github.com/lxin/quic

... as a draft PR making curl use it was filed: github.com/curl/curl/pull/1431…

Seirdy reshared this.

in reply to daniel:// stenberg://

Pippin: But what about QUIC?
Daniel: You've already had it.
Pippin: We've had four, yes. But what about fifth QUIC?
in reply to daniel:// stenberg://

We‘ll need it for True Multipath QUIC, where one uses multiple implementations as well.😌
in reply to daniel:// stenberg://

That sounds mildly sarcastic.

I'm not convinced shoving yet another nontrivial protocol into ambient-authority land is advisable.

in reply to LisPi

@lispi314 I agree that's worthwhile discussion. There are certainly both pros and cons with both ways: userspace and kernelspace.

I don't think a full QUIC implementation will be accepted into the kernel anytime soon though because of its complexity.

in reply to daniel:// stenberg://

it's not my area, but wasn't part of the original justification for QUIC that it was implemented in userspace and so easier to change and update?
in reply to daniel:// stenberg://

I mean... I kind of like it. IPPROTO_QUIC added to ye olde socket API looks neat/simple to me, and (as a transport layer) I think it belongs in the kernel anyway.

I assume you prefer QUIC in userspace? For portability reasons?

in reply to EricJ

@ericj kernel-side certainly makes a few things simpler, but I don't expect this to land in a mainline kernel any time soon and it will be Linux only so in effect it it does not simplify anything for us...
in reply to daniel:// stenberg://

My thought: oh, it's finally happening.

I've been expecting this for a while...