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

QUIC and the end of TCP sockets

codemia.io

Post reply on HN
Print view View original

31–40 of 83 posts

Re: QUIC and the end of TCP sockets

#31

Post by lxgr »

jauntywundrkind wrote: post #11
superkuh wrote: post #7

QUIC would be the end of the free internet if it ever "took over" but luckily it won't. It's not built to do so, it's only built for corporate use cases. QUIC implementations do not allow for anyone to connect to anyone else. Instead, because it was built entirely with corporate for-profit uses cases in mind and open-washed through the IETF, the idea of a third party coporation having to authenticate the identity of…

There's a fairly far a long draft for replacing webrtc's SCTP with QUIC for doing p2p work. It doesn't seem to have any of these challenges, seems to be perfectly viable there for connecting peers. https://github.com/w3c/p2p-webtransport Alas alas, basically stalled out, afaik no implementation. I wish Microsoft (the spec author) or someone would pick this back up.

WebRTC wraps SCTP in DTLS, so the "great challenge of encryption" has never been a problem there.

It just uses self-signed certificates, which is maybe conceptually slightly clunky compared to "pure" anonymous TOFU, but allows reusing existing stacks.

Re: QUIC and the end of TCP sockets

#32

Post by lxgr »

neilalexander wrote: post #30
lxgr wrote: post #20

Earlier quoted context omitted.

> Why do the hard work if the same thing can be done by the kernel, or even by the card itself? How would you swap out the TCP congestion control algorithm in an OS, or even hardware, you don't control? > Drown other applications for your own benefit? Fairness equivalent to classic TCP is a design goal of practically all alternative algorithms, so I'm not sure what you're implying. It's entirely possible to improve r…

> How would you swap out the TCP congestion control algorithm in an OS, or even hardware, you don't control? On the contrary, introducing their own novel/mysterious/poorly implemented congestion control algorithms is not a thing I want userspace applications doing.

Fortunately you don't get any say in what my userspace applications do on my own hardware.

And if you worry about hostile applications on your own hardware, the OS is an excellent point to limit what they can do – including overwhelming your network interface.

Re: QUIC and the end of TCP sockets

#33

Post by CuriouslyC »

IgorPartola wrote: post #5

The obnoxious thing is that overly aggressive firewalls have killed any IP protocols that are not TCP or UDP. Even ICMP is often blocked or partially blocked. In the mean time we could have had nice things: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr... SCTP would be a fantastic protocol for HTTP/HTTPS. Pipelining, multi homing, multi streaming, oh my.

SRT is hot stuff over UDP: https://www.haivision.com/products/srt-secure-reliable-trans...

But even UDP is heavily restricted in most cases.

Re: QUIC and the end of TCP sockets

#34

Post by lxgr »

CuriouslyC wrote: post #33
IgorPartola wrote: post #5

The obnoxious thing is that overly aggressive firewalls have killed any IP protocols that are not TCP or UDP. Even ICMP is often blocked or partially blocked. In the mean time we could have had nice things: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr... SCTP would be a fantastic protocol for HTTP/HTTPS. Pipelining, multi homing, multi streaming, oh my.

SRT is hot stuff over UDP: https://www.haivision.com/products/srt-secure-reliable-trans... But even UDP is heavily restricted in most cases.

Is it really? It's been a while since I've been on a network that actually filters UDP.

Too many things that people actually need to work run over it these days, including VPNs, videoconferencing etc.

Re: QUIC and the end of TCP sockets

#35

Post by yobid20 »

IgorPartola wrote: post #5

The obnoxious thing is that overly aggressive firewalls have killed any IP protocols that are not TCP or UDP. Even ICMP is often blocked or partially blocked. In the mean time we could have had nice things: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr... SCTP would be a fantastic protocol for HTTP/HTTPS. Pipelining, multi homing, multi streaming, oh my.

^^^^ this. I work for a big company (15k engineers). Trying to use anything that is not TCP or UDP simply doesnt work here. For years, even UDP was blocked and the answer we got was always "why are you using UDP, use TCP instead". Yep you read that right. Most of these folks are very short sighted or narrow minded. We tried to use SCTP for one project, major blunder. Zero support from network teams. Sctp is blocked everywhere. All their custom software and scripts for network deployments only work with tcp and udp. And they will not change that. And that comes from higher ups the ppl in charge. They are set in there ways and will not budge. As for as QUIC support? Never gonna happen here.

Re: QUIC and the end of TCP sockets

#36

Post by jcelerier »

tptacek wrote: post #17
IgorPartola wrote: post #5

The obnoxious thing is that overly aggressive firewalls have killed any IP protocols that are not TCP or UDP. Even ICMP is often blocked or partially blocked. In the mean time we could have had nice things: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr... SCTP would be a fantastic protocol for HTTP/HTTPS. Pipelining, multi homing, multi streaming, oh my.

Why would you need another IP protocol besides UDP? Anything you can do directly under an IP header, you can do under a UDP header as well, and the UDP header itself is tiny. Going back to David Reed, this is specifically why UDP exists: as the extension interface to build more non-TCP transport protocols.

> the UDP header itself is tiny.

we're fighting for bits here!!! if you want to be 100% safe you need 576 packet size, UDP header is 1.4% of that

Re: QUIC and the end of TCP sockets

#37

Post by neilalexander »

lxgr wrote: post #32
neilalexander wrote: post #30

Earlier quoted context omitted.

> How would you swap out the TCP congestion control algorithm in an OS, or even hardware, you don't control? On the contrary, introducing their own novel/mysterious/poorly implemented congestion control algorithms is not a thing I want userspace applications doing.

Fortunately you don't get any say in what my userspace applications do on my own hardware. And if you worry about hostile applications on your own hardware, the OS is an excellent point to limit what they can do – including overwhelming your network interface.

> the OS is an excellent point to limit what they can do – including overwhelming your network interface

One might even call this "congestion control"!

Re: QUIC and the end of TCP sockets

#38

Post by lxgr »

mtoner23 wrote: post #28
tptacek wrote: post #17

Earlier quoted context omitted.

Why would you need another IP protocol besides UDP? Anything you can do directly under an IP header, you can do under a UDP header as well, and the UDP header itself is tiny. Going back to David Reed, this is specifically why UDP exists: as the extension interface to build more non-TCP transport protocols.

Because it's an extra header. Making data transfer that much less efficient and working to make sure that clients can decide it properly

An extra header of 8 bytes. To put that into perspective, IPv6 added 20 bytes to the IP header compared to v4.

Re: QUIC and the end of TCP sockets

#39

Post by thadt »

mtoner23 wrote: post #28
tptacek wrote: post #17

Earlier quoted context omitted.

Why would you need another IP protocol besides UDP? Anything you can do directly under an IP header, you can do under a UDP header as well, and the UDP header itself is tiny. Going back to David Reed, this is specifically why UDP exists: as the extension interface to build more non-TCP transport protocols.

Because it's an extra header. Making data transfer that much less efficient and working to make sure that clients can decide it properly

Yeah? It's an eight byte header. The OS needs something to tag IP packets to get them delivered to the correct application. So you're thinking maybe a four byte header for 50% savings here?

Re: QUIC and the end of TCP sockets

#40

Post by lxgr »

yobid20 wrote: post #35
IgorPartola wrote: post #5

The obnoxious thing is that overly aggressive firewalls have killed any IP protocols that are not TCP or UDP. Even ICMP is often blocked or partially blocked. In the mean time we could have had nice things: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr... SCTP would be a fantastic protocol for HTTP/HTTPS. Pipelining, multi homing, multi streaming, oh my.

^^^^ this. I work for a big company (15k engineers). Trying to use anything that is not TCP or UDP simply doesnt work here. For years, even UDP was blocked and the answer we got was always "why are you using UDP, use TCP instead". Yep you read that right. Most of these folks are very short sighted or narrow minded. We tried to use SCTP for one project, major blunder. Zero support from network teams. Sctp is blocked e…

> Trying to use anything that is not TCP or UDP simply doesnt work here.

Good news, then: QUIC uses UDP.

> As for as QUIC support? Never gonna happen here.

So generic UDP is allowed, but QUIC is specifically detected and filtered? That would be bizarre.

Post reply on HN