Re: [nfsv4] Review of stefanha-nfav4-rpc-over-vsock-00 (part two of three)

[Stefan Hajnoczi <[e-mail]>]

On Fri, Dec 15, 2017 at 03:30:54PM -0500, David Noveck wrote:
> *Comments by Section (Abstract through Section 2)*
> 
> *Abstract*
> 
> There are problems with the statement that this document "*describes **how
> to* (emphasis aded) transfer Remote Procedure Call (RPC) messages over
> AF_VSOCK sockets" leading to the following issues:
> 
>    - It doesn't do that.
>    - It doesn't seem like it ever will, given that standardization of these
>    matters is unlikely to proceed at a pace that would allow them to be
>    addressed in this document.
>    - Even if those matters were to be standarized, they would be dealing
>    with matters not really in the IETF's purview: OS APIs and OS-hypervisor
>    interfaces,
>    - As a result, the document winds up essentially apologizing for not
>    doing what it would be inappropriate for it to do now and will probably
>    never do.
> 
> Based on my own judgment about what is possible in a reasonble time frame,
> suggest the following as a possible replacement:
> 
> This document discusses the transfer of Remote Procedure Call (RPC)
> messages over AF_VSOCK sockets.  Sufficient information is provided to
> allow RPC services to operate over such sockets.

Okay.

> *1. Introduction*
> 
> Suggest replacing the second through fourth sentences of the first
> paragraph by the following:
> 
> It was initially implemented in Linux 3.9 as a means of communicatng with
> the VMware hypervisor. Later support was added to allow communication with
> the KVM and Hyper-V hypervisors. AF_VSOCK services could be implemented
> without knowlege of the hypervisor type since the commnication semantics
> for the mechanism used are the same for all supported hypervisors.

Okay.

> *2. Status of AF_VSOCK*
> 
> Suggest replacing the section title by "Specification of AF_VSOCK".
> 
> I suggest deleting the first paragrph since:
> 
>    - It isn't clear who "reviewers" are. In the IETF, everybody in the
>    working group may review and make suggestions about a document. Actually,
>    anyone in the IETF may do so, but that only becomes important once the
>    working group is done with it, if the document gets that far.
>    - Saying "is not intended to be included unchanged" is troublesome
>    because it suggests that other things are intended to be included unchanged
>    in the final document.  It is best not to go there.  In the IETF,
>    *everything *is, in principle, subject to change until an RFC is
>    published.
>    - It seems to me that most of the material is appropriate to include in
>    an eventual RFC, if not necessarily unchanged.  It is best to include the
>    material and see what changes people might suggest are necessary.

Points taken, thanks.

> Suggest deleting the last pargraph because:
> 
>    - There are some documents (some actual and some potential) that you
>    mention in the paragraphs above.
>    - It is best not to raise a question without having at least a potential
>    answer.  It may lead to a trip to the swamp and there might be alligators
>    there. I suggest trying to reference AF_VSOCK in the best way possible and
>    see if there are objections.

Okay.

> I suggest reorganzing the remaining material by the level of interface
> involved, either the OS API level or the hypervisor interface level.
> Neither of these are within the purview of the IETF but that does not mean
> they cannot be usefully rerferenced (via an Informative Reference).
> 
> For the API Level suggest the following:
> 
> The Linux AF_VSOCK address family does not have a specification
> document nor is one likely to be produced. AF_VSOCK is defined by its
> Linux implementation that first became available in 2013.
> 
> There is reason to believe that a man page and shared test suite for
> AF_VSOCK might be available in the near future.  This could provide
> necessary information regarding semantics that could be referenced in
> an eventual RFC.

Recent developments:

The Linux man-pages project has merged the vsock.7 man page:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man7/vsock.7

The test suite is currently under review and pending testing by VMware:
https://www.spinics.net/lists/netdev/msg471897.html

> Up untl now, the behavior of VMware's AF_VSOCK driver has been used as
> a reference as to how such sockets should behave.  This behavior is
> very close to that of TCP for SOCK_STREAM and of UDP for SOCK_DGRAM.
> As a result,  converting applications from using AF_INET to AF_VSOCK
> is quite simple.

Sounds good, thanks for these suggestions.

> For the hypervisor interface level suggest the following, assuming that
> there is an informative reference to "https://code.vmware.com/doc/p
> review?id=5521" with the anchor "vsockets".
> 
> Reference documentation for the Vmware Interface, called vSockets,
> which is used by the Vmware AF_VSOCK driver can be found in
> [vsockets].  While this interface is at a lower level than AF_VSOCK,
> it can be a helpful reference since:
> 
> 
>    - Other hypervisors, which have different interfaces, will need to
> be semantically compatible since all will be used to implement the
> AF_VSOCK semantics.
>    - The piece of AF_VSOCK above these interfaces is liable to be
> quite simple, and be limited to providing a path to the underlying
> hypervsor interface.

The VMware vSockets API is higher level than Linux AF_VSOCK.  It is a
cross-platform library that VMware-specific applications can be written
against.  It is not the hypervisor level interface.

My intention was to share the VMware documentation because it is the
most oldest vsock-related document available.

Stefan