Subject: RE: SETCLIENTID issues (long)

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 22 Jul 2002 07:03:10 -0700

Peter Astrand wrote 
> (Btw, I think it's a bit odd that we must deal with low-level problems
> like Byzantine routers in a high-level operation like SETCLIENTID.  
> Currently, we have several different ways of protecting ourselves from
> re-sent packages and Byzantine routers: Duplicate Request Cache (which is
> far from perfect), sequence-id's, _CONFIRM-operations and verifiers.  Why
> not use a single mechanism for the entire v4 protocol?)

I think we would have been better off if we had done that.

One example of such an approach in an NFS-v4-based protocol is DAFS,
where a single mechanism does serve for all of those.  DAFS had the
issue of VI receive descriptor allocation (which necessitates limits
on the number of outstanding requests) and took advantage of that
(and the connected-oriented nature of the underlying transport) to
provide reliable deterministic reply cache behavior, which in turn
allows you dispose of all those odd individual mechanisms.

I believe that even though the receive-descriptor motivation is 
missing you could do something similar for NFS working on more
prosaic transports, although I think you are going to need some
extra mechanisms precisely at a SETCLIENTID-like phase where you
need to bootstrap the reply mechanism.

What's less clear to me is whether you could do something like
that within the constraints of a V4.x.  The obvious implementation
of this kind of thing would want a per-request stream number and
sequence-within-stream and the obvious implementation of that is
new fields in the COMPOUND which is precisely what you can't do in
an NFSv4.x.

At some point I'll write up something discussing this issue for the 
V4.1 wish list.