Subject: RE: [nfsv4] recent server request cache

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 17 Nov 2003 08:31:41 -0800

I agree that this is a valid concern.  I'm not going to be satisfied until
we make the request cache history, and am looking forward to EOS using
the session extensions in a forthcoming minor version.

I think there are some things that could be done to at least make the
situation no worse, or perhaps a bit better, than in v2/v3.  Let me
hasten to mention that none of these are things our server currently
does, but I think we should all be thinking about ways to narrow the
false-positive window.

The problem that you outline is basically that the everything-is-a-
compound philosophy increases the probability of false positives since 
comparison on procedure number loses its value as a discriminator.

So here are a number of possible suggestions on things to use as 
additional discriminators, that would serve to reduce false positives:

    Comparison of the tags or a hash thereof.  Since the reply will
    contain, normally, the request tag value, the tag for the request 
    in the case could be compared against that for the putative 
    retransmission with rejection on a mismatch.  Even if you don't
    save the tag (too large or something), you can still save a hash 
    of the request tag in the request cache entry header and compare
    that to the hash of the tag for the incoming request.

    Comparison of the ops.  The structure of the reply shows the actual
    ops executed and this list of the ops can therefore be obtained from
    the cache reply (yeah, it's just an SMOP :-) and compared to the 
    list of ops for the incoming request.  You would only have to do
    the work of extracting ops lists if the xid matched so the performance
    impact would be minimal, even if it involved duplicating work that
    you would normally do in a different fashion, later.

    Comparison of a hash of the request.  Except for writes, most requests
    are fairly short (< 1k) and a hash of the request, including all the
    ops and their operands could be quickly turned into a 32-or-64-bit-hash 
    and that hash saved in the request cache entry header and compared when
    there is xid match.  Even if you have long requests, hashing the first
    N bytes would work pretty well, given that the context is that we are
    trying to make an unsatisfactory situation, somewhat less unsatisfactory,
    and realize that we are not going to reach perfection.

Each of these is work but the CPU cost is low for most and virtually non-
existent for some, and servers can make appropriate trade-offs.  Another
possible problem is false negatives.  Can anybody conceive of situations 
in which a request should validly be considered a re-issue and not match on 
any of the discriminators above? 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Sunday, November 16, 2003 4:59 PM
To: [email-masked]
Subject: [nfsv4] recent server request cache

Hi,

I am concerned w.r.t. the possibility of a "false hit" on the server
recent request cache, if a client re-uses an xid (especially just
after a reboot). I've written a brief note on this that is available at
ftp://snowhite.cis.uoguelph.ca/pub/nfsv4/server-cache.notes, in case
anyone is interested.

In summary, I'm curious if there is an accepted practice for selecting
an xid value, especially just after a reboot? (RFC1831 doesn't have
much to say on the matter.)

Thanks for any comments, rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4