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