On 03/27/2018 05:04 AM, Lorenzo Colitti wrote:
On Tue, Mar 27, 2018 at 11:18 AM, Christoph Paasch <cpaasch@apple.com> 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
subflows.

+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. 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() shows 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 seems 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.

Shoaib



_______________________________________________
mptcp mailing list
mptcp@lists.01.org
https://lists.01.org/mailman/listinfo/mptcp