[nfsv4] Issue with EXCHANGE_ID case 4

<Noveck_David@emc.com> Mon, 19 July 2010 16:58 UTC

Return-Path: <Noveck_David@emc.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27F83A6B37 for <nfsv4@core3.amsl.com>; Mon, 19 Jul 2010 09:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgFQ0uCev5hT for <nfsv4@core3.amsl.com>; Mon, 19 Jul 2010 09:58:22 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 737223A6B00 for <nfsv4@ietf.org>; Mon, 19 Jul 2010 09:58:22 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o6JGwaIp014690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nfsv4@ietf.org>; Mon, 19 Jul 2010 12:58:36 -0400
Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for <nfsv4@ietf.org>; Mon, 19 Jul 2010 12:58:28 -0400
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o6JGwSEc012294 for <nfsv4@ietf.org>; Mon, 19 Jul 2010 12:58:28 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.41]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 12:57:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Jul 2010 12:57:06 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D8001D4402B@CORPUSMX50A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Issue with EXCHANGE_ID case 4
Thread-Index: AcsnY2skhv9lCTXtROyAzp1NVx7eqg==
From: Noveck_David@emc.com
To: nfsv4@ietf.org
X-OriginalArrivalTime: 19 Jul 2010 16:57:08.0036 (UTC) FILETIME=[6C2D8840:01CB2763]
X-EMM-EM: Active
Subject: [nfsv4] Issue with EXCHANGE_ID case 4
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jul 2010 16:58:23 -0000

There seems to be a problem with the way case 4 of section 18.35.4 is
written, as it affects trunking (also retry,  although that isn't the
focus of this message).

Color code:
*	Blue is material from RFC 5661
*	Red is material that I'm thinking addresses an issue in RFC 5661
and might potentially be text to be incorporated in an errata or other
explanation of how to deal with this issue.
*	Black is for ordinary discussion and asides

The context is that when trunking is potentially in effect the same
client may be issuing multiple EXCHANGE_ID requests to the same server
at the same time, so that there can be more than one outstanding at
once.  Once the EXCHANGE_ID is completed (i.e. the client has received
the response), then the client can serialize these using the clientid
sequence, but until it gets the server_owner values, he can't, since he
doesn't know that the two destinations are the same server.  This can
occur both when multiple IP's are able to be session-trunked or when
they can only clientid-trunked.

I think this issue needs to be explained, and my approach to this issue
would be described by the following paragraph, which would make sense
appearing following the sixth paragraph of section 18.35.3

	Note that because the client doing EXCHANGE_ID does not possess
the 
	server-owner information at the time the request is issued, it
is 
	possible that the client will issue multiple EXCHANGE_ID
requests to 
	the same server (as evidenced by eir_server_owner) before a
response
	is received for any.  In this situation, the server will send
multiple 
   responses containing zero in the EXCHGID4_FLAG_CONFIRMED_R flag and 
   the same seqid and clientid values.  Note that in this situation, the

   requirement that the clientid be confirmed applies to the clientid as
   whole and is not something that must be done for every EXCHANGE_ID 
   response.  In the case in which the eir_server_owner values of the 
   two responses differ as to so_minor_id (clientid trunking), there
will 
   be multiple CREATE_SESSION operations done and the first of these
will 
   confirm the clientid and be done with the eir_sequenceid value
returned
   in the EXCHANGE_ID responses, while the second, which can only be 
   done after the response for the first request is received, will be
done 
   with immediately following seqid value for the clientid.


Assuming that this is not prevented by something else that I'm not
thinking of, then let's look at case 4 in RFC 5661 section 18.35.4.

  4.  Replacement of Unconfirmed Record

          If the EXCHGID4_FLAG_UPD_CONFIRMED_REC_A flag is not set, and
          the server has the following unconfirmed record, then the
          client is attempting EXCHANGE_ID again

"again" suggests that we are dealing with something that happened after
he got the response to the first which isn't necessarily true.

                                                 on an unconfirmed
          client ID, perhaps due to a retry, 

If this is the case of a retry, then creating a new clientid seems like
the wrong thing to do.  If we have initial try A and retry B, we don't
know for sure which response will be processed.  Normally, it is B but
it can be A, and if it is A, the client will get a clientid that has
been stepped on.  Generally, we work to make sure that two retries of
the same request have the same effect as one and that the response is
the same for both.  Normally this is done via a response cache but where
you don't have that, you should do what you can to make handling fit
that paradigm.

          a client restart before
          client ID confirmation (i.e., before CREATE_SESSION was
          called),

That case can be clearly distinguished by looking for a different
verifier value. 

          or some other reason.

What is discussed above for instance.

          { ownerid_arg, *, *, old_clientid_ret, unconfirmed }

          It is possible that the properties of old_clientid_ret are
          different than those specified in the current EXCHANGE_ID.

And it's also possible that they are the same as in the case of a retry.

          Whether or not the properties are being updated, to eliminate
          ambiguity, the server deletes the unconfirmed record,
          generates a new client ID (clientid_ret), and establishes the
          following unconfirmed record:

          { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
          unconfirmed }

I'm suggesting that this action is only right for a subset of the
situations and that it would be better divided up as follows:

  4a.  Request Matching Unconfirmed Record

          If the EXCHGID4_FLAG_UPD_CONFIRMED_REC_A flag is not set, and
          the server has the following unconfirmed record, then the
          client has issues another EXCHANGE_ID on an unconfirmed client
          ID, perhaps due to a retry or to multiple EXCHANGE_ID requests
          being issued to different IP addresses in a situation in which
          trunking causes them to be handled by the same server. 

          { ownerid_arg, verifier_arg, principal_arg, clientid_ret, 
            unconfirmed }

          If the properties of clientid_ret are different from those 
          specified in the current EXCHANGE_ID, then this case does not 
          apply and the handling is as indicated below for case 4b.  
          Otherwise, the unconfirmed record is left as is and
clientid_ret 
          returned to the caller.

  4b.  Replacement of Unconfirmed Record

          If the EXCHGID4_FLAG_UPD_CONFIRMED_REC_A flag is not set, and
          the server has the following unconfirmed record, then the
          client is attempting EXCHANGE_ID again on an unconfirmed
          client ID, perhaps due to a client restart before client ID 
          confirmation (i.e., before CREATE_SESSION was called), or 
          some other reason.

          { ownerid_arg, *, *, old_clientid_ret, unconfirmed }

          It is possible that the properties of old_clientid_ret are
          different than those specified in the current EXCHANGE_ID.
          Whether or not the properties are being updated, to eliminate
          ambiguity, the server deletes the unconfirmed record,
          generates a new client ID (clientid_ret), and establishes the
          following unconfirmed record:

          { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
          unconfirmed }


Alternative ways of dealing with this issue?  Other comments?