From: Robert Thurlow (Robert.Thurlow@eng.sun.com)
Date: 12/19/02-12:48:47 PM Z
Date: Thu, 19 Dec 2002 11:48:47 -0700 (MST) From: Robert Thurlow <Robert.Thurlow@eng.sun.com> Subject: Re: Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt Message-ID: <Roam.SIMC.2.0.6.1040323727.17415.thurlow@jurassic.eng> Hi Mike, Again, thanks, and comments inline. > Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt > > This goes back to the design i-d, where it stated, without > too much justification, that RPC would not be used in > transfer protocol. In looking at the strawman protocol, I > see a whole lot of stuff unspecified, that RPC would have > taken care of automatically ... > I also see that in this non-RPC protocol, many if not all > of the operations have confirmation messages. Every message is intended to have a confirm of some kind, except for ABORT_SESSION, because the expectation is that the connection would be closed after it was sent. > I realize that some of the things I'm observing are a > result of this being a strawman, but I can also see us > getting bogged down in specifying what is effectively a > layer in the protocol stack, when we already have one, ONC > RPC, to use today. Time is of the essence. So let's open this up for discussion. Suppose we make at least a first attempt (in the Connectathon 2003 timeframe) with an RPC-based protocol, based on this strawman. Does that make sense for others who might want to try this at C-thon 2003? I can certainly be convinced, because I have less time for prototyping than I'd initially hoped. What about some of the other design team folks? > In section 2.2, the RMmessage_id type ... does the first > message in a session start at zero? Likely; shoulda been specified. > In section 2.5 (and section 7), why is the nfsace4 type > imported from nfsv4? If the other attribute types aren't > importanted, there should be no need for the ace type. I brought in fattr4's as well; I wanted to use them verbatim when we're working with NFSv4 metadata. > In section 4.4, regarding the RM_UTF8NAMES capability flag, > why doesn't the nfsv4 migration protocol assume UTF8 file names? > So why does this bit need to exist? What I was thinking about here was to try to encode if the server supports arbitrarily complex UTF8 names, or if they will be mapped to something like simple ASCII. The hope was that the source server could know this early on and inform the admin that metadata might be impacted on this destination server. > Regarding the RM_FHPRESERVE capability, unless the source > and target know the fh format, this capability seems useless. > Since NFSv4 defines file handles as opaque, the capability is > indeed useless, unless source and target know they have compatible > file handles. My suggestion: > > Include in the OPEN_SESSION_NEW arguments a field > of type utf8str_cis (from the nfsv4 spec) which is > a dns domain name that serves as an > "implementation" identifier to uniquely and > unambiguously identifies the file handle format. If > a particular implementer has multiple fh formats > (e.g. because it has both big endian and little > endian platform support), then it can use multiple > domain names or subdomain names. If the source and > target have different domain names, it is still > possible the target understands the source's file > handle format, and it can still turn on the > PRESERVE capability. Yes, this was underspecified and you have pointed towards a way out. I had also thought (fantasized?) about trying to encode the way the filehandle was put together - i.e., these bytes are invariant in this filesystem, these bits represent the specific file, and these bits represent the share point. The biggest problem is that this assumes a filehandle will consist of all of these parts, which is probably not sufficiently general. > Does RM_FHPRESERVE also imply preservation of fileid? For domains where it is useful, it probably will, but I don't know if it should be specified so. > On a related note, preservation of directory cookies is > another capability that would be good to support. Agreed - I hadn't thought about that. > Also, since RM_FHPRESERVE might not be supported, it > implies, to me at least, that any server planning on > supporting the source side of this this protocol and > currently returning a value of FH4_PERSISTENT in the > fh_expire_type attribute should instead warn its NFSv4 > clients up front, and return the FH4_VOL_MIGRATION bit. > Otherwise, clients will be out of luck when their data is > migrated away. Definitely agreed. > In Section 5.1, Data transfer phase messages, shouldn't > there be a SEND_DELEGATION_STATE message as well? Possibly helpful; I'd expected we'd recall delegations just before pushing the final set of changes, and not issue new delegations until completion. > In section 5.3 there is a RM_CIFS_ATTR type. Why is this > needed? This is the NFSv4 migration protocol, and in any > case, the set of NFSv4 attributes is rich enough to > encompass what Windows environments need. That's there so that vendors that sell multi-protocol servers can express any CIFS attributes we can't encode with NFSv4, and to illustrate the intent that we're not supporting NFSv4 only, just NFSv4 first. If this is not useful, it can go, but I'd like to maintain support for alternate attribute "profiles" in the future. > In section 5.8 SEND_RENAME, it seems that a SEND_LINK > message is also needed. Agreed. > In section 5.12, CONFIRM_MESSAGE, it says CONFIRM_MESSAGE > is used to confirm every data transfer message. First this > certainly looks like RPC. But second, I don't think it is > desirable to confirm every data transfer message, because > while I think ONC RPC should be used beneath this protocol, > I also think there is benefit to a paradigm that doesn't > ACK each and every message from the target. Instead, delete > CONFIRM_MESSAGE, and replace with with a true RPC that > allows the source to ask the target the sequence number of > the last data transfer message it has received. > > SEND_CHECKPOINT though, ought to be a traditional RPC. Good points; more fodder for just using RPC. > In section 6.3, ABORT_SESSION overloading ABORT_SESSION to > be both the confirmation from the target, or an initiated > message from the target is going to make implementation > complex. Just have two different message types, or better > yet, RPCs. (and make CLOSE_SESSION an RPC as well). How does the destination perform an abort? Do we have to define that the source implement a server side to receive it? > Section 6.2 implies that if a session is explicitly aborted > via ABORT_SESSION, it can later be resumed. It seems to me > that there ought to be an operation to allow the source to > tell the target that the session will not be resumed, and > another operation to tell the source that the target is > aborting and it will not maintain the previous state: > resumption is futile. Maybe this can be done with specific > error codes, but specific operations seems less error > prone. I guess I expect the abort stuff to be in a crisis handler, where a lot of computation is not welcome. The implementation could advertise if it can do restart or not at connection time, which might accomplish enough here - would that work? > In section 7 and else where, what are the definitions of the > various compression types? Do the compression types only > apply to the data field of the SEND_FILE_DATA operation. Underspecified again, and yes. > Other things that were covered in the specification: > > - the checkpointing model makes it obvious what the recovery > model is when the target dies, but what happens when the > source dies? How long must the target maintain the state > (and disk space) of the incomplete transfer? > Perhaps this should be negotiated when the session > is first created. Agreed on the latter point. > - the protocol does not have any message types for telling > the source to start to do the referral. Is this > implied by confirmation of the CLOSE_SESSION message? That was my assumption; one further message/RPC to verify that the destination is ready for this might be in order. > - Can there be multiple sessions per TCP connection? I'd prefer separate TCP connections for separate sessions. > - Presumably this protocol requires an IETF approved > congestion management transport, so TCP is the > required transport. Yes; I thought I had specified that somewhere. Rob T
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:42 AM Z CST