43 ms·

I didn't realize it was such a drop-in replacement. Couldn't you then use a LD_PRELOAD to translate TCP into MPTCP? Then applications wouldn't need to be modi

I didn't realize it was such a drop-in replacement. Couldn't you then use a LD_PRELOAD to translate TCP into MPTCP? Then applications wouldn't need to be modified.

brenns10 5y ago
It's probably possible to do that, assuming you have a kernel properly configured and the sysctls and privileges established. I had no problems using the out-of-tree MPTCP kernel for a variety of TCP based tasks, so most applications had no issue with it. Of course then the next requirement is a server which supports MPTCP as well... which means you need at least two hosts with very specific kernels, and maybe LD_PRELOAD setups :/ And to be honest, there are good reasons not to enable MPTCP by default. For one, there's security consequences. "Hi Bob, my name is Alice, I have a totally different IP address but would like to join into this conversation as well..." MPTCP has protections for this based on session keys that are exchanged. But for many people, it's still a concern. Another good reason is that most applications don't benefit from multiple paths, so it's a lot of extra complexity and packets being sent for no benefit. And finally, there are many possible use cases for multipath reliable sockets, as I detailed above. Each requires different policy (to determine when to make new connections across different IP addresses, or how to schedule data to transmit across each subflow). It's unlikely that an unmodified application would get the kind of behavior that the user desires. How do you decide whether you should treat one subflow as a metered "backup" connection, or whether you should be blasting data across all subflows? This could all be configured by user who has dutifully read enough manual pages and implemented enough netlink applications (or BPF scripts?) to control the kernel's behavior, I'm sure. So, the moral of the story to me is that, drop-in replacement was an exciting goal, and something that felt important. Losing it definitely meant that MPTCP was doomed to not reach critical mass, and probably won't see widespread deployment. But losing it also means that we can see applications fine-tune a solution like this one for their use case, which feels like a win.
- brenns10 5y ago
  To expand on this - if you are going to mess with LD_PRELOAD, why not stick this whole library behind LD_PRELOAD? You get similar levels of compatibility (except for the odd app that shirks libc and hand-codes their system calls...). But you also get the ability to do userspace protocol development, and you have an easier time of configuring the policy for how you handle new connections and subflows.
  - grayfaced 5y ago
    Thanks for the explanation, the linux internals of this is past my understanding. It reminded me of tsocks (for wrapping connections in a socks proxy), so I thought a similar thing would work. But it makes sense that you don't really get benefits unless you've tuned mptcp.

I didn't realize it was such a drop-in replacement. Couldn't you then use a LD_PRELOAD to translate TCP into MPTCP? Then applications wouldn't need to be modified.

brenns10 5y ago

It's probably possible to do that, assuming you have a kernel properly configured and the sysctls and privileges established. I had no problems using the out-of-tree MPTCP kernel for a variety of TCP based tasks, so most applications had no issue with it. Of course then the next requirement is a server which supports MPTCP as well... which means you need at least two hosts with very specific kernels, and maybe LD_PRELOAD setups :/ And to be honest, there are good reasons not to enable MPTCP by default. For one, there's security consequences. "Hi Bob, my name is Alice, I have a totally different IP address but would like to join into this conversation as well..." MPTCP has protections for this based on session keys that are exchanged. But for many people, it's still a concern. Another good reason is that most applications don't benefit from multiple paths, so it's a lot of extra complexity and packets being sent for no benefit. And finally, there are many possible use cases for multipath reliable sockets, as I detailed above. Each requires different policy (to determine when to make new connections across different IP addresses, or how to schedule data to transmit across each subflow). It's unlikely that an unmodified application would get the kind of behavior that the user desires. How do you decide whether you should treat one subflow as a metered "backup" connection, or whether you should be blasting data across all subflows? This could all be configured by user who has dutifully read enough manual pages and implemented enough netlink applications (or BPF scripts?) to control the kernel's behavior, I'm sure. So, the moral of the story to me is that, drop-in replacement was an exciting goal, and something that felt important. Losing it definitely meant that MPTCP was doomed to not reach critical mass, and probably won't see widespread deployment. But losing it also means that we can see applications fine-tune a solution like this one for their use case, which feels like a win.

brenns10 5y ago
To expand on this - if you are going to mess with LD_PRELOAD, why not stick this whole library behind LD_PRELOAD? You get similar levels of compatibility (except for the odd app that shirks libc and hand-codes their system calls...). But you also get the ability to do userspace protocol development, and you have an easier time of configuring the policy for how you handle new connections and subflows.
- grayfaced 5y ago
  Thanks for the explanation, the linux internals of this is past my understanding. It reminded me of tsocks (for wrapping connections in a socks proxy), so I thought a similar thing would work. But it makes sense that you don't really get benefits unless you've tuned mptcp.