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

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

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.

>
> There are necessarily going to be sequences of function calls after
> which trying to change a PvD will be non-sensical.  For example, after
> I have a connected TCP socket: a source address has been chosen from a
> PvD and the PvD's routing table is in use for every write()/send() I
> call.  Attempting to change which PvD is use is a bit non-sensical at
> that point, and I think perhaps that an API should not really allow it.
>
>     In section 3.4 there is a note/question about "loopback PvD". What
>     we were thinking/discussing is that there should be such a PvD for
>     backwards compatibility, i.e. for non-PvD aware applications that
>     for some reason expect all available connections and interfaces
>     (PvDs) to be present (non-PvD aware mpTCP and SCTP applications,
>     UDP applications, debugging applications like tcpdump/wireshark).
>     This configuration we called internally "root network name space".
>
>
> That sounds a bit different from what I was thinking of a loopback
> PvD.  What you describe sounds like how things are today in a totally
> non-PvD-aware system, which has the kinds of problems we're aiming to
> solve, yes?

Probably I missed the point here, i.e. there is no point of having
something like "all addresses" when we are talking about PvD aware
applications that can find out all of them via PvD API. Yet, I believe
that something like "all addresses present" will have to exists on a
system due to the backwards compatibility with legacy applications which
will be with us for a long time. Now, I don't know if that is something
that should be covered by PvD API or not, probably depends on use-cases.

SG

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.

> -ek