Subject: Re: Tweaking NFSv4 to be friendlier to hardware

From: Brent Callaghan <[email-masked]>
Date: Tue, 10 Aug 1999 14:02:51 -0700 (PDT)

Constantine Sapuntzakis writes:
> typedef opaque message<>;
> 
> struct COMPOUND4args {
> 	message	oplist<>;
> 	utf8string tag;
> };
> 
> struct COMPOUND4resok {
> 	message data<>;
> 	utf8string tag;
> };

Having the tag at the end of the request won't work
very well for packet sniffers like snoop or tcpdump.
Being packet sniffers, they take each packet as it
comes and attempt to print what's in it.  They don't
do any fragment reassembly.  If a request spans
multiple fragments - the later fragments are not
interpreted since all the interesting information
is normally near the front of the packet.  

I think we should keep the tag at the front of
the request/reply for now.  If we complete our
prototype implementations and nobody has found it useful,
then we can get rid of it entirely.  I think we will 
find it useful.

As for putting a byte count at the front of each message
and reply - I repeat my claim that it increases the size
of messages and complicates XDR encoding of the requests/replies.
The net affect is negative for all implementations that do
not use hardware pre-processing. 

For instance, to XDR an integer and a string currently we do
something like this in pseudo-XDR:

	xdr_int(i);
	xdr_int(s);

To prepend the length we have to back-patch,
i.e. insert space for the count, xdr the
integers, then go back and patch in the length
when you know it:

	pos1 = xdr_getpos();
	xdr_int(0);  // space for count
	xdr_int(i);
	xdr_string(s);
	pos2 = xdr_getpos();
	xdr_setpos(pos1);
	xdr_int(pos2 - pos1);
	xdr_setpos(pos2);

Of course, this is all a complete waste of time
if no client or server implementation actually
uses it.

I'd feel more positive about this if someone were
actually building a hardware preprocessor and bringing
it to the bakeoff....

	Brent

---

From: Guy Harris <[email-masked]>
Date: Tue, 10 Aug 1999 14:22:53 -0700 (PDT)

> do any fragment reassembly.

Well, *some* packet sniffers don't do fragment reassembly (or TCP
segment reassembly).

I've found that to be an annoying deficiency in the UNIX packet sniffers
I've used (having had to dissect a multiple-frame READDIR reply on
occasion), and, at some point, plan to fix that deficiency in Ethereal:
(it currently does some limited TCP segment reassembly, but no IP
fragment reassembly; it doesn't do ONC RPC protocols such as NFS yet,
but I also hope to fix that...).

I have the impression a Network General^H^H^H^H^H^H^HAssociates
Sniffer(TM) might handle multiple-frame requests and responses.

I'm not sure one should use the deficiencies of existing packet sniffers
as an argument against putting information at the end of a request or
response that may require multiple frames.