netdev - Re: [RFC] tcp: add support for scheduling TCP options on TCP sockets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAE1zotLxNPSpksBbKu6Z1MrcgdnFGxK8E-6c+fT6csEcQmFOsw@mail.gmail.com>
Date:	Wed, 7 May 2014 21:15:54 +0300
From:	Octavian Purdila <octavian.purdila@...el.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Christoph Paasch <christoph.paasch@...ouvain.be>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC] tcp: add support for scheduling TCP options on TCP sockets

On Wed, May 7, 2014 at 6:32 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Wed, 2014-05-07 at 18:17 +0300, Octavian Purdila wrote:
>
>>
>> That would require adding a new field to sk_buff to keep track of how
>> much we need to copy in pskb_copy. Fortunately it seems it has some
>> holes we could use.
>>
>> David, does that seem reasonable?
>
> MPTCP and/or Minion could be implemented in user land, with a generic
> infrastructure in the kernel to directly pass raw packets once demux
> has been done by the kernel.
>

Implementing MPTCP in userspace makes a lot of sense to me as you can
naturally consider MPTCP as a layer on top of TCP. Passing raw packets
is one option, another one is creating the infrastructure to
send/receive TCP options with standard TCP sockets APIs like sendmsg
or recvmsg.

The first option is more flexible, but on the other hand (at least for
MPTCP), it means that userspace must duplicate the "basic" TCP
functionality. The second option allows one to reuse the TCP stack in
kernel while adding new functionality on top of that.

> Large CDN cant always assume multi paths to hit a particular destination
> can all originate from a single host in the datacenter.
>
> MPTCP has this hard assumption from day one.
>
> Our team try to focus on making TCP better, we believe all these
> experimental features do not belong to the kernel yet.

I hear you, the TCP stack is already very complex. That is why I am
looking at ways to manage the increased complexity that MPTCP brings
by using a layered approach.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html