On 03/27/2018 05:04 AM, Lorenzo Colitti wrote:
On Tue, Mar 27, 2018 at 11:18 AM, Christoph Paasch
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. 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.
mptcp mailing list