3 ms·

All well and good, but TCP has been around for decades and there are top quality network stacks providing TCP sockets on top of almost anything that can run on

All well and good, but TCP has been around for decades and there are top quality network stacks providing TCP sockets on top of almost anything that can run on a CPU. Is there a (preferably BSD-licensed) QUIC piece of code that can be retrofitted where the TCP stack of an OS used to be? Or are we going to start linking a piece of the network stack into the applications?

jabedude 6y ago
>Is there a (preferably BSD-licensed) QUIC piece of code that can be retrofitted where the TCP stack of an OS used to be? No, and that's a current drawback of QUIC. But of course it's just a current drawback - the investment cost of integrating this into the operating system vice applications will certainly be eclipsed by the benefits as QUIC is deployed more throughout the internet
PudgePacket 6y ago
It's intentionally userspace to avoid ossification.
- simias 6y ago
  What you call "ossification" others would call "stabilization" and "standardization". Not to say that the inertia of (some) kernels is not excessive sometimes but I'm not a fan of the "fuck it, we'll do it in userland" attitude. That creates big, opaque application blobs that nobody understands and knows how to debug with standard tools. I feel like Google in particular loves to do that stuff because while they control the internet and the browser, they don't (yet) control the OS so they have a very strong incentive to push stuff up in order to retain control. They don't have to ask anybody to add things into Chrome, they have to get third parties on board to extend the kernels (outside of Android at least).
  - toast0 6y ago
    What's extra frustrating is that Google does control the OS for Android, but they don't use that to make TCP better. Things they could do: a) enable MTU blackhole probing, so people behind dumb networks can talk to servers that don't artificially reduce MSS. Apple has a pretty agressive implementation of MTU probing, and it's very effective. b) put in hooks for userspace congestion control. Make sending faster (or not) with updates from Google Play services (or whatever) c) the article mentions sending fewer acks. That could probably be done in TCP too --- it makes sense to make that a setting that they could roll out. d) some sort of name and shame program for bad networks / bad network devices. It's 2020 and people running PPPoE and sending MSS 1480 when it's really 1472 should be ashamed of themselves, but big companies just set their servers to MSS 1460 and call it a day. :(
  - PudgePacket 6y ago
    It's not me, it's the IETF, https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force https://en.wikipedia.org/wiki/Internet_Engineering_Task_Forc.... QUIC is a standard, it will be stabilised in time. TCP can't be improved on much at this point, and there are some pretty massive flaws in it that QUIC solves. TCP isn't going away any time soon, or being "replaced" by QUIC, but for certain applications QUIC is going to be a massive improvement, albeit and an increased complexity and application size cost. There are over 10 implementations of QUIC at this point in time, you don't have to go with Google's approach, https://en.wikipedia.org/wiki/QUIC#Source_code https://en.wikipedia.org/wiki/QUIC#Source_code.
toast0 6y ago
Microsoft put out an MIT licensed stack that was discussed here earlier in the week. I'm not affiliated, and haven't inspected it. https://news.ycombinator.com/item?id=23014068 https://news.ycombinator.com/item?id=23014068

jabedude 6y ago

>Is there a (preferably BSD-licensed) QUIC piece of code that can be retrofitted where the TCP stack of an OS used to be? No, and that's a current drawback of QUIC. But of course it's just a current drawback - the investment cost of integrating this into the operating system vice applications will certainly be eclipsed by the benefits as QUIC is deployed more throughout the internet

PudgePacket 6y ago

It's intentionally userspace to avoid ossification.

simias 6y ago
What you call "ossification" others would call "stabilization" and "standardization". Not to say that the inertia of (some) kernels is not excessive sometimes but I'm not a fan of the "fuck it, we'll do it in userland" attitude. That creates big, opaque application blobs that nobody understands and knows how to debug with standard tools. I feel like Google in particular loves to do that stuff because while they control the internet and the browser, they don't (yet) control the OS so they have a very strong incentive to push stuff up in order to retain control. They don't have to ask anybody to add things into Chrome, they have to get third parties on board to extend the kernels (outside of Android at least).
- toast0 6y ago
  What's extra frustrating is that Google does control the OS for Android, but they don't use that to make TCP better. Things they could do: a) enable MTU blackhole probing, so people behind dumb networks can talk to servers that don't artificially reduce MSS. Apple has a pretty agressive implementation of MTU probing, and it's very effective. b) put in hooks for userspace congestion control. Make sending faster (or not) with updates from Google Play services (or whatever) c) the article mentions sending fewer acks. That could probably be done in TCP too --- it makes sense to make that a setting that they could roll out. d) some sort of name and shame program for bad networks / bad network devices. It's 2020 and people running PPPoE and sending MSS 1480 when it's really 1472 should be ashamed of themselves, but big companies just set their servers to MSS 1460 and call it a day. :(
- PudgePacket 6y ago
  It's not me, it's the IETF, https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force https://en.wikipedia.org/wiki/Internet_Engineering_Task_Forc.... QUIC is a standard, it will be stabilised in time. TCP can't be improved on much at this point, and there are some pretty massive flaws in it that QUIC solves. TCP isn't going away any time soon, or being "replaced" by QUIC, but for certain applications QUIC is going to be a massive improvement, albeit and an increased complexity and application size cost. There are over 10 implementations of QUIC at this point in time, you don't have to go with Google's approach, https://en.wikipedia.org/wiki/QUIC#Source_code https://en.wikipedia.org/wiki/QUIC#Source_code.

toast0 6y ago

Microsoft put out an MIT licensed stack that was discussed here earlier in the week. I'm not affiliated, and haven't inspected it. https://news.ycombinator.com/item?id=23014068 https://news.ycombinator.com/item?id=23014068