
Can QUIC match TCP’s computational efficiency? - simonpure
https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency
======
wmf
_Intel Core m3-6Y30 ... USB Gigabit-Ethernet adapter_

Danger, non-server hardware detected.

 _we limited the CPU’s clock from 2.2GHz down to 400MHz_

Danger danger, system imbalance approaching critical levels; please evacuate
to a safe distance.

~~~
emmericp
The hardware selection and test setup is questionable, yeah. But downclocking
the CPU is pretty standard for many benchmarks like that. Would have been
better to evaluate the effects of CPU frequency changes separately. But
there's nothing wrong with downclocking in general if you want to evaluate
effects of CPU bottlenecks when you don't have high-speed links available.

~~~
dirtydroog
But is there any point it profiling on a laptop? Thermal throttling is a
bigger issue than on a desktop, where even there you have to faff about with C
states if you want somewhat believable stats.

------
enitihas
Disabling TCP offload to hardware makes this comparison much less useful. TCP
has hardware offload right now, and QUIC will take years to get at that level.

~~~
PudgePacket
If I understand correctly the whole point of QUIC is to not be in hardware
level. That's why QUIC exists, because TCP can't be changed because it is
baked in at such low, fundamental levels.

~~~
thwarted
It's not that TCP can't be changed, it's that it's the only option that works.

TCP is baked into firmware on edge routers and firewalls and wifi devices that
are beyond the period of support and the companies that created them aren't
interested in supporting them or have gone out of business.

There are other protocols in layer 4 that could have been used that are better
on some workloads than TCP, but TCP and UDP were the only things
configured/supported; many firewall default configurations filter out things
they don't recognize so anything new is a non-starter. And because of the
perception of responsibility when it comes to networks, if I support a new
protocol and you can't connect to it because there's older devices between you
and me, it becomes my problem.

~~~
JoeAltmaier
So much this. Its ossified so far that if your DHCP packet isn't padded in
just the right way, some firewalls will block it. Somebody mis-read the RFC
and put in some rule, and now many Enterprise firewalls do this. Sigh.

Anyway, anothing not 'normal' is being filtered out somewhere. We even (at one
startup) considered tunneling RTP through HTTP! My god.

------
kev009
Their implementation of congestion control (reno) is 85 lines including a big
copyright block comment. That's cute but it's completely incomparable to the
transmission intelligence in the Linux TCP stack, especially for the line of
business Fastly is engaged in (maybe the technical staff doesn't even know
what that is due to poor leadership?) in trying to get goodput to devices
across congested and channel lossly links. This article is highly comical.
I've yet to be impressed by fastly aside from offloading itself to retail
investors with another nonsensical IPO.

~~~
vardump
They use Reno? I don't know what's their business, but hopefully it doesn't
involve lossy links like mobile data, which often drop packets even when
uncongested...

Reno can work nicely for low packet loss links, though.

~~~
esaym
Interestingly, I've found TCP_Illinois[0] to do the best on lossy links. Case
in point was a cable modem isp I used for about a year once. The upstream was
rated at 10mbs, but it would bounce between 1-5mbs. Using a UDP test, I
noticed about a 0.2-1% packetloss on upstream only. I tried all the tcp algos
in linux. Illinois did the best. And by "best" I mean it would hold a steady
speed between 8-9mbs while others would get quite jumpy at times (or just
never go above 5mbs). I'm limiting upstream to 9mbs via fq-codel as well. I've
always found it strange Illinois is never brought up anywhere. It even has
tuneable parameters too.

[0]:[https://en.wikipedia.org/wiki/TCP-
Illinois](https://en.wikipedia.org/wiki/TCP-Illinois)

~~~
vardump
Not questioning your conclusion; out of curiosity, did you also measure
latency?

You could get very close to maximum possible just by massively delaying &
coalescing ACKs. In other words nearing blind transmission without caring
about packet loss at all.

But latency could get pretty bad!

~~~
esaym
Not really. Was just using max average upload speed at. Test was done on my
laptop, my firewall uses fq-codel so max bufferbloat delay would be below 50ms
in most cases.

~~~
vardump
Sorry, should have been more specific. I wasn't talking about latency
bufferbloat induces in _other_ streams. But extra latency in any stream with
packet loss.

I meant stream of the receiving party would effectively block on any lost
packet. You can't read past what you don't have yet.

Imagine a stream that consists of 10 packets, and for simplicity that each
packet takes a second to send. (Real life scenario would be about several
orders of magnitude more packets and similarly shorter packet transmission
times.)

You receive packets 1 and 3-10. Thus in one second the application can see
data from packet 1. But application's read is going to block until you also
receive packet 2. Reception of packet 2 can't happen until 8s is spent
receiving packets 3-10 and additional 1s resending 2 (plus whatever it took to
send the ACK).

So data from packet 2 would be 9s late from receiving application's point of
view.

Bulk transfers would approach maximal possible transfer rate because sender
lost no time waiting for ACKs, but this would be pretty bad for something like
remote desktop or streaming video.

No sane _general purpose_ network stream protocol would implement this policy
for obvious reasons. But you'd sure get high bandwidth for file transfers!

------
aduitsis
All well and good, but TCP has been around for decades and there are top
quality network stacks providing TCP sockets on top of almost anything that
can run on a CPU. Is there a (preferably BSD-licensed) QUIC piece of code that
can be retrofitted where the TCP stack of an OS used to be? Or are we going to
start linking a piece of the network stack into the applications?

~~~
PudgePacket
It's intentionally userspace to avoid ossification.

~~~
simias
What you call "ossification" others would call "stabilization" and
"standardization". Not to say that the inertia of (some) kernels is not
excessive sometimes but I'm not a fan of the "fuck it, we'll do it in
userland" attitude. That creates big, opaque application blobs that nobody
understands and knows how to debug with standard tools.

I feel like Google in particular loves to do that stuff because while they
control the internet and the browser, they don't (yet) control the OS so they
have a very strong incentive to push stuff up in order to retain control. They
don't have to ask anybody to add things into Chrome, they have to get third
parties on board to extend the kernels (outside of Android at least).

~~~
toast0
What's extra frustrating is that Google does control the OS for Android, but
they don't use that to make TCP better.

Things they could do:

a) enable MTU blackhole probing, so people behind dumb networks can talk to
servers that don't artificially reduce MSS. Apple has a pretty agressive
implementation of MTU probing, and it's very effective.

b) put in hooks for userspace congestion control. Make sending faster (or not)
with updates from Google Play services (or whatever)

c) the article mentions sending fewer acks. That could probably be done in TCP
too --- it makes sense to make that a setting that they could roll out.

d) some sort of name and shame program for bad networks / bad network devices.
It's 2020 and people running PPPoE and sending MSS 1480 when it's really 1472
should be ashamed of themselves, but big companies just set their servers to
MSS 1460 and call it a day. :(

------
campuscodi
Shouldn't we be waiting for QUIC to pass IETF before we go diving into
performance benchmarks?

~~~
wmf
Given that performance is one of the motivations for QUIC, benchmarking needs
to be done at every stage of development. Also, QUIC is close to being
finalized so I don't think it's too premature.

------
bullen
Everything past HTTP 1.1 has been a waste of time and energy.

Everyone involved in making these protocols (HTTPS/WebSocket/HTTP2/HTTP3/etc.)
are just victims of:

“It is difficult to get a man to understand something, when his salary depends
upon his not understanding it!” - Upton Sinclair

~~~
acdha
Can you back that up? HTTPS is a requirement for doing anything securely. It
seems like a lazy troll to just dismiss it with no explanation. Similarly,
even a cursory amount of research into WebSockets or HTTP/2 will turn up real
engineering problems which are solved by those protocols. Can you address any
of them?

~~~
bullen
I hash the password with a one-time server salt in the client (instead of
HTTPS) and I use simple HTTP comet-stream for real-time data (instead of
WebSockets):

[http://fuse.rupy.se](http://fuse.rupy.se)

HTTP/2 has the TCP head of line problem which makes it completely useless.

HTTP/3 is trying to be more nimble, but it's a protocol! Ossification is a
_feature_ of protocols; for TCP it allows the backbone to evolve without
everyone re-implementing everything over and over again at the edges!

The solution is to make TCP like UDP instead, by allowing sockets to not
resend missed packets.

Another real solution is to remove the network kernel on linux.

