Sorry I did not respond to your email, too many issues to worry about :-)
On 03/28/2018 02:33 PM, Stephen Brennan wrote:
> Hi Rao et al.,
> On Tue, Mar 27, 2018 at 06:53:46PM -0700, Rao Shoaib wrote:
>> On 03/27/2018 05:04 AM, Lorenzo Colitti wrote:
>>> On Tue, Mar 27, 2018 at 11:18 AM, Christoph Paasch <cpaasch(a)apple.com
>>> <mailto:firstname.lastname@example.org>> wrote:
>>> It also would allow us to expose subflows as file-descriptors
>>> to the
>>> user-space. That way the user-space can do setsockopt,
>>> getsockopt,... on the
>>> subflows. An idea that came up in the past when we were thinking
>>> on how to
>>> expose an MPTCP API that allows apps to control certain things
>>> on the
>>> +1 to this since it will allow client platforms to use setsockopt to,
>>> for example, bind subflows to interfaces (e.g., with
>>> SO_BINDTODEVICE, or
>>> with SO_MARK as used by Android).
>> May I ask why it can not be done -- Only flow id should be needed.
> It sounds like you're referring to the proposed MPTCP_SUB_GETSOCKOPT and
> MPTCP_SUB_SETSOCKOPT operations in this IETF draft , correct?
> : https://tools.ietf.org/html/draft-hesmans-mptcp-socket-00
Actually I have not read the draft, my comment was based on general
understanding of the kernel. I am coming of Solaris and we know how to
create custom socket, special setopt/getopt , special fd's to expose
something etc etc. It is not rocket science. If someone has already
thought of it then we have less work to do.
Any change of this kind has to be discussed in a standards body so
vendors and users can comment.
>> Plus for
>> policy enforcement the meta socket would have to be consulted. I am
>> new to
>> Linux but based on what I have read SO_BINDTODEVICE does not
>> guarantee much
>> for Tx if the routing says otherwise, quick check of ip_queue_xmit()
>> it first consults the routing table. I understand policy routing can
>> be used
>> to steer the packets. Perhaps my understanding is incorrect.
>> IMHO this whole idea of exposing individual flows to the application
>> to go against the basic design of MPTCP. I am not sure what the use
>> case is
>> as TCP is streams based and MPTCP will spread out data on multiple
>> flows. I
>> am not a involved in the cellular space so I don' know, feel free to
>> enlighten me.
> I'm also a bit confused at this. I've read the Socket API drafts from
> which seem to be motivated by the idea that mobile apps will want to
> directly control which subflows and paths are created (similar to the
> APIs released recently). It sounds like we have two approaches: (1)
> as a drop-in replacement for TCP, so unmodified applications may use it,
> and (2) MPTCP as an explicitly requested protocol which user-space
> applications request, and then manipulate via socket options. Given the
> amount of drafts and other work put in so far, it seems that use case
> has enough demand that it ought to be supported.
Can you point me to the drafts or requests. As I said with the current
design everything is possible. No change is needed.
The best approach I think is to enhance netlink. I have a pie in the
sky idea, we can have meta/master socket register with netlink,
identified by src and destination addresses for direct communication.