Re: Sun White Paper on WebNFS

Robert S. Thau:
>
>Hi --- I'm just posting a pointer to a document which many people in
>the WG might want to review.  It's Sun's White Paper on WebNFS, which
>they are now proposing as an alternative to HTTP for some applications.
>This document is at
>
>   <http://www.sun.com:80/sunsoft/solaris/networking/webnfs/index.html>

I just read the white paper and the press release under the above URL.

The press release under the above URL utterly over-hypes the good
WebNFS can do.  In particular, it fails to mention the little detail
of there not being an easy upgrade path from current HTTP/1.0 web
sites to WebNFS-based sites.  To deconstruct the summary below the
title of the press release:

 WebNFS Strengthens Web Infrastructure; Increases Internet Performance
 Up to 10 Times; Can Triple Web Site Capacity

The "up to 10 times" is claimed in the white paper applies to the
downloading time of large amounts of small (Java class) files
(compared to HTTP without persistent connections).  The "triple
capacity" refers to an interesting benchmark in the white paper, more
about that below.

If there is an easy upgrade path from HTTP/1.0 to WebNFS, the white
paper does a good job at hiding it.

The white paper does contain some interesting information, and is
comparatively hype-free.  It does not argue that 1.0 servers should be
replaced by WebNFS servers.  It seems to mainly make a case for nfs:
URLs being supported along with ftp: and gopher: URLs.

>Unfortunately, the white paper does not really cover the relationships
>to many of HTTP's widely used features very well --- the section on
>caching is a particular disappointment, and I could find no mention
>of session state.  

As far as I can see, these is no coverage of these features because
WebNFS does not try to provide these features.  There isn't even a
facility for sending along the MIME type of the data.  nfs: URLs would
provide about the same functionality as ftp: URLs do now, though
access would be more efficient.

>Still, they do make a reasonably interesting case that performance of
>an NFS-based protocol in retrieving simple files directly from an
>origin server would exceed that of status-quo HTTP in the same
>application (including HTTP/1.1).

The paper says that most of the performance benefit of WebNFS over
HTTP/1.1 is due to WebNFS being implemented in the kernel while
HTTP/1.1 is not (yet).  So maybe we'll see HTTP/1.1 servers
implemented as Linux kernel modules in future.  The paper claims no
great savings in bandwidth when compared to persistent HTTP.

Also, it is interesting to note that for their HTTP server/NFS server
performance comparison, they subject a HTTP server and an NFS server
to NFS load patterns generated by the leading NFS benchmark, not to
HTTP load patterns generated by a HTTP benchmark.  I would not have
noticed this if they had not mentioned in Section 10.0 that NFS
vendors aggressively tune their NFS implementations with this
particular NFS benchmark in mind.

[...]
>(In any case, public acceptance determines the evolution of standards
>at least as much as any individual's notion of what constitutes technical
>merit, and there seems to be an awful lot of buzz around WebNFS right
>now.

To get public acceptance for WebNFS as an alternative to HTTP, it
would at least have to deliver the things promised in the press
release, but it cannot.

>  That may, in the long run, be determinative, particularly in the
>absence of buzz about alternatives, and WebNFS may merit careful study
>now for that reason alone).

In my view, WebNFS may merit careful study by people working on HTTP
multiplexing, but it probably does not merit careful study beyond
that.  To students of hype, I recommend a careful study of Java.

>rst

Koen.

Received on Friday, 14 June 1996 06:46:36 UTC