3 ms·

I am not seeing the problem with every participant linking in their own QUIC implementations. The problem of ossification is there is way too much policy hidden

I am not seeing the problem with every participant linking in their own QUIC implementations. The problem of ossification is there is way too much policy hidden on the kernel side of the sockets API, and vanishingly few applications are actually trying to make contact with Mars, which is the use-case for which those policies are tuned.

xg15 3y ago
How would you make changes to the QUIC protocol then?
- jeffbee 3y ago
  I wouldn't. I would write down the protocol in a good and extensible way, the first time. It's no good throwing something into the world with the assumption that you can fix the protocol later.
sophacles 3y ago
Which policies are you speaking of? How are they hidden? What would you like to tweak that you can't?
- theptip 3y ago
  Presumably all the sysctls? http://www.linux-admins.net/2010/09/linux-tcp-tuning.html?m=1 http://www.linux-admins.net/2010/09/linux-tcp-tuning.html?m=... & associated traffic shaping algorithms?
- jeffbee 3y ago
  There are a billion timers inside the kernel, not all of which can be changed. Some of them are #defined even. In these days when machines are very large and always have several applications running, having an external network stack in the kernel violates the end-to-end principle. All of the policy about congestion, retrying, pacing, shaping, and flow control belong inside the application. https://en.wikipedia.org/wiki/End-to-end_principle https://en.wikipedia.org/wiki/End-to-end_principle
  - sophacles 3y ago
    Can you point me to an example of a timer in the kernel that is not settable/tunable that should be? My experience in looking at such things suggests that most of the #defined bits are because RFCs define the protocol that way. As for network stack per application: you're more than welcome to so so a myriad of ways - linux provides many different ways to pull raw IP, or raw ethernet into userspace (e.g. xdp, tun/tap devices, dpdk, and so on). It's not like you're being forced to use the kernel stack from lack of supported alternatives.

xg15 3y ago

How would you make changes to the QUIC protocol then?

jeffbee 3y ago
I wouldn't. I would write down the protocol in a good and extensible way, the first time. It's no good throwing something into the world with the assumption that you can fix the protocol later.

sophacles 3y ago

Which policies are you speaking of? How are they hidden? What would you like to tweak that you can't?

theptip 3y ago
Presumably all the sysctls? http://www.linux-admins.net/2010/09/linux-tcp-tuning.html?m=1 http://www.linux-admins.net/2010/09/linux-tcp-tuning.html?m=... & associated traffic shaping algorithms?
jeffbee 3y ago
There are a billion timers inside the kernel, not all of which can be changed. Some of them are #defined even. In these days when machines are very large and always have several applications running, having an external network stack in the kernel violates the end-to-end principle. All of the policy about congestion, retrying, pacing, shaping, and flow control belong inside the application. https://en.wikipedia.org/wiki/End-to-end_principle https://en.wikipedia.org/wiki/End-to-end_principle
- sophacles 3y ago
  Can you point me to an example of a timer in the kernel that is not settable/tunable that should be? My experience in looking at such things suggests that most of the #defined bits are because RFCs define the protocol that way. As for network stack per application: you're more than welcome to so so a myriad of ways - linux provides many different ways to pull raw IP, or raw ethernet into userspace (e.g. xdp, tun/tap devices, dpdk, and so on). It's not like you're being forced to use the kernel stack from lack of supported alternatives.