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

[Erik Kline <[e-mail]>]

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?

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?

-ek