Live data from Hacker News

QUIC – Will It Replace TCP/IP?

brighttalk.com

91–100 of 142 posts

Re: QUIC – Will It Replace TCP/IP?

#91
post #84
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…

If you are in a situation where you can have a shared key, TLS, with it's asymmetric handshake is probably overkill.

Re: QUIC – Will It Replace TCP/IP?

#92

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.

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

Re: QUIC – Will It Replace TCP/IP?

#94
post #64
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.

not to mention, that while encryption is cheaper than it was, it still isn't free. And managing certificates and CRLs, while much easier than it used to be is still not trivial, especially on an internal network or localhost.

Re: QUIC – Will It Replace TCP/IP?

#95
post #36
post #16

Earlier quoted context omitted.

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.

> 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

lots of games use UDP, lots of games use TCP. I could easily see games using QUIC. If you include mobile games, I doubt most games have the budget to tune a UDP stack.

Re: QUIC – Will It Replace TCP/IP?

#96
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…

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

Re: QUIC – Will It Replace TCP/IP?

#97
post #64
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.

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

Re: QUIC – Will It Replace TCP/IP?

#98
post #84
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…

Thanks for the information; your link was an interesting read.

> I'm actually curious what use cases you have in mind.

TLS certs can be a hassle for peer-to-peer type stuff. I'm currently working on a project that does encrypted file transfer between two people and uses a PAKE instead, because I can encode 32 bits of random data in 3 words and that's plenty versus having to deal with public-key infrastructure or dealing with cert files/large blocks of base64. I don't want to run a CA for this and a self-signed cert doesn't verify identity. I certainly don't want to trust some other CA. SSH sort of solves this problem by keeping a known_hosts file with which IP has which key. Unfortunately, that's only good after first contact. People's IPs also change whereas those of servers usually don't. Finally, I share Colin Percival's concerns about the quagmire of backwards compatibility that TLS has become: https://news.ycombinator.com/item?id=16751358

Edit: What's app also moved from TLS to a protocol based on Noise. I believe the rationale was that it's a much cleaner, ground-up implementation rather than being an evolution of something from the '90s. It's analogous to C++: you can do just about anything with it because it has so many features, but they were bolted-on piecemeal. This also means there are a half-dozen ways to do any given thing and even more ways to do something wrong, so there are stylistic inconsistencies on teams beyond "tabs vs. spaces".

Re: QUIC – Will It Replace TCP/IP?

#99
post #96

Earlier quoted context omitted.

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

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

[deleted]

Re: QUIC – Will It Replace TCP/IP?

#100

Earlier quoted context omitted.

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

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.

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), "Pervasive Monitoring is an Attack". Protocols that enable interception are broken and will be replaced with protocols that do not.

Post reply on HN