Re: [mif] Fwd: New Version Notification for draft-kline-mif-mpvd-api-reqs-00.txt

[Stjepan Groš <[e-mail]>]

On 04.11.2015 13:01, Erik Kline wrote:
>
>
> On 2 November 2015 at 22:13, Stjepan Groš <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>     On 02.11.2015 13:18, Erik Kline wrote:
>>
>>     On 2 November 2015 at 18:44, Stjepan Groš <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Hi Erik,
>>
>>         Thank you for the draft.
>>
>>         I have few comments/questions.
>>
>>         First, what I'm reading from the draft is that each PvD aware
>>         application should have access to a single PvD at any single
>>         moment? If that is so, what about mpTCP and SCTP applications
>>         that are PvD aware? They should have access to multiple PvDs
>>         simultaneously for a fail over reasons. So, how this draft
>>         takes into account that use case?
>>
>>
>>     Not quite: they should be able to specify only one PvD per
>>     function call, per thread (for example).  An app can have
>>     multiple sockets, each one using one PvD.  An app can have
>>     something like a single unconnected datagram socket and call
>>     sendto() with a different PvD for each sendto() call.  That kind
>>     of thing is more what I meant to write, but I guess was not very
>>     clear.  (Clearly, I have a bunch of sockets-y things in my head
>>     but am trying to write things in a more general,
>>     non-sockets-dependent way.)
>>
>>     The confusion may be arising in part from the resolution of which
>>     PvD to use for a given function call if no PvD is specified.  In
>>     those cases, the system checks for "defaults" at increasingly
>>     general levels.  So a process could set a process default PvD and
>>     avoid having to specify the PvD for each an every call, but still
>>     make individual socket calls or query DNS on a different PvD
>>     whenever it wants to.
>>
>>     Does this make more sense?
>
>     I was thinking on functions like sctp_bindx that explicitly expect
>     multiple IP addresses to be present at a point when the function
>     is called. mpTCP could be even bigger problem because, as I
>     understand it, Linux kernel autonomously decides which local IP
>     addresses to use.
>
>
> Ah, thank you, that kind of call is an important consideration.  I
> believe I have a solution that will work: when determining the
> intended PvD in the case of existing APIs that specify source
> addresses (and/or maybe even interfaces) we should use PvDs that are
> uniquely identified by this information.

You mean like having some separate function which is called before
sctp_bindx with the same arguments so that appropriate PvDs can be
activated?

We were thinking about some kind of a PvD activation function (e.g.
pvd_attach_pvd(pvdid *id) and possibly also pvd_detach_pvd) so that
application can attach any combination of PvDs it wants to have access
to. This, at least to me, seems to be the most flexible solution?

>
> What to do if an address does not unique identify a PvD is another
> matter.  For both of these issues I'm hoping to have some discussion
> in Friday's mif meeting.
>  
>
>     P.S. When I'm discussing these issues I'm thinking about general
>     Linux Workstation, like Fedora, and in addition I'm also I'm in
>     terms of network name spaces as the way to implement PvD separation.
>
>
> FWIW, for Android's mif implementation network namespaces were
> considered and rejected.  Among other things, I don't think it's
> really possible to write an application that can have multiple sockets
> with each one "bound" to a different network namespace.

That's interesting. Namely, I wrote a test application that does the
following:

1. creates a socket (just calls socket function) in the default namespace
2. then, it switches to some other namespace using setns. This new
namespace doesn't have any connectivity.
3. test application connects to a server and issues HTTP GET request
4. writes response to the stdout

In short, this worked which made us conclude that the socket is bound to
whatever namespace was active at the time socket was created.
Application can switch to other namespaces after that at will, even
within a single thread. This means that you can use multiple namespaces
from within the single application at will. You have to only take care
to activate namespace you need before issuing socket call.

Did you try to do something like that?

The issue we have though, with respect to namespaces, is that we might
end up in a situation in which two namespaces share the same IP address.
It is almost equivalent to having two machines on the network with the
same IP address. We have some half-baked ideas for solutions for this
issue, and nothing that works.

>
> Instead, it's a bit more like implicit PvDs are used with one
> interface belonging to one and only one PvD and each PvD gets its own
> routing table.  This model is, obviously, not as general as mif work
> is trying to address (i.e. m:n interfaces to PvDs are not supported).
>  (but it has been sufficient to gain some experience with how an API
> would look and behave)

This probably could work for Android, but this brings up two points when
we talk about some general Linux distribution:

1. Is it really necessary to support multiple interfaces with a single
PvD instance? And by single PvD instance I mean PvD with the same
parameters, i.e. same address on multiple interfaces. In that case it
seems to me that bridging is a better approach.

2. How do you intend to control which process uses which interface/PvD?

SG