HTTP-over-QUIC will officially become HTTP/3
daniel.haxx.se
daniel.haxx.se
To meet the data rate, we were sending datagrams that were 64KB in size (there was no system call at this time to send multiple datagrams in one go).
The datagrams were being fragmented into MTU sized fragments by the OS and reassembled on the remote end. However, with the data rate and the fact that there is only a 16 bit IP ID in the IP header, the fragments would often get missassembled on the receiving end and passed up to the UDP layer. Usually, the UDP checksum would detect the problem and throw the datagram out. However, since the checksum is weak and we were sending a lot of data, it would sometimes pass the datagram up to the application layer.
So, we would get corrupted data on the receiving end once in a while. It took quite a bit of time to figure this out, of course.
The solution was to implement dynamic MTU discovery along with the protocol so we could avoid the fragmentation.
The custom solution is still being used 20 years later!
Even if your packet ids are assigned poorly, on the receiving side Linux has a heuristic that takes in to account reordering to minimize the chance of reassembling bad packets. Basically if packets with the same frag id are too far apart then the whole datagram is chucked:
So, what's the point of ditching all that and reinventing HTTP over a thin wrapper (UDP) over (lossy) IP? Has there been a huge theoretical breakthrough which simply can't be applied to TCP?
Right?
"Just open more connections" has issues. QUIC making it less necessary to do that has value even if it didn't save memory or CPU usage.
Also, big(ish) routers are aware of TCP and can adapt as the load changes. They literally won't know what to do with a huge increase in UDP traffic.
I'd make an educated guess that mass deployment of QUIC will prove to be pretty awful until it's hacked to look more or less exactly like TCP with multiple connections, just with more overhead.
Randomly drop UDP packets.
Google(tm) HTTP/2.0 was unasked for, tried to reinvent TCP, found buggy and fundamentally broken after less than a year.
So now Google is pushing HTTP/3 to solve the bugs they made with HTTP/2, by reinventing even more of the IP-stack. What could possibly go wrong?
Can someone please tell Google that protocols are not Chrome-releases?
They need to work and stay working and supported for decades. You can’t ship a new revision every 6 month.
Edit: Correct HTTP/1.1 longdetivity.
Networks change as the world evolves and supports more people and applications, so new protocols are expected. HTTP/2 was great progress at the application layer, and QUIC is now about improving the transport layer.
Can you clearly list the bugs you claim HTTP/2 has?
Fair enough. Corrected.
> Can you clearly list the bugs you claim HTTP/2 has?
They seemed fairly well outlined in the post I was replying to, no?
Plus, this wasn't "found after less than a year". It was a known drawback from the very beginning, when the protocol was still SPDY, and deemed an acceptable tradeoff.
Perhaps a new version of TCP could've been made, and that's a valid concern, but it's a slow moving standard that takes decades to alter. QUIC evolved faster on UDP so that's what we have. What strategy do you suggest for improving TCP faster than the current process?
QUIC basically is a new version of TCP. Yeah, it's based on UDP, but, that is just an implementation detail. If it weren't for various poorly behaved middleboxes, QUIC could just sit on top of IP like TCP does. But, it can't - so we hold our noses and put it on top of UDP and we end up with something that actually works.
This is why browser marketshare matters. One player holding such a dominant position gives them according control over how web standards evolve.
- https://daniel.haxx.se/blog/2018/11/11/http-3/ - https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0...
However there's only so much you can at the application level. Some problems need to be fixed at the transport level, and there's where QUIC comes in. It's not fixing problems in HTTP/2 (at least not compared to HTTP/1), it's making things even better for high performance web applications.
I suppose that's one way of putting it.
Currently, the home page at www.google.com wants to do twenty-five requests in order to show me an interface consisting of a text input and two buttons. Google decided to fundamentally redesign HTTP to accommodate their own inability to impose any kind of discipline on their programmers. I don't see this as a good thing.
1) That is a ridiculous statement with absolutely no evidence to back it up.
2) The number of requests that Googles homepage does in order to load has _nothing at all_ to do with whether or not solving head of line blocking problems for the rest of the web is a good thing.
It has a lot to do with the desire to work around limits on the number of in-flight connections allowed to a single host, which is one of the primary things HTTP/2 is designed for.
It's also pretty unreasonable to point at www.google.com and say that it makes too many requests and it could be trivially fixed to use fewer. But, let's assume that the problem you identify actually is the case: Google is a huge, cash rich organization - if they can't figure out how to enact the change you suggest, how could any other organization? And if HTTP/2 and QUIC (HTTP3) solve this problem for Google, and since they are making it an open standard, also for other organizations, why is that a bad thing?
Press Ctrl+U on any Google page.
> The number of requests that Googles homepage does in order to load has _nothing at all_ to do with whether or not solving head of line blocking problems for the rest of the web is a good thing.
No, but it's evidence you claim doesn't exist.
It takes large team to produce a pages so bad as the Google landing page, blogger etc. For me, just about anything Google I looked at is to a well crafted website what elevator music played with a 1000 man orchestra is to someone with a guitar singing a really good song. The scale and the available resources makes the result worse to me, not better.
I’d hate to bring it up but here goes: SPDY was designed specifically to load the Google homepage quickly on typical American DSL MTU configuration, even with all that JavaScript tracking enabled.
Turned on it’s head: SPDY was designed to make google’s wide tracking of end-users impact page-load times as little impact as possible, to avoid it being a cause of end-user dissatisfaction.
SPDY was extremely tailored to a very niche need which first and foremost serves Google.
I see you don't cite any evidence that SPDY was miopically designed for American DSL connections, but regardless of that, HTTP3 is going to benefit a wife range of connection types.
How vile of them to force a purely optional protocol on us.
And then one day Google declares HTTP/1.1 deprecated, lowers the score of sites without HTTP/3, and removes support for HTTP/1.1 from Chrome in a week. You're personally free to not use it, but I'm not sure that everybody else will while you'll be the one responsible for supporting it on your website.
I feel like you're conflating two very different things into "head of line blockings".
Head of line blocking in HTTP/1.1 was that HTTP/1.1 cannot transmit responses out of order, so a slow response "blocks" any responses behind it. HTTP/2 solves this by being multiplexed (effectively, it tags the requests & responses s.t. you can match out of order responses back to the appropriate request). This isn't necessarily that the network can't handle it; a request that might be easy for the server to handle (e.g., a static asset) can get caught behind one that is not (e.g., one that entails a slow DB query).
The other "head of line blocking" that I think you're getting at is just network loss or saturation. If the network can't deliver packets, I don't see how having 6 connections is going to help: you're going to have to wait for six different state machines to determine that the link is saturated, back off, etc.
Regardless, my understanding is that QUIC / HTTP/3 is still a multiplexed protocol; I would think it would behave very similarly. Nonetheless, Google's announcement of it backs up your claim[1]:
> Like HTTP/2, QUIC multiplexes multiple streams into one connection, so that a connection can serve several HTTP requests simultaneously. But HTTP/2 uses TCP as its transport, so all of its streams can be blocked when a single TCP packet is lost—a problem called head-of-line blocking. QUIC is different: Loss of a UDP packet within a QUIC connection only affects the streams contained within that packet. In other words, QUIC won’t let a problem with one request slow the others down, even on an unreliable connection.
But what here makes QUIC think that those other requests have any hope where the first didn't? To me, this approach seems like you're just spamming the link with packets and hoping for the best; those packets could just end up dropped like the other ones were. What makes QUIC think this approach will have any benefit? (It could, perhaps, if the link is just going to drop one packet and we can get right back to sending. I'm not sure that still conveys any benefit over TCP. Not saying QUIC is wrong, just that I don't see a decent reason to buy into it.)
(This whole thing makes me think there are two problems here: there's the actual network connection between two endpoints, and what its state is, how lossy it is, its PMTU, how much data we should allow in-flight between those two endpoints, etc. But then there is also logical streams, such as HTTP request/response pairs. It almost seems like to me any data about the link, such as PMTU/lossiness/window, should be shared between all TCP connections, and the individual logical streams should be otherwise cheap/easy to make.)
[1]: https://cloudplatform.googleblog.com/2018/06/Introducing-QUI...
There are a lot of ways to lose just a single packet. One way is a router is overloaded and so it throws some packets away. Another is some brief interference on a wireless connection.
I think the phrase "spamming the link" is incorrect. QUIC does flow control to determine how much data to send. Once it's decided that the link can take a certain amount of data, it will send it. So, say it sends packets 1, 2 and 3. But, let's say that packet one is lost but 2 and 3 get through. With QUIC, the receiver can potentially do something with packets 2 and 3 with TCP, the receiver couldn't. Regardless, QUIC will respond to the packet loss by updating its flow control information - I haven't read anything that suggestions that QUIC responds by "spamming the link".
> This whole thing makes me think there are two problems here: there's the actual network connection between two endpoints, and what its state is, how lossy it is, its PMTU, how much data we should allow in-flight between those two endpoints, etc. But then there is also logical streams, such as HTTP request/response pairs. It almost seems like to me any data about the link, such as PMTU/lossiness/window, should be shared between all TCP connections, and the individual logical streams should be otherwise cheap/easy to make.
You've basically described what QUIC is in this paragraph
You would need kernel support here, though, would you not? (And you would need a generic protocol. I have admittedly not studied QUIC thoroughly yet, but my impression was that it was strictly HTTP / not generic.) Without kernel support and/or being generic, I don't see how it's really different from HTTP/2 w/ a single TCP connection.
This document is about doing HTTP on QUIC, so it's renaming itself HTTP/3, the main QUIC document is as you've described it 'generic'
I wasn't as clear as I wanted to be. Yes HTTP/1.1 has head-of-line blocking on a single HTTP Connection (read TCP connection). Attempts to solve HTTP's head-of-line blocking like HTTP Pipelining didn't receive widespread adoption for many reasons, primarily middle ware boxes screwing things up.
H2 achieves logical parallelism by multiplexing requests/responses over a single connection. H1 solved it by allowing 2 (then 4, then 6-8) parallel TCP connections to a single origin.
While you might think that having 6 parallel TCP connections makes you 6x more like to encounter network loss, saturation, and dropped packets, that doesn't seem to be the case.
The best paper to date on this is "HTTP/2 Performance over Cellular Networks" [1]. In rigorous testing, they found that in slower/congested networks, H2 is actually worse than H1, sometimes by a lot. If 1 TCP connection in H1 stalls, no big deal, you have 5 others to that host. If 1 TCP connection in H2 stalls, you are stalled.
[1] https://www.akamai.com/kr/ko/multimedia/documents/technical-...
Since HTTP is the use case here, it is possible to create a protocol that is optimized for it, whereas TCP cannot be optimized specifically for HTTP.
Source: I've implemented a reliable, stream oriented protocol over UDP which has been in use for many years.
You don't really want to drop data for streaming video either, sure, in some cases it might not make a huge difference, but if you drop i-frames, you are going to have quality issues.
I'm not sure if HTTP/3 will have a way to do selective re-sending, but that is how very versatile lossy video streams do it. I-frames can get re-sent while normal frames can be lost.
ref: https://docs.microsoft.com/en-us/windows/desktop/WinSock/tcp... https://linux.die.net/man/7/raw
h2 failed because it's mux everything into 1 single tcp connection, and it only takes 1 failed tcp to block everything in line.
h2 really need to do demux. But h2 actually can technically do M:N connections, but browsers do only 1:N.
Also h2 is a failed promise. Most sites deliver web assets and page and js in different host, also ws/wss in a different host. Thus renders h2 advantages complete useless.
Just curious, what do you mean? Quickly Googling this, it looks like 1/3 websites use HTTP2 today, which is darn good for a relatively new protocol.
Most sites use h2 by just wrapping http/1.0 behind some h2-enabled CDN or upgrade to latest nginx and call it done.
What about h2 push? Priority? WS inside h2? Nope. No one use them obviously.
I mean gRPC utilized more h2 features than most h2 browsers/CDN do.
I'm curious to hear what you mean by WS inside h2, not sure how that's different. WS is only http for the first part i.e. the upgrade request.
I am less worried about what most sites do and more interested in the features offered by implementations. A huge number of sites don't even use https.
Again, the goal of h2 is not to maximize usage of features in the h2 protocol. So judging h2 by that metric does not make any sense. I could just as easily complain that HTTP is a failure because few sites use more than just GET/POST, or because many of the headers defined in the HTTP standard are not commonly used.
Sure, there's some other stuff in there, server sent goaway in particular is a great way to indicate the server intentionally closed the connection, but the primary objective is to get around congestion control -- which could have been better solved by just adjusting congestion control to pool by destination IP in clients Google could control (at least Android) and on servers Google could control (at least their servers)
You can try and diddle with chunk size and message prioritization in your application to reduce HOL blocking of low latency messages behind chunks of high throughput data, but your OS will buffer everything in one big queue anyway (because TCP is a single stream and flow control applies to that entire stream as a whole).
How do you fix that? Well you can reduce socket buffer sizes on your TCP connection, and that will fix latency... but small buffer sizes mean your total throughput is limited by round trip time (because of the way the TCP receive windows and positive acknowledgment work). If you're working over a LAN, things will be fine, but over the Internet you're hosed.
Of course, the solution really is to have separate long-lived TCP connections for different kinds of flows, so you can set buffer sizes appropriately... but that's impossible for your browser (which is responsible for opening connections). It has no way to know whether a GET request triggered by an <img> tag is going to yield a 100 byte response or a 100MB response.
But... which use cases of HTTP need us timers? It's not like gmail or other bloated web apps will load faster on my phone because of QUIC?
Anyway, that's mobile. In the datacenter all of these timers are way too high, by several orders of magnitude. 1ms is an outrageously long RTO in a datacenter fabric but 200ms is the minimum RTO allowed by the TCP RFCs.
In general, it is true that TCP is highly optimised, but it is only optimised for one use case: a long lived single flow over a low error rate connection to a single destination. That was the predominate type of connection back in the FTP and early web days. But is hasn't been that way for a while now. HTTP is short lived, video goes to multi destinations, HTTP/2 and multi media in general has multiple flows. Wireless only appears to be low error rate because the physical layer had to cover up it's shortcomings otherwise TCP's performance became abysmal.
TCP hasn't remained king of the mountain because its fantastic protocol that can't be improved. On the contrary - looks to be the simplest thing it's inventors could come up with. It even lacked round trip time measurement - which is something I suspect that would have killed it if an extension hadn't saved it. TCP has remained king of the mountain purely because it appears to be near impossible to replace. Now that Google has done it, I expect we will see a lot more experimentation in this area.
If you want to put security on/into IP, you suddenly need the whole key management thing, and if you want it to be automatic, you need to somehow cobble together the assignment, provisioning, allocation, publication, revocation of keys with IP addresses (or hostnames, domain names, and you just put DNS into IP).
Eventually it means either you need manual key management (thus IPsec becames a hard to manage old rusty and poorly supported concept from an old era) or you just descended into the recursive pit of all hells of circular dependencies. Sure, it can be done, we can put keys into DNS, and we can use that, but then we're back to QUIC or DTLS basically.
The thing is, how you set up (mutual) authentication is very much an application level thing. Do you want certs, an SSH key, passwords, hardware tokens, SIM based authentication, or something else? These aren't things the OS can decide, and they aren't so simple we could tell the OS what we want with a few flags.
I did a quick read on the subject and main argument for QUIC seems to be zero roundtrip session establishment - using TLS session resumption. SCTP uses a 4-way handshake.
Also found this comment from 2015: https://news.ycombinator.com/item?id=9639824, and this ietf draft: https://tools.ietf.org/html/draft-joseph-quic-comparison-qui...
It then seems that optimized protocols like QUIC could benefit from disabling this lower level error correction.
Is this at all possible? Do the wireless physical protocols allow for such a thing? Do the operating systems offer it as a flag?
Bundling HTTP and QUIC into one protocol is a bad idea because (1) it increases complexity, (2) it creates application-specific QUIC implementations, which will become a problem later if QUIC is adopted by anything else, not to mention the security holes/feature gaps in different implementations, etc, (3) it reduces the likelihood of the operating system supporting QUIC as a first class L4(OSI) protocol, which will further doom any network application that uses any method of IPC other than an HTTP request.
Honestly, the way modern network applications operate is embarrassing. People in the future are going to look back and wonder what was wrong with us.
/s
1. An internet standard 2. Already has kernel support 3. Was not developed by one company
And, most importantly,
4. IT'S ALREADY IMPLEMENTED IN EVERY MAJOR BROWSER!
I know little about SCPT. Why is it preferable?
This looks to me like a strict superset of what QUIC is intended to solve. And it is already supported in all major operating systems.
This is not something very easy to fix - not as easy as fixing Cisco devices that hijack 1.1.1.1, or upgrade enterprise-grade MITM firewalls that don't know and block TLS 1.3.
It's standard only on paper. There is only one significant user space implementation (usrsctp). It's used both by Chrome and Firefox. I don't think it has much use outside of that. And, I don't think other browsers implement data channels (which require SCTP).
Browser implementations will probably never have to interact with kernel implementations (which are not really used outside of telecoms). There is really no reason to make them talk the same protocol. It's likely better to use two different protocols tuned to those specific uses:
https://tools.ietf.org/html/draft-joseph-quic-comparison-qui...
They will probably replace SCTP with QUIC also in WebRTC:
There's two sides to networking -- client and server. Your arguments may make sense for the client, but they do not make sense for the server, IMO.
> There is only one significant user space implementation (usrsctp)
That's right, but there are others (one was posted a while back) independent implementations, and the kernel implementations (BSD, Linux, likely others) are indeed different.
Only one significant opensource implementation. Behind the scenes, SCTP is used to connect most telephone calls in the world.
Google is not interested in what is implemented in every major browser. Google is interested in making sure that Chrome is the only browser of any significance on the internet and it behaves in a way that Google wants it to behave ( such as forcefully signing into Google services ).
That's why we got HTTP/2 ( which seems to be viewed as a flop at Google ) which is why we are getting HTTP/3.
Follow. The. Money.
But google is big enough to push through that problem, IMHO, as long as browsers fail back to HTTP/2 or HTTP/1.1, the widespread acceptance of SCTP would be a boon to e.g. VoIP and game developers. But alas it's too late. QUIC has been in development for six years now.
So what ? We standardize on a hack because Deep Pocket ?
Not even mentioning competitive advantage for big cloud companies ...
Not really. There are hundreds of millions of home routers deployed that all do NAT. And they all don't support NAT for SCTP. And many do NAT with hardware support, so it's probably not even fixable with a firmware upgrade, which isn't even an option for a ton of unsupported devices anyway.
So, I think encapsulating in UDP is the only realistic option if you want to gain any adoption any time soon.
Also, SCTP has the same problem that TCP has in that the network can look inside the protocol, and thus you would get protocol ossification. While Google does this for selfish reasons, I think it is a really good idea to establish a protocol that is completely opaque to telcos and should ultimately benefit the public. Telcos really don't want to be dumb pipes, and they tend to abuse any power they get, as they have demonstrated time and time again, and the only way to force this issue is by simply making it impossible for them to see or manipulate anything at all. So, while we may have to live with the UDP encapsulation forever, and as stupid as that is, this at least ensures that anyone in the future can trivially invent and deploy new protocols, as it is trivial to masquerade anything at all as QUIC. The adoption of QUIC for the web has the potential to get all ISPs to fix things so that QUIC actually works reasonably reliably over their network. And the fact that as far as the network is concerned it's just UDP packets filled with random data ensures that as long as your new protocol is UDP packets filled with random data, that will work as well, even if you use completely different mechanisms for framing or flow control or multiplexing or whatever.
It doesn't take any dedication at all, it only takes address exhaustion. Which is precisely why it took so long.
> Why can't SCTP adoption be a similar long term project?
Because there is zero incentive for Telcos.
> QUIC has been in the making for 6 years now?
And QUIC (the Google "prototype") has probably been successfully deployed to more devices than IPv6 by now?
void encaps_udp(void *out_buf, void *old_pkt, size_t old_pkt_sz) {
struct udphdr udp;
udp.dport = UDP_DEST_PORT;
udp.sport = UDP_SRC_PORT;
memcpy(out_buf, &udp, sizeof(udp));
memcpy(out_buf + sizeof(udp), old_pkt, old_pkt_sz);
}
Of course, this encapsulation for SCTP is even standardized in case it wasn't obvious that this is how you encapsulate protocols.
More importantly: You are missing the point. Great, you have encapsulated your protocol in UDP. Now, what do you notice? Your ISP is throttling your protocol because for some braindead reason their traffic management has categorized it as some sort of unimportant protocol, probably P2P or something. Or they just throttle UDP in general, because who uses UDP besides DNS and VoIP? So, high bandwidth UDP usage is obviously a DoS, and we don't want that! If you are unlucky, maybe they even shut off your server because it is obviously part of a botnet?
OK, so enough people complain to their ISPs that SCTP over UDP doesn't work. What happens? Exactly, ISPs start putting in rules that "recognize SCTP over UDP". So next time you want to try out a new protocol or extend SCTP somehow, you run into the exact same problem.
The difficult part isn't stuffing bytes into UDP packets, the difficult part is making sure it actually works reliably and fast over the public internet.
1. While getting telcos to fix their network so that QUIC works optimally might also need some work, it should be easier than for unencapsulated SCTP for the simple reason that (a) there is a relevant proportion of the network that already does work fine with it, so it is easier to blame the bad providers when things don't work so well with some provider that throttles UDP, say, and (b) in the case of simple UDP throttling, QUIC is in competition with VoIP and DNS, which could lead to degradation of those other services, which should increase the pressure to fix things. And in any case, you at least don't need to touch all CPE, only middle boxes within the infrastructure.
2. Probably more improtantly, SCTP is a plain text protocol, so getting it to work over telcos' networks does not help you at all the next time around when you want to evolve protocols. Once the work is done for QUIC, you won't have to do it ever again, because anything new that you could come up with is easily made indistinguishable from QUIC as far as the telco is concerned.
There's an old phrase: better to keep your mouth shut and be assumed a fool, than to open it and remove all doubt.
SCTP is not a plain text protocol. I'm not sure how you managed to convince yourself of this one.
Here is the bit-by-bit format of the SCTP header, in case you were ever confused again:
https://tools.ietf.org/html/rfc4960#section-3.1
In the above post, I was talking about SCTP over UDP, which is an IETF standard already. You have moved the goal posts by talking about unencapsulated SCTP. We all agree that this is a tough problem. However, QUIC is also encapsulated over UDP, and when encapsulated, has the same advantages / disadvantages as SCTP over UDP.
SCTP over UDP over DTLS already constitutes a good portion of web traffic, since WebRTC (and hence technologies like hangouts, facebook video messaging, etc) is based on it.
> Here is the bit-by-bit format of the SCTP header, in case you were ever confused again:
> https://tools.ietf.org/html/rfc4960#section-3.1
I can not find there a single hint that anything is encrypted, and I would have been very surprised if I had. The security considerations do even explicitly acknowledge that it's up to the application to encrypt the payload if it wants to.
> In the above post, I was talking about SCTP over UDP, which is an IETF standard already. You have moved the goal posts by talking about unencapsulated SCTP.
No, I simply covered that case as well because SCTP on IP was mentioned as a supposedly viable alternative in this discussion as well, which supposedly would be preferable over QUIC because of lower overhead (which is true if it works, of course).
> However, QUIC is also encapsulated over UDP, and when encapsulated, has the same advantages / disadvantages as SCTP over UDP.
No, it then has the advantage of being nearly completely encrypted, so we don't get any protocol ossification.
> SCTP over UDP over DTLS already constitutes a good portion of web traffic, since WebRTC (and hence technologies like hangouts, facebook video messaging, etc) is based on it.
Well, yeah, but then what's the advantage over QUIC? It's also a complete flow control and encryption stack in user space if you want to run it over DTLS! I mean, I don't mind SCTP, but it's not like the kernel implementation is of any help when you want to run it over DTLS ...
Plain text is typically used as the opposite of 'binary'. You are intending to say 'unencrypted' or 'clear text', not 'plain text'. SCTP is not encrypted by default. It is a transport protocol and it is intended that
> Well, yeah, but then what's the advantage over QUIC? It's also a complete flow control and encryption stack in user space if you want to run it over DTLS! I mean, I don't mind SCTP, but it's not like the kernel implementation is of any help when you want to run it over DTLS ...
the advantage is that DTLS over SCTP is an internet standard that was created organically by a variety of motivated individuals and organizations. DTLS over SCTP does not require kernel encryption, and is implementable in userspace. This is similar to how TLS is implemented in userspace but uses the kernel TCP drivers. SCTP has been a standard for almost two decades and DTLS over SCTP for a similarly long time. There is no reason to replace something that works, with something that is exactly the same, except for the fact it's invented by Google.
You claim QUIC is encrypted. It is not. QUIC is a transport protocol and transport protocols need their headers to be inspectable to provide good routing, etc. The payloads are encrypted, like any other transport protocol.
The point is that there is no technical advantage to QUIC over DTLS over SCTP over UDP. Thus, we should reject the new standard in favor of the existing one.
This is similar to how, if someone made a POSIX-like specification that fulfilled all the same requirements as POSIX, we shouldn't simply adopt because it's newer. If the new technology offers no advantage over the old, then the new technology should be rejected as offering nothing new.
https://en.wikipedia.org/wiki/Plaintext
Also, context. None of what I wrote makes any sense under the assumption that I was talking about a 'character string protocol'.
> the advantage is that DTLS over SCTP is an internet standard that was created organically by a variety of motivated individuals and organizations. DTLS over SCTP does not require kernel encryption, and is implementable in userspace. This is similar to how TLS is implemented in userspace but uses the kernel TCP drivers.
Which is true, but obviously does not apply to SCTP over DTLS, which is what you were talking about in your previous post.
> There is no reason to replace something that works, with something that is exactly the same, except for the fact it's invented by Google.
Well, true. Which is why it is relevant that QUIC is not exactly the same, as I have explained a dozen times now.
> You claim QUIC is encrypted. It is not. QUIC is a transport protocol and transport protocols need their headers to be inspectable to provide good routing, etc. The payloads are encrypted, like any other transport protocol.
Routing happens at the IP layer, so, no, a transport protocol does not need to be inspectable. And in fact it is an explicit design goal of QUIC to minimize what is inspectable. Which is why it is essentially uninspectable.
All that is inspectable is a connection ID and a packet sequence number. The sequence number doesn't really tell you anything as it is not even a sequence number of payload segments, but only of transport packets (so retransmits get new sequence numbers). The connection ID tells you which packets form a connection ... but then there is essentially one connection between two endpoints, so nothing to see there either that isn't obvious from the network layer anyway.
But none of the flow control machinery is inspectable by the network, and even the unencrypted header fields are still authenticated so as to prevent any meddling by middle boxes. Also, you know, you can read all of this in the specification, maybe that'd be better than removing more doubt?
https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02#sec...
I did mention sctp over dtls, but not as a replacement for quic. Only to say that it is a transport protocol that already is being used
Which is exactly why we need QUIC (or something like it), because they shouldn't, it's causing more problems than it helps.
But why bother when you can hack a wrapper around UDP and pretend you're long term planning for the "greater good" ?
I worry that everyone will have an incentive to "cheat" at congestion control, leading to a tragedy-of-the-commons situation of ever-more-aggressive flows, followed by eventual congestion collapse.
This effect didn't happen with in the TCP world, since most applications don't run with enough privileges to speak TCP without the kernel's involvement. But now that we're moving to a model in which applications do their own congestion control, an arms race seems inevitable.
> This effect didn't happen with in the TCP world, since most applications don't run with enough privileges to speak TCP without the kernel's involvement.
The argument is that while kernel developers wouldn't start this supposed "arms race", but application developers would.
I think we would have seen this already with things like (m)uTP if it was an issue.
(But even then, just open lots of TCP connections if you want to have your unfair share of bandwidth)
Also, couldn't the OS still throttle back greedy applications? No reason it couldn't detect the heavy stream of UDP traffic.
The OS can throttle sends on a single machine, but it can't arbitrate across machines or do anything about incoming flows.
Isn't that the case with TCP's congestion control as well? If the server's kernel isn't backing off properly, how can the client's TCP stack mitigate that?
So far, these hacks have been limited by the need to work with stock receive-side TCP stacks. Once you move to UDP, all bets are off.
I suspect that's more down to NAT than anything else
In the past Bittorrent and the creation of the µTP prooved ( http://blog.bittorrent.com/2009/11/13/testing-%C2%B5tp-is-%C... ) that unmanaged protocol abuse in userspace can lead to big degradation in QOS yes. Mainly due to "unfair" congestion policy between protocols.
Or will HTTP/1 and 2 slowly decline over time?
Genuine question, not snark.
Remember that UDP itself is stateless. So you either need some explicit port mapping via UPnP (which seems like a nightmare because HTTP connections are so common), or some really smart router that understands QUIC.
Sorry, I would find it myself but I'm on mobile right now...
QUIC is basically rebuilding the stateful connection abilities of TCP on top of UDP with optimizations.
Multiplexed streams with packets that can arrive out of order, removing the head of line blocking issue with TCP. There is also forward error-correction to reconstruct lost packets instead of retransmitting. Better packet sizing and congestion algorithms to reduce round-trips. There are also updates to include all the TLS 1.3 stuff for 0-RTT setup.
All of this reduces latency and makes connections more reliable, especially with changing networks on mobile devices. Not many downsides other than that TCP is far more open and optimized than UDP so it may take a while to effectively get this protocol out there.
In particular QUIC contains everything necessary to continue connections after the client's IP address (any one side really, but the other side has to find it) changes, which is helpful when devices change between networks without needing a Mobile IP-style bouncer.
The Hangout connection doesn't drop. It may go fuzzy/staticy before the WiFi drops in favor of LTE but that's all.
It's expensive to support on servers because (to my knowledge) there's not a good way to ensure related sub flows arrive at the same nic rx queue on the same server in real world load balancing situations, which is critical for performance.
Nobody else is doing it (other than Apple for Siri), so it's not clear what the benefits are.
On mobile, it is meant to use an entirely separate network backbone (wifi vs LTE) so doesn't offer much benefits when you're limited to a single type.
Obviously that doesn't solve any immediate problems, in that I'm sure it would take a decade to get something like that in widespread use. But if the theory is that TCP isn't so great given what we know now, I'm wondering if it's worth making those capabilities available to other protocols.
> HTTP/3 (originally named QUIC) is an experimental transport layer[1] network protocol designed by Jim Roskind at Google,[2] initially implemented in 2012,[3] and announced publicly in 2013 as experimentation broadened
and then
> In June 2015, an Internet Draft of a specification for QUIC was submitted to the IETF for standardization
Unless you count 'developed independently by Google and then three years later submitted to IETF for standardization' as 'developed from scratch by an IETF working group', I fail to see how your assertion is backed by actual events.
For the record, SCTP has been standardized since 2000, and it was actually developed by an IETF working group.
Discussion from four years ago: https://news.ycombinator.com/item?id=8465956.
Way back this was IPX/SPX vs IP/(TCP|UDP). We know who won that and what happened to the loser.
There is another aspect to this: agnostic network and 'good enough' conceptions have been historically adopted by engineering organizations to remove vendor disposition from the end user landscape and protect the end user. On this forum a lot of these historical protections are seen as passe or unimportant for reasons best not scrutinized too closely.
IMO, the idea embodied in encapsulation of application protocol traffic in stateless transport to avoid a vendors technical issues with existing application stream orientation|transport in the non-vendor real world is one of the ugliest ideas I've yet encountered.
There are a lot of good ideas floating around in the comments here that avoid vendor lock in for applications stream based transport that already exist.
So we are to believe that the people who thought that multiplexing a single TCP connection over mobile was a good idea, that moving lockstock and barrel to UDP will solve our problems?
Look, its very simple: HTTP is now a file server protocol with a chatty control channel smashed in. However instead of optimising for that we have this.
It basically seems like a massive ego trip: "we can't admit we were wrong about the multiplexing thing, lets just bash out a reliable UDP protocol"
Look, the vast majority of file transfer protocols are TCP for a reason. Loosing chunks of files is annoying, and making a custom protocol over UDP that is both fast start reliable and fast, is actually quite difficult.
Yes, UDP has the advantage that you don't have a connection, and you can just fire stuff at the destination port and it'll magically arrive. however, anyone can do that. How does HTTP3 handle noise? how does it handle spoofing?
Basically, H2 was a regression because it was designed by people who didn't appear to understand real world networks, this seems like a doubling down.
I have evaluated QUIC, as reliable stream protocols on UDP are something I have a professional interest in.
> QUIC is the next iteration of TCP
Its not designed for that.
> That it lives on top of UDP (& might ship that way) is an implementation detail due to the realities of how the Internet is built
no, its fundamental. You can't just swap out TCP with UDP and have done with it. If we ignore the Datagram vs stream aspect, we are left with implementing our own flow control, packet loss and authentication.
Which is where my comment comes in, with a TCP socket, if someone tries to inject spoofed packets, (assuming we in a non-LAN environment) those packets will be rejected long before they reach us. In UDP no such guarantees exist.
Thats not considering flow control, which is a whole 'nother issue. Its always a trade-off between efficiency, speed and reliability.
I would suggest an evaluation in which you completely omitted to notice the central feature of the protocol doesn't reflect well on your abilities, regardless of whether you claim it's a "professional interest".
My point is this, the client is protected from a _lot_ of noise. QUIC changes this.
The client does all this when you open socket.connect()?
no, no, you're not and no, it doesn't, which is part of my point. Lots more noise will be forwarded to the client directly, after all, stateful connection management is impossible. With more noise, comes a bigger attack surface.
Yes, yes it is. I did 20% on Quic, I've talked with the engineers on it, I've read a lot of the paper, I've written some code. It's 100% intended to replace TCP as much as SCTP & other next-gen stream-oriented protocols are. It's written on top of UDP because they're dealing with the realities of public routing on the internet.
> no, its fundamental. You can't just swap out TCP with UDP and have done with it. If we ignore the Datagram vs stream aspect, we are left with implementing our own flow control, packet loss and authentication.
This again leads me to question how much you've actually researched Quic. It does all that & more. Now it is easier to write a Quic client in user-space that misbehaves for flow control & distribute that (TCP would typically require root access). However, that's the reality of the Internet - middleboxes have ossified the ability to add new protocols. It's why SCTP & the like are non-starters even though IETF has tried to get them to work for so long.
> Which is where my comment comes in, with a TCP socket, if someone tries to inject spoofed packets, (assuming we in a non-LAN environment) those packets will be rejected long before they reach us. In UDP no such guarantees exist.
Are spoofed packets validated at every hop? It would seem like memory & CPU load at backbones would be insane to keep track of all the connections flowing across it. I'm also curious how that would be possible because a backend route switch (i.e. new BGP route) would cause all middleboxes to drop the connection. I'm not sure even ISPs try to reject TCP connections early.
As for the "protection" you lose (if there is any), you gain by your ability to hop physical networks without losing the connection (i.e. WiFi & cellular). This means there's all sorts of cool things you can do that simply weren't possible before; use both wifi & cellular at the same time to download the same file, seamless handoff of a video chat without requiring any ISP support, seamless detection & handoff of a failing internet route to a fallback connection (i.e. walking in the parking lot without having to manually switch off WiFi).
The connection itself does have a connection ID in the public header in the version negotiation packet which is then mirrored in the encrypted packet header to protect against spoofing. However, the connection ID may be omitted from the public header in future packets.
Anyway, I recommend reading the IETF docs on QUIC [1][2], if you have an open mind. If you just have the mentality of "UDP bad", then probably you will be wasting your own time reading it. There's lots of really smart networking experts who work on & design QUIC & lots of smart people in IETF looking over & providing feedback/criticism. I think it's safe to assume they've covered any obvious problems concerns.
[1] https://tools.ietf.org/html/draft-ietf-quic-transport-08#pag... [2] https://tools.ietf.org/id/draft-ietf-quic-manageability-01.h...
1. Connection management 1.1. Initial handshake allows arbitrary layer above initial handshake in same packet as body 1.2. Subsequent packets have connection identifier.
2. Encryption. The SSL bits.
3. Multiplexing and Congestion control.
So in essence the trick of QUIC is not collapsing layers, but splitting TCP into connection management and congestion control and moving SSL in the middle.
So why wasn't this proposed? I hope not because people are too "practical" to care about layering and abstraction anymore!
Is there any testing toolkit that will tell me "bzzt! you messed up header X" or any other error I might make?
For example, Snowflake[1] which is WebRTC based, and meek[2] which chunks the stream into a series of HTTP requests/responses for domain fronting. TCP is still used between nodes.
[1] https://trac.torproject.org/projects/tor/wiki/doc/Snowflake
Also clients don't have to use QUIC.
A deep dive impartial comparison at different usecase/workload would be great.
Will it? The TCP header is 20 bytes, the UDP header is 8 bytes. And in as far as packets are bigger, will it actually cause more traffic? For example, you have muliplexing of streams over one connection without head of line blocking, while with HTTP over TCP you need multiple TCP connections and thus multiple TLS connections for that, for example. Also, QUIC allows you to change UDP endpoints without the need to establish a new connection. I wouldn't be so sure it needs more bandwidth.
Now, arguably, building directly on IP would be better, but that is unfortunately an option that ISPs and other manufacturers and operators of middleboxes have destroyed, so I think you can't really blame QUIC for that. There really is no realistic way to evolve beyond the limitations of TCP unless you build on UDP. If QUIC succeeds and if we manage to move to IPv6 and get rid of NAT, though, I guess there might be a chance to one day see "QUIC on IP"--as far as the protocol is concerned, it should be trivial to adopt it for direct IP transport.
TCP minimum header is 20 bytes.[1] QUIC "short header" (after key negotiation) looks like it can go down to 2 bytes for non-roaming connections with a 1-byte packet number, if the server allows the omit_connection_id, and 10 bytes otherwise.[2] Add the UDP header (8 bytes[3]) and you're at 10-21 bytes. So if you both supply a connection ID and a 4-byte packet number you're just barely at the same transport overhead as TCP; otherwise it's less.
(The QUIC "long header" is longer but that's a fixed cost and shouldn't matter too much for overhead.)
Or am I missing something?
[1]: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#... [2]: https://tools.ietf.org/html/draft-ietf-quic-transport-08#sec... [3]: https://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_...
QUIC is supposed to send fewer packets for the same payload, at least that's what I've heard. I don't follow it closely. Assuming that's true, if you want people to believe that QUIC packets are bigger and that the increased size more than compensates for their reduced number, you'll have to supply arguments. Packet traces for a few typical connections would be good arguments. Assuming it's false, you'll need much the same kind of argument.
(FYI I've written ten RFCs and like to think I've learned the RFC processes by now.)