On 2 November 2015 at 18:44, Stjepan Groš <stjepan.g...@fer.hr> 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
_______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
