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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Baptiste Jonglez
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/

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Multipath TCP kernel (linux-mptcp) to [community]

arch dev mailing list
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Multipath TCP kernel (linux-mptcp) to [community]

Gaetan Bisson-2
In reply to this post by Baptiste Jonglez
[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

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Multipath TCP kernel (linux-mptcp) to [community]

Bartłomiej Piotrowski-3
In reply to this post by Baptiste Jonglez
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Multipath TCP kernel (linux-mptcp) to [community]

Baptiste Jonglez
In reply to this post by Gaetan Bisson-2
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Multipath TCP kernel (linux-mptcp) to [community]

Levente Polyak-3
On June 11, 2017 12:47:07 AM GMT+02:00, Baptiste Jonglez <[hidden email]> wrote:

>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
Loading...