The Illustrated QUIC Connection

https://quic.xargs.org/

by solarkraft • 4 years ago

32 8 4 years ago

quic.xargs.org

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.)

syncsynchalt4• 4 years ago

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?

deathanatos2• 4 years ago

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.

gnabgib• 4 years ago

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

solarkraft• 4 years ago

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.

syncsynchalt4• 4 years ago

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

syncsynchalt4• 4 years ago

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.

The Illustrated QUIC Connection

Related Stories