Bug 995574 - Multipath TCP-support in the Fedora-Kernel
Multipath TCP-support in the Fedora-Kernel
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
unspecified Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-09 14:36 EDT by Christoph Paasch
Modified: 2015-07-23 10:13 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-15 09:20:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christoph Paasch 2013-08-09 14:36:12 EDT
Multipath TCP (MPTCP) is an extension to TCP, that allows a single data-stream to be sent over multiple interfaces. This allows to increase the throughput of the connections and improves resilience against failures.

E.g., with Multipath TCP, it is possible to have an SSH connection to a server while connected to Ethernet & WiFi. If you plugout your ethernet-cable, MPTCP will handover the traffic to the WiFi-interface, without the application actually noticing anything. With regular TCP you would need to restart your SSH-connection.

Source-code and further information is available at: http://multipath-tcp.org/

This bug-report is a feature-request to ask if there is an interest in including Multipath TCP in the Fedora-kernel.
Comment 1 Josh Boyer 2013-08-15 09:20:57 EDT
Thanks for the request.  The project sounds interesting, but it's not suitable for Fedora at this time.

First and foremost, that functionality should be posted to the networking maintainers and work itself into the upstream kernel via the normal kernel process.

Ignoring that, the source isn't exactly in a consumable state.  The git tree seems to be a complete kernel tree and not a split out commit set.  We could get it manually, but that's not something we'd really have time to go do.

Also, I'm concerned about the need to disable SYN_COOKIES and TCP_MD5SIG.

If you'd like to see this functionality in Fedora, I'd suggest working with the developers to get it upstream.
Comment 2 Christoph Paasch 2013-08-15 09:45:34 EDT
Hello,

thanks for your reply to my feature-request. Actually, I'm currently the head-developper of the Multipath TCP-project.

(In reply to Josh Boyer from comment #1)
> First and foremost, that functionality should be posted to the networking
> maintainers and work itself into the upstream kernel via the normal kernel
> process.

Yes, longterm our plan is to try pushing MPTCP upstream. But this might take still quite some time. So, I thought that it might be of interest for Fedora to have Multipath TCP in a serparate kernel.

Of course, I understand that if Fedora is not yet interested in Multipath TCP. Admittedly, it is quite a large code-base and taking it via upstream is probably easier for Fedora.

> Ignoring that, the source isn't exactly in a consumable state.  The git tree
> seems to be a complete kernel tree and not a split out commit set.  We could
> get it manually, but that's not something we'd really have time to go do.

On a similar request on Gentoo https://bugs.gentoo.org/show_bug.cgi?id=477786, they had the same concern.
Are there any guidelines on how we should change our development-mode so that it is easier for the distributions to get projects like Multipath TCP in their kernel?

> Also, I'm concerned about the need to disable SYN_COOKIES and TCP_MD5SIG.

Ok, so SYN_COOKIES and TCP_MD5SIG-support is on my ToDo-List now for the next stable MPTCP-release :)


Cheers,
Christoph
Comment 3 Josh Boyer 2013-08-15 09:51:13 EDT
(In reply to Christoph Paasch from comment #2)
> Hello,
> 
> thanks for your reply to my feature-request. Actually, I'm currently the
> head-developper of the Multipath TCP-project.
> 
> (In reply to Josh Boyer from comment #1)
> > First and foremost, that functionality should be posted to the networking
> > maintainers and work itself into the upstream kernel via the normal kernel
> > process.
> 
> Yes, longterm our plan is to try pushing MPTCP upstream. But this might take
> still quite some time. So, I thought that it might be of interest for Fedora
> to have Multipath TCP in a serparate kernel.

Fedora doesn't build separate kernels (or out of tree modules) because it becomes a maintenance headache rather quickly.

> Of course, I understand that if Fedora is not yet interested in Multipath
> TCP. Admittedly, it is quite a large code-base and taking it via upstream is
> probably easier for Fedora.

Not just Fedora, but everyone involved.  For Fedora this is doubly so, as we really try to avoid carrying out-of-tree patches as much as possible.

> > Ignoring that, the source isn't exactly in a consumable state.  The git tree
> > seems to be a complete kernel tree and not a split out commit set.  We could
> > get it manually, but that's not something we'd really have time to go do.
> 
> On a similar request on Gentoo
> https://bugs.gentoo.org/show_bug.cgi?id=477786, they had the same concern.
> Are there any guidelines on how we should change our development-mode so
> that it is easier for the distributions to get projects like Multipath TCP
> in their kernel?

Most developers work in a topic branch in git that isn't the master branch.  Then you can rebase your topic branch (e.g. mptcp) on top of the master branch when it updates and you can use 'git format-patch master..mptcp' to get a list of nicely split out commits.

That's just a suggestion though.  The main issue is to have a set of well formatted patches that can be sent to the list for review.  See Documentation/SubmittingPatches in the kernel tree.
> 
> > Also, I'm concerned about the need to disable SYN_COOKIES and TCP_MD5SIG.
> 
> Ok, so SYN_COOKIES and TCP_MD5SIG-support is on my ToDo-List now for the
> next stable MPTCP-release :)

Sounds great.  Good luck!

Note You need to log in before you can comment on or make changes to this bug.