Live data from Hacker News

QUIC – Will It Replace TCP/IP?

brighttalk.com

21–30 of 142 posts

Re: QUIC – Will It Replace TCP/IP?

#21
post #9

Earlier quoted context omitted.

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.

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.

Re: QUIC – Will It Replace TCP/IP?

#23
post #9

Earlier quoted context omitted.

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.

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

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?

Re: QUIC – Will It Replace TCP/IP?

#24
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

Re: QUIC – Will It Replace TCP/IP?

#25
post #16
post #4

HTTP isn't the only L7 protocol.

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.

Seeing a BGP implementation running over QUIC would be the end game, right? There is so mug network hardware which will not be replaced for decades, so people would have to get started now if they wanted to completely make TCP redundant in the not so near future.

Re: QUIC – Will It Replace TCP/IP?

#26

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.

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

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

Re: QUIC – Will It Replace TCP/IP?

#27
post #8
post #4

HTTP isn't the only L7 protocol.

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.

Re: QUIC – Will It Replace TCP/IP?

#28
post #11

Earlier quoted context omitted.

The corporate firewalls I'm talking about do often break UDP. Because chrome races QUIC/UDP with HTTP(S)/TCP, the big corps are often unaware it's broken. Chrome works around it.

So it doubles the traffic?

A good chunk of them block UDP outbound entirely, so the additional traffic never hits the public internet.

Re: QUIC – Will It Replace TCP/IP?

#30
post #11
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.

The corporate firewalls I'm talking about do often break UDP. Because chrome races QUIC/UDP with HTTP(S)/TCP, the big corps are often unaware it's broken. Chrome works around it.

People with corporate firewalls should also be limiting the unruly behavior of web browsers using group policy. For instance, in my environment, regardless of your browser of choice, QUIC is disabled. (As is DoH and various other recent/trendy things browsers are doing.) We also disable all but a small whitelist of approved browser extensions.
Post reply on HN