[arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]
Hi again, Since a few years, I maintain a variant of the linux kernel in the AUR [1] that adds support for Multipath TCP [2]. The most recent version is based on linux 4.4, and the package I maintain tries to follow the "linux" package from [core] as much as possible. There is no short- or medium-term perspective to merge Multipath TCP upstream, so I would like to bring this package to [community]. There are already several kernel variants in the official repos, but I would like to get some feedback before adding another one. Thanks, Baptiste [1] https://aur.archlinux.org/packages/linux-mptcp/ [2] http://www.multipath-tcp.org/
Hey, Quoting Baptiste Jonglez (2017-06-06 22:58:01)
Hi again,
Since a few years, I maintain a variant of the linux kernel in the AUR [1] that adds support for Multipath TCP [2]. The most recent version is based on linux 4.4, and the package I maintain tries to follow the "linux" package from [core] as much as possible.
There is no short- or medium-term perspective to merge Multipath TCP upstream, so I would like to bring this package to [community]. There are already several kernel variants in the official repos, but I would like to get some feedback before adding another one.
Thanks, Baptiste
[1] https://aur.archlinux.org/packages/linux-mptcp/ [2] http://www.multipath-tcp.org/
Personally I don't really think that having it in [community] would add that much, since it doesn't really seem to have /that/ many users compared to the other kernels. Now I'm not saying that you shouldn't add it, just that I'm not sure how useful of an addition it would be.
[2017-06-06 22:58:01 +0200] Baptiste Jonglez:
Since a few years, I maintain a variant of the linux kernel in the AUR [1] that adds support for Multipath TCP [2]. The most recent version is based on linux 4.4, and the package I maintain tries to follow the "linux" package from [core] as much as possible.
There is no short- or medium-term perspective to merge Multipath TCP upstream, so I would like to bring this package to [community]. There are already several kernel variants in the official repos, but I would like to get some feedback before adding another one.
We already have an official linux package in [core] which is very well maintained and works great for 99% of our users, so I'd really like if you tried to explain why we need another variant and why the AUR is not suitable for it anymore. As you're aware, we've had another package (linux-grsec) with a user base certainly much larger than linux-multipath come and go because upstream went another direction and nobody had the resources to fork it. I'd really like our packages to enjoy some level of support and not just go to [community] "because they can" and get dropped just as fast. What could you tell us about linux-multipath on that front? Cheers. -- Gaetan
Hi Gaetan, On Wed, Jun 07, 2017 at 08:55:15AM -1000, Gaetan Bisson wrote:
[2017-06-06 22:58:01 +0200] Baptiste Jonglez:
Since a few years, I maintain a variant of the linux kernel in the AUR [1] that adds support for Multipath TCP [2]. The most recent version is based on linux 4.4, and the package I maintain tries to follow the "linux" package from [core] as much as possible.
There is no short- or medium-term perspective to merge Multipath TCP upstream, so I would like to bring this package to [community]. There are already several kernel variants in the official repos, but I would like to get some feedback before adding another one.
We already have an official linux package in [core] which is very well maintained and works great for 99% of our users, so I'd really like if you tried to explain why we need another variant and why the AUR is not suitable for it anymore.
At that point, Multipath TCP is mostly useful to researchers and tinkerers, because both ends of a TCP connection need to run the modified kernel (otherwise, it just falls back to regular TCP). However, I still think it would be useful in [community]: 1) One nice use-case is link aggregation, where you basically tunnel traffic over a Multipath TCP connection. You may want to build such a tunnelling system with Arch. 2) Not everybody has the resources to build a kernel (time, CPU, memory, disk...) 3) It is good to have kernel diversity in our repositories. For instance, I had a laptop that couldn't go to sleep with the kernels from [core] (either linux or linux-lts), but it worked with linux-mptcp. This is really not the main goal of having linux-mptcp in [community], but it's a nice side-effect. By the way, the kernel is completely stable, I have been using it on a daily basis (on my laptop) since a few years. At the beginning of the project in ~2014, there were occasional kernel panics, but not anymore.
As you're aware, we've had another package (linux-grsec) with a user base certainly much larger than linux-multipath come and go because upstream went another direction and nobody had the resources to fork it. I'd really like our packages to enjoy some level of support and not just go to [community] "because they can" and get dropped just as fast. What could you tell us about linux-multipath on that front?
When talking about "some level of support", do you mean whether the upstream project is active? The project has one main developer, 2 to 3 additional developers, and several small contributors (including myself). I think nobody is working full-time on it, though. Regarding activity, major releases happen when the project is rebased on a more recent kernel version and sufficiently tested: - v0.86 released 2013-03-07, based on linux 3.5 - v0.87 released 2013-07-25, based on linux 3.10 - v0.88 released 2013-10-30, based on linux 3.11 - v0.89 released 2014-10-12, based on linux 3.14 - v0.90 released 2015-09-02, based on linux 3.18 - v0.91 released 2016-06-21, based on linux 4.1 - v0.92 released 2017-06-04, based on linux 4.4 So, I would say the project is active and focused on the long term. There have been minor releases in-between these major releases, to integrate bugfixes and update to latest stable kernel. For instance, v0.91.2 was based on linux 4.1.35. Baptiste
On June 11, 2017 12:47:07 AM GMT+02:00, Baptiste Jonglez
At that point, Multipath TCP is mostly useful to researchers and tinkerers, because both ends of a TCP connection need to run the modified kernel (otherwise, it just falls back to regular TCP).
However, I still think it would be useful in [community]:
1) One nice use-case is link aggregation, where you basically tunnel traffic over a Multipath TCP connection. You may want to build such a tunnelling system with Arch.
That there may be useful things provided by multipath per say is out of question, it's more how useful it is to package yet another kernel into the repository. It's very much an edge case variant at this point (as you pointed out yourself).
2) Not everybody has the resources to build a kernel (time, CPU, memory, disk...)
If you're a researcher or thinker you will somehow manage to compile a kernel from the AUR and the resources to do so are not really that high.
So, I would say the project is active and focused on the long term. There have been minor releases in-between these major releases, to integrate bugfixes and update to latest stable kernel. For instance, v0.91.2 was based on linux 4.1.35.
Which is quite ancient actually. Also the mentioned support includes handling of vulnerabilities by our security team. Each kernel, especially when not in sync with neither LTS nor the default, creates overhead when handling and researching patches and vulnerabilities as they are part of the official repositories. This can get pretty cumbersome and personally I don't quite see the justification fur the additional burden it creates. My humble opinion is that multipath sounds nice but belongs into the AUR rather then into our repository. Cheers, Levente
On 06/06/2017 10:58 PM, Baptiste Jonglez wrote:
Hi again,
Since a few years, I maintain a variant of the linux kernel in the AUR [1] that adds support for Multipath TCP [2]. The most recent version is based on linux 4.4, and the package I maintain tries to follow the "linux" package from [core] as much as possible.
There is no short- or medium-term perspective to merge Multipath TCP upstream, so I would like to bring this package to [community]. There are already several kernel variants in the official repos, but I would like to get some feedback before adding another one.
Thanks, Baptiste
[1] https://aur.archlinux.org/packages/linux-mptcp/ [2] http://www.multipath-tcp.org/
Just to add what has been said already. The fact that there is no perspective of having multipath upstreamed is the exact reason why we should not have it in repositories. It is a niche that Arch does not target. -ARCH and -lts kernels are self-explanatory. -hardened replaced the grsecurity kernel and combines KSPP efforts with enormous Daniel's knowledge (and there is more business to it that's out of scope for this mailing list), -zen is desktop oriented and also maintained "upstream" by heftig. This covers everything that the majority of our community might want and I can't see what else could fit there. Bartłomiej
participants (5)
-
Baptiste Jonglez
-
Bartłomiej Piotrowski
-
Gaetan Bisson
-
Johannes Löthberg
-
Levente Polyak