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

[Erik Kline <[e-mail]>]

On 2 November 2015 at 22:13, Stjepan Groš <[e-mail]> wrote:

>
> On 02.11.2015 13:18, Erik Kline wrote:
>
>
> On 2 November 2015 at 18:44, Stjepan Groš <[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.

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.

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)