
QUIC – Will It Replace TCP/IP? - RMPR
https://www.brighttalk.com/webcast/663/382768
======
mmm_grayons
Nah, I think it won't.

1\. Not everything needs encryption, so QUIC's built-in TLS doesn't always
make sense.

2\. Not everything that needs encryption needs TLS specifically. TLS is not a
one-size-fits-all solution.

These reflect the fact that QUIC is a transport protocol for the WWW more than
a TCP replacement.

By the way, does anyone know why QUIC specifically put NewReno as its official
congestion control [0]? Different environments benefit from different
algorithms so I don't see why.

[0]: [https://tools.ietf.org/html/draft-ietf-quic-
recovery-12#sect...](https://tools.ietf.org/html/draft-ietf-quic-
recovery-12#section-4)

~~~
rakoo
1) Not everything needs encryption, but crucially, nothing is worse off if it
is encrypted. Encryption is either useless or better, so why not put it
everywhere by default ?

2) QUIC explicitely doesn't use TLS but something different, so indeed, not
everything needs TLS

~~~
pawalt
"nothing is worse off if it is encrypted" is a pretty big oversimplification.
Layer 7 proxies and firewalls frequently use packet data to make more
intelligent decisions about where to route packets, whether to drop packets,
whether to modify packets, etc.

~~~
kevin_thibedeau
These are the same agents that prevented SCTP from being usable outside of
private networks. We need to stop catering for them.

------
suncore
I think it might actually succeed to replace TCP. There are a bunch of
benefits. There is a great video here about it that you should also watch
before passing summary judgement:
[https://www.youtube.com/watch?v=idViw4anA6E](https://www.youtube.com/watch?v=idViw4anA6E)

~~~
RMPR
On the flip side there are no multi path implementation for QUIC while Multi
Path TCP is being merged since Linux 5.6[1], just for this I think it's won't
be simple as your comment may lead to think.

[1]:
[https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Starts-
Multipath-TCP)

------
bregma
So, something layered on top of UDP layered on top of IP is going to replace
IP?

Maybe the marketing department needs to hire someone who knows the
fundamentals to write the headlines?

~~~
coder543
> Maybe the marketing department needs to hire someone who knows the
> fundamentals to write the headlines?

What's that quote about throwing stones while living in glass houses?

The headline says nothing about replacing IP. It's talking about replacing
"TCP/IP", which is neither "TCP or IP" nor "TCP and IP".

In this case, it's asking whether TCP/IP will be replaced with a protocol
(QUIC) that is built on UDP/IP.

IP is definitely still involved.

As with the classic XKCD reference for this situation
([https://xkcd.com/927/](https://xkcd.com/927/)), I find it very unlikely that
it will "replace" TCP/IP in the sense of TCP/IP disappearing altogether, but
it certainly stands a chance of replacing TCP/IP in many specific applications
that test it and find it beneficial.

~~~
takeda
TCP/IP != TCP

TCP/IP is a name for the Internet Protocol Suite[1], which UDP ironically is
part of.

If someone talks about one protocol replacing another they should be aware of
this distinction, and this title makes me believe the author doesn't know what
he is talking about.

[1]
[https://en.wikipedia.org/wiki/Internet_protocol_suite](https://en.wikipedia.org/wiki/Internet_protocol_suite)

~~~
coder543
That's not the _singular_ definition of TCP/IP, as you're seemingly so intent
on believing.

TCP and IP are separable[1], so it logically makes sense to have "TCP/IP" mean
that you're using them together, rather than meaning some arbitrary suite of
protocols that may have nothing to do with TCP specifically.

Cloudflare, which is obviously a major industry player, defines TCP/IP the
same way that the webinar authors and I both normally define it.[2] Cloudflare
also (logically) refers to UDP/IP as a concept,[3][4] which further supports
the notion that TCP/IP is not singularly referring to the whole internet
protocol suite.

I understand that people do sometimes use TCP/IP to refer to the internet
protocol suite as a whole, including UDP. I've seen it before. That doesn't
make it the only (or most logical) definition of the term. It's certainly not
the definition the authors of this webinar intended you to use when reading
the title.

In the tech world, _many_ terms are overloaded with multiple definitions. This
isn’t an uncommon situation by any means.

> this title makes me believe the author doesn't know what he is talking about

Because the authors are choosing to use a different common definition of
TCP/IP, you think _they 're_ the ignorant ones because _you_ don't know that
common definition? Or because you're only willing to read the title in the way
that makes it seem the most nonsensical?

I left my first reply because the author of that comment was being so
unnecessarily insulting to the authors, and now you're following up with
similar snark, and posting it in multiple places on this topic, when there is
no evidence to support that your use of the term is the only valid use of the
term.

[1]: [https://superuser.com/questions/449703/must-tcp-use-
ip](https://superuser.com/questions/449703/must-tcp-use-ip)

[2]: [https://www.cloudflare.com/learning/ddos/glossary/tcp-
ip/](https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/)

[3]: [https://www.cloudflare.com/learning/ddos/glossary/user-
datag...](https://www.cloudflare.com/learning/ddos/glossary/user-datagram-
protocol-udp/)

[4]:
[https://www.cloudflare.com/learning/ddos/glossary/internet-p...](https://www.cloudflare.com/learning/ddos/glossary/internet-
protocol/)

~~~
bawolff
I don't think your cloudflare link supports your position. CF talks about "The
TCP/IP relationship..." \- in context they are clearly referring to tcp and ip
as two separate nouns, not as a single noun to refer to the internet suite.
Context can modify word meaning-using that as an example really doesn't say
anything about the term "tcp/ip" in general.

Fwiw Wikipedia also thinks tcp/ip means the protocol suite
[https://en.wikipedia.org/wiki/Internet_protocol_suite](https://en.wikipedia.org/wiki/Internet_protocol_suite)
(edit: i guess other person already said that, i didnt notice)

Edit2: otoh, i think this whole argument is pedantic and its clear what the
original article meant.

~~~
bregma
If it was clear, after reading the headline I would not have assumed that QUIC
was proposed to replace the internet protocol (IP) for the internet.

The title "QUIC -- Will it replace TCP?" would be accurate and correct and
contains everything both necessary and sufficient to describe the article.
Adding in unrelated extras, like QUIC replacing IP, conveys additional and
incorrect information. It muddies what the article is about.

Calling out unclear and misleading communications is not being pedantic.
Clarity is the most fundamental aspect of good and effective communications.
The headline writer does not need an apologist, they need to expand their
knowledge of the subject they are writing about.

------
darkr
Historically, some of the big problems of running UDP-based services over the
internet are related to source spoofing, used in reflection/amplification
attacks etc (looking at you, DNS/NTP), which is possible as very few providers
carry out source address validation on egress.

Looks like QUIC has a nice solution to this, making the impact of source
spoofing similar to that of TCP, give or take a few CPU cycles:
[https://jacobianengineering.com/blog/2016/11/1543/](https://jacobianengineering.com/blog/2016/11/1543/)

------
davewritescode
They're specifically doing QUIC as a way to move TCP to up into the
application space so they can iterate more quickly. Ideally, a lot of these
concepts could be adopted into TCP stacks eventually.

~~~
swiley
That’s pretty annoying as a user honestly, websockets are difficult enough to
deal with.

------
londons_explore
QUIC has a substantial CPU overhead, due to lack of hardware or kernel
acceleration.

QUIC deployed worldwide might cost us a power station or two...

~~~
drewg123
In estimates I've done, in its current un-accelerated state, it would at least
triple the CPU cost per byte served on our CDN workload. We basically lose:

\- sendfile

\- ktls

\- TSO

Its like stepping into a time machine and going back to the mid 90s. To send
data with QUIC, we have to get byes from kernel into userspace, encrypt them
in userspace, and then write them back to the kernel, where they travel down
to the NIC an MTU at a time. Ugh.

~~~
xakahnx
One of the consequences of TCP being implemented in the Linux kernel is that
companies were implicitly motivated to open source any performance or
efficiency improvements to their TCP stack. Are any companies collaborating to
improve QUIC efficiency issues in open source? The issues are well understood
among at least the big cloud providers.

~~~
RMPR
Quic is being standardized in the IETF there are a couple of companies
involved:

\- Cloudflare

\- Facebook: They already use QUIC for some of their products, or at least
it's a pretty sensitive piece of software on their architecture because they
ask to report bugs to the bug bounty program[1]

\- Microsoft

\- Nginx

\- Google

\- NetApp

\- Mozilla

\- Traffic Server

\- Litespeed

\- Fastly

\- F5

\- Apple

Amazon is very quiet about all that, but they are probably looking into it.
So, it is pretty backed up. If you take a look at their workgroup homepage
(quicwg.org) you will see a couple of open source implementations, some from
those same companies.

[1]:
[https://github.com/facebookincubator/mvfst/blob/master/READM...](https://github.com/facebookincubator/mvfst/blob/master/README.md)

------
crazygringo
Better framing:

Will it replace HTTPS over TCP? Maybe. Mostly. Eventually. (Hopefully?)

Will it replace TCP for other purposes? Of course not.

~~~
Rusky
QUIC no longer includes HTTP, so "of course not" is a bit strong. It's easily
applicable to a lot more scenarios than HTTPS over TCP.

------
downerending
My bank account awaits a whole new raft of security problems for me to be paid
to support/fix.

------
xxpor
HTTP isn't the only L7 protocol.

~~~
jchw
Nothing prevents you from using QUIC as a replacement for TCP AFAIK - on the
surface it seems like it would be potentially useful for more applications
than HTTP. May even be a decent option for video games and other things that
need somewhat lower latency and wish to avoid head-of-line blocking.

~~~
chungy
> May even be a decent option for video games and other things that need
> somewhat lower latency and wish to avoid head-of-line blocking.

Most video games already use UDP

~~~
jchw
Sure. In fact most video games use some kind of networking middleware. But
tbh, a lot of them are not so great because a lot of concerns get mixed
together, and if you want a reliable connection with congestion control you
likely will just open a TCP connection somewhere with a different protocol.

For the hobbyist world, this option as a low level transport is not so bad
imo. Like as a replacement for ENet which does not have IPv6 support today
seems reasonable.

------
anfilt
The one thing I like about QUIC being more wide spread is that it is making
network operators treat UDP traffic more fairly.

However, I don't see it replacing TCP, and if anything it's just an other tool
to use.

------
tyingq
They would need some incentives to make it work in big orgs that have MITM
and/or restrictive firewalls.

~~~
JoshTriplett
Ideally those incentives would be combined with disincentives for those
organizations to continue breaking the web. A combination of the two seems
more likely to be successful than either alone.

~~~
kazen44
tcp != the web.

Also, most firewall don't break TCP, they break HTTP(S) because they want
levels of control.

~~~
marcosdumay
Well, they break TLS. That's almost as broad as breaking TCP.

And it's because they want levels of control on the least affordable place.
They wouldn't need to break anything if they added the supervising software to
the endpoints.

~~~
ocdtrekkie
It's odd you refer to endpoints as being the "more affordable place". Because
running monitoring software on 5,000 PCs plus management infrastructure and
software updates is a lot more "expensive" than having a single purpose-built
box on the border between the network and the wider Internet.

Now, I get that QUIC's developers live in a zero-trust/BeyondCorp model, and
expect everyone else to too, and with COVID-19, a lot of businesses are
suddenly having to look at thinking that way, it's far from how most companies
work at present. And having a single box handle filtering and monitoring is
actually the most affordable place to put it. ;)

~~~
marcosdumay
> It's odd you refer to endpoints as being the "more affordable place".

The endpoints afford monitoring. The middle of the network does not afford it,
so you are fighting the system and it is certain that you will break stuff.

~~~
ocdtrekkie
The middle of the network has always afforded monitoring, until certain
companies with a vested interest in interfering with said monitoring started
pushing the Internet to not afford it.

Middleboxes are the system, and protocols that deliberately try to block
inspection are fighting it and trying to break stuff.

~~~
JoshTriplett
_Users_ have a vested interest in not having their connections MITMed. End-
user security is not an "agenda" or a "vested interest". And portraying MITM
attacks and similar security holes as "inspection" is spin.

See also RFC 7258
([https://tools.ietf.org/html/rfc7258](https://tools.ietf.org/html/rfc7258)),
"Pervasive Monitoring is an Attack". Protocols that enable interception are
broken and will be replaced with protocols that do not.

~~~
ocdtrekkie
I disagree. Because when clients get phished or infected by malware that
bypassed my inspection boxes, the end user was harmed. For me to buy that we
shouldn't MITM for security reasons, you'd need to convince me that cloud
providers on the other end were mildly successful at preventing malware,
scams, and fraud.

And they're not. Google, Amazon, Microsoft, etc. have failed to keep the
Internet safe. And when they fail they hide behind liability shields like
Section 230. So it falls on IT staff, more often than not, to filter, block,
and intercept where Big Tech has demonstrated inability to do so.

~~~
JoshTriplett
TLS is now pervasive. Certificate Transparency prevents CAs from aiding
interception. http is now explicitly flagged as "insecure". Browser vendors
have had a major part in those improvements to Internet security. (So have
many other parties, such as Let's Encrypt for removing cost as an excuse for
not using TLS.)

People trying to make protocols more secure don't need to convince you, they
just need to make your job as hard as possible until most users reject what
you're offering.

We need a dozen more ideas like Certificate Transparency. We need pervasive
end-to-end DNS security, with unencrypted DNS flagged as insecure. We need a
means of preventing DNS servers from altering the DNS records of sites they
aren't authoritative for. We need browsers to all agree to explicitly flag
connections as insecure when they chain to a locally installed certificate, in
a way that can't be hidden without rebuilding from source.

And this isn't a purely technical problem, either. We also need legal support
to review regulations in certain regulated industries and demonstrate well-
supported ways to fulfill those regulations without breaking security (e.g.
"if you do XYZ to log the time and endpoints of connections but don't actually
MITM their traffic, it's reasonably well-established that you're fulfilling
ABC regulation"). We need lobbyists to change regulations incompatible with
secure protocols. We need designers to make security as usable as possible,
because poor usability is a security problem.

------
jasoneckert
I don't think it will ever replace TCP/IP.

But even if it does, the replacement won't be QUIC.

------
ChrisMarshallNY
"Betteridge's law of headlines" applies, I suspect...

We're having difficulty getting IPv6 up and going, and that's 100% supported
by everyone.

------
doublerabbit
As it seems like we won't be rolling out IPv6 anytime soon, why would this
replace TCP?

~~~
EdSchouten
Unlike IPv6, QUIC requires (almost?) no buy-in from network operators/ISPs.

~~~
Carpetsmoker
Which is pretty much the entire point of QUIC, since updating gazillions of
network appliances to support newer versions of TCP is rather hard and will
take decades, if not longer. With QUIC, that's no longer needed.

------
_jal
> Will It Replace TCP/IP?

No.

This as been another episode of "simple answers to stupid questions".

~~~
takeda
Just the title itself shows author has no idea what the hell he is talking
about TCP/IP != TCP

TCP/IP refers to the entire stack that Internet is build on, the UDP is
actually part of TCP/IP (it was added later for use cases where low latency
was important, like telephony). He probably meant just TCP, but that's still
"no".

~~~
emmelaich
TCP/IP metonymically refers to IP.

My guess is that just saying "IP" is too short.

(And ambiguous - tee hee)

------
spdegabrielle
Nope

------
chirau
Quick answer for QUIC...

No, it won't replace TCP/IP

------
OrangeMango
I've been told in the recent past that there is so much old internet
infrastructure equipment that only knows UDP and TCP that any other protocol
will fail to meaningfully catch on. This equipment will drop anything that
isn't TCP or UDP and until it's replaced you will have a lot of trouble.

~~~
matthewmacleod
QUIC operates over UDP. That’s really why this question is worth asking.

~~~
m0th87
Yes, though this is arguably a big reason why SCTP didn't take off, which is
similar to QUIC in a lot of ways (there is SCTP over UDP, but it was a second
class citizen until WebRTC.)

------
acheron
I see no problems in Google continuing to replace basic protocols. In fact,
why not get rid of the open Internet altogether and just use all Google
products all the time? It'll be like the good old days of AOL.

~~~
mmm_grayons
The fact that it originated in Google doesn't make it some kind of proprietary
protocol. It's subject to the usual IETF process, just like others, and is a
public draft: [https://tools.ietf.org/html/draft-ietf-quic-
transport-22](https://tools.ietf.org/html/draft-ietf-quic-transport-22)

~~~
ocdtrekkie
My concern with Google engaging standards bodies is that if Google is the
monopoly on all sides, the standards body has little choice but to eventually
accept it: Google didn't wait for an IETF standard to implement it in both
their monopoly-scale browser and their monopoly-scale services and then
declare that a large portion of Internet traffic was now already using QUIC. I
am aware there have been some revisions between gQUIC and QUIC as being
prepared for standardization, but it seems unlikely the IETF has the ability
to say, discourage shifting a huge portion of Internet traffic to a Google-
based protocol.

Under these sorts of arrangements, standards bodies have little choice but to
rubber stamp the company's interests or face irrelevance. On the HTML/JS side,
we often see the same problem with the W3C.

The web's baseline protocols are slowly being replaced by protocols designed
to favor the interests of a single company without enough meaningful checks on
that. I do not really think it's an IETF/W3C problem though, so much as a
economic power one.

~~~
anfilt
The IETF has shown it's self less prone to rubber stamping. W3C is a whole
other case. Problem is unlike IETF which anyone can chime in on a standard.
W3C is members only and most the members are companies. Most these companies
use googles web browser so they just kinda go along with it.

~~~
tialaramex
The W3C was conceived from the outset for corporations. It even has the word
consortium in its name. Personal membership was added much later.

It's actual normal for Standards Organizations to look like this. If anything
by their standards the W3C is very liberal. ISO's members are UN member states
for example. Want a delegation to ISO to disagree with how an ISO standard
works? Create a sovereign entity, seize control over an appreciable amount of
the world and force other sovereign entities to accept you as an equal or you
can't. The SI units are controlled by Conférence Générale des Poids et Mesures
which only has countries as members - some countries don't even get full
membership. Don't like the kilogram? Unless you are literally a country too
bad.

The IETF is the far outlier, it might even question whether it is indeed a
Standards Organization at all. After all it doesn't have any members, (the
Internet Society has members but the IETF does not) and so perhaps its
"standards" are only "standard" the way English is standard: a bunch of loose
conventions, some honoured more consistently than others. Nobody pretends
there's a "Standards Organization" for English after all.

