
A QUIC look at HTTP/3 - lukastyrychtr
https://lwn.net/SubscriberLink/814522/ab3bfaa8f75c60ce/
======
cmroanirgo
> _In practice, it will mean asking the DNS first to check if HTTP /3 can be
> used._

Looking at the (draft) DNS specs for HTTPSSVC records [0] it seems that
there's also the equivalence of SRV records? (SRV records is something that
the browsers have never implemented)

I recall a semi-recent discussion about the prevalence of CDNs and what
options there are for smaller players and DIY-ers and how SRV could have had a
role in that [1]. I'm really looking forward to the spec rolling out if this
is the case!

(There's a little example given in the Appendix of the DNS specs [2])

[0] [https://tools.ietf.org/html/draft-ietf-dnsop-svcb-
httpssvc-0...](https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-01)

[1]
[https://news.ycombinator.com/item?id=22073098](https://news.ycombinator.com/item?id=22073098)

[2] [https://tools.ietf.org/html/draft-ietf-dnsop-svcb-
httpssvc-0...](https://tools.ietf.org/html/draft-ietf-dnsop-svcb-
httpssvc-01#appendix-A.1)

~~~
tialaramex
Yes, Alt-Svc just isn't practically faster unless you're constantly back to
that particular site so a DNS solution had to be on the table, and (the
current assumed path for) eSNI assumes a DNS solution too.

It will be interesting to see which is the biggest deployability headache out
of QUIC itself (UDP doesn't work for a noticeable fraction of users) and
HTTPSSVC (not only will lots of people who have a shiny new HTTP/3-capable
server not have a DNS server that understands HTTPSSVC lots of their clients
have DNS servers which reject queries they don't understand outright).

Remember it was about a year between TLS 1.3 being finished and being really
finished, because the standard that was cryptographically sound and made sense
from an engineering perspective couldn't be deployed - what we've got now is
that protocol seen through a funhouse mirror that lets it pass middleboxes.

For example the version field where you'd write TLS 1.3 (actually in a sense
SSL 4.2 or maybe SSL 5) you can't do that. To sneak past a middlebox say
instead that you're TLS 1.2 like it expects, and furthermore, you are re-
connecting. It shouldn't worry that it can't understand the rest of what you
say because you're just re-connecting - it must have approved that previous
connection and so logically this one is likewise fine. Actually remembering
which such connections have happened would cost money and isn't required to
make the test pass so the middlebox doesn't do that and many will just allow
all re-connections past untouched.

------
clarry
Am I the only one who thinks QUIC looks a bit crazy with all its variable
length fields in the frame, separate short & long header format, and rather
high limits for certain things? 160 bit connection ids and 64 bit stream ids
sound like something you'd benefit from if you're Google scale and building
big-ass load balancers on custom hardware but I feel like there's going to be
a lot of overhead for everyone else. (Consider that a TCP header with no
options is as large as a single maximum size connection id in QUIC).

At least the designers of IPv6 seemed to care more about efficiency, even if
the protocol otherwise seems quite bloated and overengineered.

~~~
the8472
I guess connection IDs are that large to allow the use of stateless
cryptographic identifiers similar to tcp syn cookies. And stream IDs are
assigned sequentially and variable length encoded, so they shouldn't take up
much space most of the time.

------
chucknthem
Uber was an early adopter of QUIC and saw significant performance improvements
for its apps from it, especially in markets where mobile connectivity is poor
[https://eng.uber.com/employing-quic-
protocol/](https://eng.uber.com/employing-quic-protocol/)

~~~
the8472
With recent linux kernels most of the cited quic advantages are also available
for TCP, the exceptions are HoL blocking which is inherent in TCP (but how bad
it is depends on loss recovery, which is improving) and connection migration
which will come to TCP via MP-TCP.

Their article doesn't even mention against which kernel verison they're
comparing

> In the future, TLS1.3 will support 0-RTT, but the TCP three-way handshake
> will still be required.

This is outright wrong. With TCP you have fast open, which provides 0-RTT send
just like the TLS 0-RTT handshake.

~~~
treve
All of this is covered in the "Boxes" section in the article

~~~
the8472
I was sppecifically responding to the bullet list in the "Adopting QUIC"
section of the uber article. I don't think the general "middle boxes ruing
everything" argument addresses this.

BBR has very few if any middlebox problems. Neither do tail loss probe
improvements or any other sender side optimizations such as TCP_NOTSENT_LOWAT.
TFO may cause issues in corporate environments (works fine with my home
equipment) but fallback is easy. So I don't think this really "addresses" the
issue. Improved acking is not strictly needed if you use tcp timestamps for
RTT estimation and still ack improvements have been added to the kernel over
the years.

~~~
londons_explore
Fallback for TFO isn't easy because your request might not have been
idempotent.

Start running some HTTP requests multiple times and you can quickly see hard
to debug breakage.

------
snypox
Man, I’m just waiting for AWS load balancers to support HTTP2. Last time I
checked they still convert HTTP2 into HTTP1 for downstream endpoints.

~~~
dochtman
Why is that an issue for you? It seems like the downstream connection would be
on AWS' internal network, so HTTP 2 doesn't have as many advantages.

~~~
halfdan
HTTP/2 push comes to mind. Your services hosted behind an ALB won't be able to
make us of it if the connection is dropped to HTTP/1.1

------
divbzero
Great article, thanks. Just today I happened to see an Alt-Svc header from a
LiteSpeed server and was wondering what it was. I’ve (finally) signed up for
an LWN subscription.

------
chaz6
So far no mention of SCTP which would have been fine if people switched to
IPv6 (which more and more are every day). Instead we have this monster of a
protocol emulating it over UDP.

~~~
alex_duf
Wouldn't SCTP suffer from the ossification of middle boxes?

~~~
topranks
Yes absolutely.

Some of the people involved in the early QUIC development in Google had been
heavily involved in the SCTP work and blamed its lack of success on the
difficulty in getting firewalls, middleboxes (and the teams that manage them)
to accept a new IP protocol. So they wrapped QUIC in UDP.

~~~
lttlrck
SCTP can run over UDP. WebRTC does it.

------
pgjones
I took an early look at the performance (using Python) in November which may
also be of interest. [https://pgjones.dev/blog/early-look-at-
http3-2019/](https://pgjones.dev/blog/early-look-at-http3-2019/)

(That site is also served over HTTP/3 if you want to try it out).

------
bogomipz
The article states:

>"In HTTP/2, the single connection carries hundreds of streams. In this case,
when we lose one packet, "one hundred streams are waiting for that one single
packet"

Could someone elaborate on how this is worse if all of those streams are part
of the some client request? Am I missing something really obvious.

~~~
chrismorgan
The difference is that in HTTP/1.1 browsers tended to use up to six TCP
connections per origin. On a site that loaded many resources (a.jpg, b.png,
c.js, an API call, _& c._) from one origin, they were multiplexed across _six_
TCP connections, and so if a packet on one connection was lost, the other five
would be unaffected and could continue at full speed.

In HTTP/2, all those requests are multiplexed across only one TCP connection
per origin (each request becomes an HTTP/2 stream); so now when a packet is
lost, _all_ requests in progress are affected, rather than as few as ⅙ of
them.

If you only ever make one request at a time, this difference does not affect
you, because only one connection would be used under HTTP/1.1 as well.

But this case can make HTTP/2 significantly worse than HTTP/1.1 on low-quality
mobile networks.

~~~
the8472
They may all be affected, but with selective ACK that means the receiver will
still ACK most of the data, the server will notice that one packet was missing
via SACK, resend it along with even more new data and all you got is a larger
batch coming in 1RTT later, throughput isn't affected if your congestion
controller can distinguish spurious losses from congestion (as BBR does). The
problem only snowballs when future requests will only be made depending on
previous data.

~~~
mnarayan01
The other requests are still taking the latency hit.

~~~
the8472
Sure, but they were parallel requests in the first place, so in terms of wall
time you're still only taking the latency hit once. And if they're larger in
aggregate than the connection's BDP some of them would only have finished by
the time that it has recovered from the loss anyway.

So... it's complicated. I'm not saying that HoL is a non-issue and that TCP is
perfect. It's just that you're not eating the latency penalty N times and for
anything that is dominated by throughput rather than latency it's even less
relevant.

------
nirui
> HTTP/3 is expected to use two to three times more CPU time than the earlier
> versions for the same bandwidth consumption.

I wonder the "for the same bandwidth consumption" is based on what. HTTP/2
with TLS I guess?

------
csense
> new implementation of TLS in the kernel

This sounds like insanity to me. Is there an _old_ implementation of TLS?

