Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC – Will It Replace TCP/IP?

brighttalk.com

Post reply on HN
Print view View original

51–60 of 142 posts

Re: QUIC – Will It Replace TCP/IP?

#51

Post by ocdtrekkie »

mmm_grayons wrote: post #24
acheron wrote: post #18

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.

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

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.

Re: QUIC – Will It Replace TCP/IP?

#52

Post by _vbdg »

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...

Re: QUIC – Will It Replace TCP/IP?

#54

Post by mschuster91 »

jimktrains2 wrote: post #49
Spivak wrote: post #23

Earlier quoted context omitted.

Do keep in mind that "want" isn't exactly accurate. No IT team wants to spend any time/effort maintaining that crap, the business doesn't want to shell out for it either since it's expensive, and the ops team doesn't want yet another thing mucking with traffic. Yet we have one because it's required by law. Wanna take a guess at what companies make sure it stays required by law?

Please tell me what law applies to most companies that do this?

US banking and record-keeping laws IIRC.

Re: QUIC – Will It Replace TCP/IP?

#55

Post by kazen44 »

CameronNemo wrote: post #27
kazen44 wrote: post #8

Earlier quoted context omitted.

this. Many people here seem to not realize that TCP is used for much more then just http/https. Quick might be nice for web traffic, but i see little reason to use it as an underlay for BGP for instance.

I have not thought much about how BGP would react to QUIC as transport, would be curious to hear your thoughts on the matter.

for one, not having hardware acceleration makes quic very slow compared to TCP. This is especially a problem on firewalls, as they need to tear apart and reassemble tcp packets at line speed.

In terms of BGP and quic as a transport.

As far as i know, quic is not backwards compatible with TCP, and having two different transport protocols for the routing protocols that ties the internet together would be problematic in terms of migration.

Im not entirely up to speed in terms of how quick would handle MSS size, but this could pose a problem in some situations.

Re: QUIC – Will It Replace TCP/IP?

#56

Post by coder543 »

bregma wrote: post #46

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?

> 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/), 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.

Re: QUIC – Will It Replace TCP/IP?

#57

Post by mikepurvis »

drewg123 wrote: post #31
londons_explore wrote: post #6

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...

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…

It doesn't exist today, but there's nothing preventing a kernelspace implementation of sendfileq (or whatever), is there?

Re: QUIC – Will It Replace TCP/IP?

#58

Post by dullgiulio »

ocdtrekkie wrote: post #51
mmm_grayons wrote: post #24

Earlier quoted context omitted.

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

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 be…

On the other hand, a protocol that has been battle-tested and proven to work in the real world makes it much easier for a standards body to accept: there is less risk of making a standard that nobody uses.

The important point is not to make proprietary deviations to the standard. Of course, Google is guilty here (Chrome-only web service, mostly) but when it comes to network protocols they haven't behaved badly, especially when others were pushing for HTTP/2 without TLS and other harmful ideas...

Re: QUIC – Will It Replace TCP/IP?

#59

Post by rakoo »

_vbdg wrote: post #52

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]? Diffe…

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

Re: QUIC – Will It Replace TCP/IP?

#60

Post by dragontamer »

rakoo wrote: post #59
_vbdg wrote: post #52

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]? Diffe…

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

> nothing is worse off if it is encrypted

Performance and power consumption of low-end devices.

Post reply on HN