4 ms·

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.

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.