From: Mike Eisler (mike@eisler.com)
Date: 12/20/02-04:24:11 PM Z
Message-ID: <3E03988B.1020003@eisler.com>
Date: Fri, 20 Dec 2002 14:24:11 -0800
From: Mike Eisler <mike@eisler.com>
Subject: Re: Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt
Nicolas Williams wrote:
>If the issue is encoding efficiency and there aren't going to be lots of
>octet streams per packet then PER is probably the best encoding. But a
>migration protocol will likely involve sending large numbers of large
>data chunks with fairly little header overhead, so that the inefficiency
>of XDR as an encoding will hardly matter. As Mike Eisler points out,
>the crypto overhead will be pretty hefty already, so will the encoding
>overhead be significant? (As long as XML is not used I'd say "no" :)
>
>
>
>If the efficiency of XDR does turn out to be an issue, couldn't the
>encoding be changed later? Switching to PER would involve using ASN.1
>instead of ONC RPC, of course, but the structure of the types might not
>change much... I rather suspect that noone in this WG will want to use
>ASN.1/PER though :) , so that leaves ONC RPC/XDR and what else? SSHv2 or TLS
>
The use of ASN.1 introduces huge barriers to entry.
XDR has an open source, free and *complete*
compiler. Can't say the same thing about ASN.1.
I'm suprised/skeptical to learn that PER/ASN.1 is
faster than XDR, but I don't claim to know
much about either.
>
>encodings?
>
SSH and TLS define an encoding language for themselves,
but not for their payloads. If there are SSH and TLS hardware
accelerators, then that's a point in their favor. If
not, what's the point?
>
>
>As for RPCSEC_GSS performance, it may be possible to use a single
>context to provide integrity/privacy for an entire stream, at the stream
>level, with each operation referencing a GSS context handle for
>authorization on the server side. No?
>
That's what I have in mind. I'll follow up today.
-mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:45 AM Z CST