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

From: David Noveck <[email-masked]>
Date: Fri, 15 Dec 2017 15:30:54 -0500

*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.

*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.

*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.

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.

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.

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.

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.

---

From: Stefan Hajnoczi <[email-masked]>
Date: Mon, 18 Dec 2017 15:25:05 +0000

> allow RPC services to operate over such sockets.

Okay.

> for the mechanism used are the same for all supported hypervisors.

Okay.

>    material and see what changes people might suggest are necessary.

Points taken, thanks.

>    see if there are objections.

Okay.

> necessary information regarding semantics that could be referenced in

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

> As a result,  converting applications from using AF_INET to AF_VSOCK

Sounds good, thanks for these suggestions.

> quite simple, and be limited to providing a path to the underlying

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