
QUIC as a solution to protocol ossification - signa11
https://lwn.net/Articles/745590/
======
Luker88
Honestly, I am kind of disappointed at QUIC.

It could have been much more...

* there is no support for non-reliable streams

* I am not keen on the variability and non-alignment of the whole header (which can go from 0 to 60+ bytes).

* it points too much towards just reducing the RTT for the initial connection (0RTT is a bad idea, especially if your application now needs to handle the special case of the connection being 0RTT or not).

* There is no support for datagrams, just datastreams.

* Perfect forward secrecy is not granted on the initial handshake (you need to explicitly do a second key exchange for that)

* Forward error correction is actually cool but just using XOR is too limited.

* The proof of ownership of the connection is one incredible hack

And these are just the things I remember from looking at it a couple of years
ago. Still, it's a nice improvement over older protocols.

To those that are going to comment something like "Well, then do your own":
that's exactly what I'm doing although it's going slowly as I don't have
Google's budget.

~~~
JulienSchmidt
Regarding non-reliable streams: There is [https://tools.ietf.org/html/draft-
tiesel-quic-unreliable-str...](https://tools.ietf.org/html/draft-tiesel-quic-
unreliable-streams-01), while it won't be part of the initial standard, it's
likely that the working group makes sure that it can be added later.

~~~
Luker88
did not see that, thanks for the link

------
gwbas1c
One of the things that I don't like about TCP is that it really goes out of
its way to emulate a stream of data over a wire. This then leads to things
like Nagle's algorithm that deliberately slow it down.

This is problematic when doing things like HTTP, or any of the infinite RPC
schemes that come into popularity every few years. (REST, Thrift, Protocol
Buffers, ect.) As a programmer, we're trying to send a request of known length
and get a response where the server knows the length. As TCP makes this looks
like a wire stream, it means that the protocol implementer needs to disable
Nagle and implement logic that figures out where the requests begin and end;
even though most likely these boundaries are the packet boundaries.

Think of it this way: An HTTP GET request may fit into one or two IP packets;
but the nature of TCP streams means that the server's HTTP API needs to find
the \n\n to know when the request headers end. Instead, the stream API itself
should just be able to say, "here's a packet of 300 bytes!" Furthermore, if
the client didn't disable Nagle, its TCP library will deliberately delay
sending the header for 200 ms.

The reality of the TCP API is that it's great for long streams of data. It
just isn't optimized for half of its use case.

~~~
nvarsj
It's a common misconception that Nagle's causes the delay problem. The problem
is tcp delayed acks. Nagle's can improve network efficiency (and latency as a
result) on slow links. On fast links it shouldn't have much impact at all.

The rest of what you said doesn't make much sense to me. Searching for \n\n is
a property of HTTP, it's nothing to do with TCP. TCP is meant as a generic
connection oriented protocol that uses packet switching, and it's largely
optimized for that.

The main benefit of QUIC it seems is that it hides itself in UDP so
middleboxes don't tamper with it. It isn't really a fault of TCP itself that
middleboxes mess it up so much.

------
qalmakka
I think we definitely need more standalone libraries for both servers and
clients to really see QUIC's adoption flying. Nowadays it's either a Go
library some people have written or scavenging Chromium sources for libquic -
which is way less than ideal.

~~~
dsign
The protocol is quite complex, unfortunately, and also in flux, which deters a
lot of companies from adopting it in their supported solutions.

There is also the issue of HTTP/2 ... just because the major open source
servers have implementations for it, it doesn't mean that it has been
assimilated to its full capabilities in hundreds of other stacks. For many
organizations, it's hard to sell internally the adoption of yet another
protocol in such a short timeframe.

~~~
baby
You're also using a protocol that changes at every version of Chrome, making
you only compatible with the last version of Chrome if you're keeping up to
date, or with multiple versions if you're willing to do that to your code.

Chrome is also only talking QUIC to Google websites, not sure how you would go
about making it work with other websites (ask the G maybe?)

~~~
detaro
Wait until the IETF-version is finished and build on that? (it's a bit
confusing it is named the same, since it is not just a version of Google's)

~~~
baby
it'll either NOT happen, or if it does it will probably be in ages.

~~~
lclarkmichalek
I don't think that's true. There's a lot of momentum in the space, and several
large vendors have IETF-quic implementations that are pretty interoperable
already.

------
Moodles
David Benjamin has proposed the GREASE proposal for TLS. Basically, random
values of future flags are thrown around so that servers (not middleboxes)
have no choice but to process them. I think it is a good idea, but there are
still occasionally niggles such as certain machines processing different
meanings for specific flags, causing them to not be able to speak TLS 1.3.

~~~
pacificmint
Cloudflare had an interesting blog post[1] a month ago about TLS 1.3. It talks
extensively about ossification and the GREASE proposal.

[1] [https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-
yet...](https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/)

Previous HN discussion of the post:
[https://news.ycombinator.com/item?id=16010930](https://news.ycombinator.com/item?id=16010930)

~~~
indescions_2018
CloudFlare's Filippo Valsorda also dives into the nitty gritty of their TLS
1.3 implementation here:

TLS 1.3 - CloudFlare London Tech Talk

[https://vimeo.com/177333631](https://vimeo.com/177333631)

And his experimental golang crypto/tls pkg:

[https://github.com/cloudflare/tls-tris](https://github.com/cloudflare/tls-
tris)

------
xg15
> _The first byte of the clear data was a flags field which, he said, was
> promptly ossified by a middlebox vendor, leading to packets being dropped
> when a new flag was set.

That was a classic example of why changing network protocols is hard and what
needs to be done to improve the situation. Middleboxes are the control points
for the Internet as we know it now. The only defense against ossification of
network protocols by middleboxes, he said at the conclusion of the talk, is
encryption._

So apparently we're now at a point where _any_ middlebox trying to make any
use of a protocol higher than IP counts as "ossification"? No matter if the
middlebox is well-behaved or not.

And the only solution naturally is to make any stack parts higher than IP
completely unusable by middleboxes by encrypting them. I guess this is make
sense if you already fully control both clients and servers and get annoyed by
middleboxes restricting your freedom to change the protocol on a whim.

However, this seems like a major change in the vision of the internet to me.
So has the internet community at large now agreed that we want to get rid of
middleboxes completely? What about middleboxes I want to employ myself, e.g.
to watch my own traffic?

~~~
cesarb
> However, this seems like a major change in the vision of the internet to me.

The vision of the Internet is that the network does little more than moving
packets from point A to point B, with all the intelligence being in the
endpoints. That way, the core network doesn't have to be upgraded for every
little change in the protocols; protocol evolution happens on the edges of the
network. Please read the classic "World of Ends"
([http://www.worldofends.com/](http://www.worldofends.com/)), and the
technical article it links to, "End-to-end arguments in system design"
([http://www.reed.com/dpr/locus/Papers/EndtoEnd.html](http://www.reed.com/dpr/locus/Papers/EndtoEnd.html)).

~~~
0xdeadbeefbabe
Is it middle boxes that do TTL-- as in ping?

------
fsiefken
Coincidentally came across this while looking up a board game: "The hidden
costs of QUIC and TOU" [https://www.snellman.net/blog/archive/2016-12-01-quic-
tou/](https://www.snellman.net/blog/archive/2016-12-01-quic-tou/)

~~~
jsnell
While I still stand behind what was written in that post re: the non-endpoints
needing the ability to troubleshoot networks, it might not be totally up to
date.

A caricature of the stakeholders in QUIC standardization would split them in
three groups:

\- The privacy cabal thinks that every single bit of unencrypted data is
unacceptable, since with enough statistical evidence over enough data paths it
could be used to deduce some bit of totally irrelevant information about a
user.

\- The operator cabal believes that any bit of encrypted metadata (but not
payload data) is unacceptable, since there could be some valid operational
reason to access it.

\- The ossification cabal believes that any bit of unencrypted data is
unacceptable, since somebody in the operator cabal would end up misusing it,
and accidentally fix the protocol in place.

Now, obviously actual humans are more nuanced than that. Still, at the time
that was written, it appeared that there was absolutely no chance of getting
any manageability metadata at all. These are not positions conducive to
compromise. (And the lack of that kind of data leads to horrible things like
using the TCP traffic going to client X to infer measurements on the QUIC
traffic going to the same client).

But at the moment it feels like it might be possible (but nowhere near
guaranteed) for the standardization to export some minimal amount of transport
layer data. See for example the spin-bit proposal [0], where just 1-2 bits of
incredibly non-sensitive data would already go a long way. Give me a single
spin-bit and say 3 low-order bits of the packet number, and I'd be happy.

[0] [https://tools.ietf.org/html/draft-trammell-quic-
spin-01](https://tools.ietf.org/html/draft-trammell-quic-spin-01)

------
jonathanstrange
I have a question about an older UDP-based protocol. I was wondering for a
long time whether UDT is worth it and in which scenarios. Has somebody tried
it or is it kind of outdated?

~~~
dangerface
UDT solves problems tcp has with congestion especially at 10Gbit+, this gives
it a much higher throughput that tcp and pretty much anything else at 10Gbit+.
I don't think it did much to fix latency issues which I think quick is more
focused on.

If you are interested in low latency protocols you should check out
minimaLT[1] better performance than QUIC but the connections are portable
across ip's so its better for mobiles, and can tunnel multiple connections
together. DJB helped out with design so you know its super secure.

[1]
[https://cr.yp.to/tcpip/minimalt-20130522.pdf](https://cr.yp.to/tcpip/minimalt-20130522.pdf)

------
omginternets
For those of you using Go, it's been an absolute pleasure to use
[https://github.com/lucas-clemente/quic-go](https://github.com/lucas-
clemente/quic-go).

FWIW.

------
ibotty
I failed to find anything a few times in the last years, so maybe it does not
yet exist, but maybe someone here has any pointers.

How can linux' iptables/netfilter match quic packages. Because quic is no ip
protocol (but on top of udp) `-p quic` will not be implemented. Will one has
to write a quic helper, so that one could match using `-m helper --helper
quic`? I tend to think so, but I failed to find such a helper.

Is there some difficulty I fail to see? Or is nobody interested (because
nobody uses linux as a router)?

~~~
_wmd
It should in principle be possible to classify brand new Quic connections,
since a tiny handful of its fields are cleartext during the initial handshake
(flags and version, in both client/server directions)

As for classifying existing Quic connections, it might get a little messier.
There are still some cleartext fields but it might require observing multiple
packets in the flow before making a guess the traffic is likely to be Quic.

Meanwhile an explicit design goal of Quic is to avoid interference from
middleboxes, so it would be no surprise if a perfect iptables Quic match is or
remains impossible.

~~~
ibotty
I don't want to mess with the content in any way, I do want to send
connections over more than one WAN, depending on utilization. That works great
with https?-connections on tcp. It would be great to be able to do the same
with quic connections.

~~~
cesarb
> I do want to send connections over more than one WAN

QUIC has something which can help with that (from
[https://tools.ietf.org/html/draft-ietf-quic-
transport-09](https://tools.ietf.org/html/draft-ietf-quic-transport-09)):

"QUIC connections are identified by a Connection ID, a 64-bit unsigned number
randomly generated by the server. QUIC's consistent connection ID allows
connections to survive changes to the client's IP and port, such as those
caused by NAT rebindings or by the client changing network connectivity to a
new address."

If that's not enough for your use cases, now is a good opportunity to mention
them and suggest enhancements, since the IETF standard is still under
development.

~~~
ibotty
I don't think this will work for randomly sending over one or the other
connection, but I will just have to test to be sure.

------
fsiefken
How do QUIC features and capabilities overlap with those of HTTP/2? For
example would using them both defeat the purpose of using one in the area of
encryption or transfer speed?

~~~
baby
You SHOULD use both of them at the same time. HTTP/2 intertwines your data by
using different streams, except all of that is on top of TCP and one stream
blocking (because a packet was dropped for example) will block the other
streams. This is called head-of-line blocking and you basically can't do much
to fix this in TCP unless you create multiple TCP connections for your
different resources. But this has a bunch of other issues, you will need to
figure out congestion control for each separate TCP connection even if they're
connecting to the same service :/

QUIC also has multiple streams, but it doesn't have this head of line problem
and other streams will continue to work fine if one stream blocks. So QUIC was
made for HTTP/2, where your HTTP/2 streams are basically replaced by QUIC
streams which are not affected by loss of packets at all.

If you want to see how loss of packets affect an HTTP/2 connection over TCP,
it's pretty bad. In general if you're on a lossy connection you should just
use HTTP/1\. Check this awesome talk:
[https://www.youtube.com/watch?v=0yzJAKknE_k](https://www.youtube.com/watch?v=0yzJAKknE_k)

~~~
Aissen
I looked for this some time ago, but IIRC there's no third party
implementation that does that. e.g integrating quic-go and grpc-go

------
Someone
_”One key feature of QUIC is that the transport headers — buried inside the
UDP packets — are encrypted”_

I’m not sure I completely understand this, but does that mean you get net
neutrality for free if you use this?

~~~
wmf
Not for any useful definition of net neutrality; IP addresses are still
visible for ISPs to discriminate on.

------
easytiger
Makes me wonder whatefver happened to PGM Reliable Transport Protocol
Specification

\- [https://tools.ietf.org/html/rfc3208](https://tools.ietf.org/html/rfc3208)

Not an entirely dissimilar concept. LBM/29West being its successor.

------
wittedhaddock
For cases where the payload is small (<100kb), Caffeine
([http://www.caffei.net/](http://www.caffei.net/)) is a good solution (TCP
based)

------
nfoz
I wonder what is the real difference between QUIC vs SCTP-over-UDP?

~~~
JulienSchmidt
Lower connection establishment latency: SCTP over UDP using DTLS requires 4
roundtrips (that's worse than standard TCP) while QUIC (which includes DTLS
like encryption) only requires 1 roundtrip for the first connection and 0 RT
for subsequent connections, when it cached some information.

~~~
nfoz
Thanks, I found this:
[https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-
saqs...](https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-
ev2jRFUoVD34/mobilebasic#h.nvk2biis6bpk)

"One of the major and believably achievable goals of QUIC, is to predominantly
have zero RTT connection (re)establishment, as was mentioned in goal 3a above.
It is highly doubtful that SCTP over DTLS can come close to achieving that
goal."

\----

I actually think the "zero round-trip-time" claim is a bit too strong. It's
only 0RTT if you've communicated before, so in a way it's not a new
connection. There's a privacy implication here -- you should wipe that state
between communications to be more anonymous -- and also you only get
"predominantely 0RTT" with an increasingly centralized web.

------
DeepYogurt
The title really should be "UDP as a solution to protocol ossification". QUIC
makes the point that you can develop a new transport-ish layer over UDP.
Developing a new protocol on raw IP packets apparently gets blocked by
firewall boxes around the world.

~~~
avian
My take-away from the article is actually "encryption as a solution to
protocol ossification". If some data (headers, etc.) is available as clear-
text, there _will_ be routers that act on it and possibly misbehave or block
traffic when they encounter new patterns.

So the article suggests that making it impossible for routers to inspect any
protocol-specific information (via encryption) helps with this problem.
Routers can't act on fields they can't read.

~~~
vog
But then you have the whole industry of "security appliances" against you,
which do want to have a look, and which do want to MITM everything -
ironically arguing that this makes everything safer, depite becoming
themselves a huge attack surface.

~~~
DeepYogurt
Ya but they're wrong.

~~~
0xdeadbeefbabe
They're interested in business security at least, security of their own
business I mean.

------
anonytrary
Heads up to the lazy folks: the article is much shorter than the scroll bar
suggests.

------
bullen
Instead of making order guaranteed on UDP, allow removal (delay) of guarantee
from TCP:

[https://www.ietf.org/id/draft-add-ackfreq-to-
tcp-00.txt](https://www.ietf.org/id/draft-add-ackfreq-to-tcp-00.txt)

