[arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]

[Baptiste Jonglez]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20170611/af85d0b2/attachment.asc>