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

81–90 of 142 posts

Re: QUIC – Will It Replace TCP/IP?

#81

Post by bobbiechen »

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

This is one of the examples of what not to do from "End-to-End Arguments in System Design" (Saltzer, 1984) [1]:

The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible.

Applications vary in what needs encryption and how that encryption is implemented, so it is better to leave this to them to implement; otherwise, all applications may suffer the cost of your protocol's encryption implementation without getting the actual encryption that they need.

[1] http://pages.cs.wisc.edu/~bart/739/papers/end-to-end.pdf

Re: QUIC – Will It Replace TCP/IP?

#82

Post by _vdpp »

marcosdumay wrote: post #21
kazen44 wrote: post #9

Earlier quoted context omitted.

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

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.

Endpoint supervising isn't always an option. As more IoT devices start to use TLS connections to phone home, a network MITM may be the only way to see what they're reporting. Breaking TLS isn't just something that Big Brother would want to do.

(This is assuming they aren't using pinned certs baked into their firmware, anyhow. I don't have good data on which manufacturers/devices are doing this, but somebody else might know.)

Re: QUIC – Will It Replace TCP/IP?

#83

Post by joshuamorton »

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…

How does the protocol Google chooses to use on its private intranet at all put pressure on the IETF to accept that protocol as a standard?

The chrome argument at least sort of makes sense, but I really don't get how the network transport that literally no one but Google can see threatens IETF irrelevance.

Re: QUIC – Will It Replace TCP/IP?

#84

Post by vasilvv »

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

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

It's a "reasonable default", in the sense that it normally works quite well, and is easy to implement. The dangerous thing about congestion control is that it's really easy to get it wrong and not notice (as noticing requires performance testing and monitoring).

Google QUIC uses BBR on the server side. I wrote the initial version of said BBR implementation, and it took a lot of effort to get it to a production-ready state, so I would not generally recommend writing BBR from scratch. CUBIC is much simpler than BBR, but is also prone to subtle bugs like [0].

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

I'm actually curious what use cases you have in mind. TLS definitely does not cover 100% of all possible cases, but I've seen a surprising number of cases where people rolled their own thing when using (D)TLS would have just worked.

[0] http://bitsup.blogspot.com/2015/09/thanks-google-tcp-team-fo...

Re: QUIC – Will It Replace TCP/IP?

#85

Post by tialaramex »

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

QUIC does use TLS, but since TLS sits on top of TCP and QUIC replaces TCP entirely they wire TLS directly into their protocol rather than it resting on top as it does with TCP.

Technically this was fairly complicated to do, but cryptographically nothing much really changes, except that now more things are encrypted.

Now, if your TLS implementation just presents as a shim layer between a TCP port and your socket code then this may mean a significant rewrite, but again that's not about cryptography it's just an engineering problem.

Re: QUIC – Will It Replace TCP/IP?

#86

Post by falcor84 »

pawalt wrote: post #64
rakoo wrote: post #59

Earlier quoted context omitted.

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

I don't see how this refutes the argument. These proxies and firewalls could just have a copy of the decryption key, no? (And if whoever is setting them up doesn't have access to the key, then they probably shouldn't be inspecting the packets anyway)

I'd say that the bigger argument against "nothing is worse off if it is encrypted" is that this takes precious time.

Re: QUIC – Will It Replace TCP/IP?

#87

Post by falcor84 »

hackmiester wrote: post #77
rakoo wrote: post #59

Earlier quoted context omitted.

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

If everything on the Internet ends up encrypted, I will call you to troubleshoot the problematic SIP calls. ;) eta: Or at least the ones where one end is a $30 phone someone bought off of Amazon that has no vendor support and the device has no CLI or debug tools available.

Please sign me up for this future where every phone has to support end-to-end encryption in order to connect to the network :)

Re: QUIC – Will It Replace TCP/IP?

#88

Post by xakahnx »

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…

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.

Re: QUIC – Will It Replace TCP/IP?

#89

Post by jupp0r »

moomin wrote: post #61
rakoo wrote: post #59

Earlier quoted context omitted.

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

The thing is, if you run Istio there’s a standard setting for getting it to do the TLS for you. Indeed, half the features of istio wouldn’t work if you did the TLS yourself. So you kind of need plaintext protocols even if you’re only running them internally within a single (logical) machine.

Istio would not only do TLS, but would also do QUIC for you in the scenario you describe.

Re: QUIC – Will It Replace TCP/IP?

#90

Post by rektide »

_jal wrote: post #14

> Will It Replace TCP/IP? No. This as been another episode of "simple answers to stupid questions".

Should it though?

Quite probably!

I see two main ways to look at this question: will QUIC replace TCP as a go to protocol for developing atop of? The other interpretation is, will QUIC replace all TCP ever written? No, indeed, likely not.

Post reply on HN