Dupe from 2 months ago (185pts, 37 comments[0]) and 4 months ago (.. not great 9pts, 4 comments[1]).. both posted with URL https://quic.xargs.org/ .. it looks like HN (now?) ignores the host (lists as xargs.org) so doesn't notice the dupes. Manchoz already benefited from duplicate posting Illustrated TLS 1.3 (4yo/568pts, 2yo/273pts article)

[0]: https://news.ycombinator.com/item?id=31817144

[1]: https://news.ycombinator.com/item?id=31121674

Oops. Okay, it's marked now. I just found it and assumed it would be marked directly if it was a dupe. Will check before posting next time.

Not your fault; I had to migrate domains a month or two ago so automated dupe checking wouldn't spot it.

I think site policy is that it's ok to repost something after a year, so the TLS 1.3 post is probably ok.

I also recently migrated domains from ulfheim.net to xargs.org, so you can crosscheck against https://news.ycombinator.com/from?site=ulfheim.net for some older posts. We'll temporarily have some "too soon" reposts in the coming year due to that.

So I was curious about why there was so much padding in the first packet.

According to https://blog.apnic.net/2019/03/04/a-quick-look-at-quic/ it's to test if the PMTU is acceptable to QUIC. (But according to that source, it should be 1,350 B, not 1,200 B.)

…and that if the PMTU is less than that, that the connection gets aborted! (And this could happen mid-connection, if that initial packet succeeds but a later large packet fails.) And that anything using QUIC needs a TCP fallback? That seems … extremely surprising. I was rather hoping QUIC could suffice for a more feature-complete TCP…

Edit: oh, I somehow missed the orange Annotations button; I guess I didn't expect it on padding. The annotation has essentially the same explanation, but doesn't get at the apparent discrepancy. Although…

> To prevent a scenario where a connection is established successfully with smaller packets but then starts timing out once larger packets are sent, the initial packets are padded to a length of 1200 bytes to prove that the end-to-end path will allow packets of that size.

No? It proves that the path that packet took does. It's a good indicator that subsequent packets of similar size are likely to succeed. "to prove" is a bit of a stretch though. (And the APNIC blog is more conservative, for this reason.)

The authoritative source is the RFC, which says 1200 bytes: https://datatracker.ietf.org/doc/html/rfc9000#section-8.1

> anything using QUIC needs a TCP fallback

This is just the reality of introducing a new UDP-based protocol in a world that's played pretty fast and loose with UDP delivery. If QUIC eats the world this thinking will likely change.

> It's a good indicator that subsequent packets of similar size are likely to succeed.

That's fair. Think I should update the wording?

> This is just the reality of introducing a new UDP-based protocol in a world that's played pretty fast and loose with UDP delivery. If QUIC eats the world this thinking will likely change.

Well, no, not really? A standards-conforming link can drop QUIC's initial packet; that's not "fast-and-loose", that's QUIC requiring a PMTU that might not exist. There's a minimum guaranteed PMTU, and it's <1,200 B. Now, it is higher in IPv6… which will roll out any day now eye twitches.

(Sure, most links might have MTU's that are that high, but I think there's a different bar for standards. Either raise the required MTU for IPv4, or permit fragmenting, or handle lower PMTUs like TCP, or … etc. I.e., solve the problem.)

But the idea with QUIC (as I had had hopes for) would be to use it for applications where TCP's stream abstraction is the wrong interface for the job.

> Think I should update the wording?

Personally, yes.

> A standards-conforming link can drop QUIC's initial packet; that's not "fast-and-loose", that's QUIC requiring a PMTU that might not exist.

I meant in the context of QUIC needing a TCP fallback for this, rather than anything PMTU-related.

The reality is that UDP is so under used (especially in a low latency context that QUIC wants) that QUIC implementors are finding all sorts of wrinkles with it, both in endpoint IP stacks and network equipment. Anyone using QUIC that doesn't control the network will need to have a TCP fallback ready until QUIC is a little more mature.

We'd all love to have QUIC available as a full TCP replacement but the reality is it's going to be non-functional in some networks and for some endpoints.

> Personally, yes.

Will do. I'll add it to my todo list, will make sure I understand everything you've said here and should probably get a tweak out in a day or two.