Re: [nfsv4] Issue with EXCHANGE_ID case 4
<Noveck_David@emc.com> Mon, 19 July 2010 17:38 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 CF7623A680C for <nfsv4@core3.amsl.com>; Mon, 19 Jul 2010 10:38:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 OFVuQhUZAPXS for <nfsv4@core3.amsl.com>; Mon, 19 Jul 2010 10:38:33 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id F0E773A67AC for <nfsv4@ietf.org>; Mon, 19 Jul 2010 10:38:32 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o6JHckW0020116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nfsv4@ietf.org>; Mon, 19 Jul 2010 13:38:47 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for <nfsv4@ietf.org>; Mon, 19 Jul 2010 13:38:34 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o6JHcXvB029107 for <nfsv4@ietf.org>; Mon, 19 Jul 2010 13:38:33 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.41]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 13:38:33 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB2769.348D4665"
Date: Mon, 19 Jul 2010 13:38:31 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D8001D440A9@CORPUSMX50A.corp.emc.com>
In-Reply-To: <BF3BB6D12298F54B89C8DCC1E4073D8001D4402B@CORPUSMX50A.corp.emc.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] Issue with EXCHANGE_ID case 4
Thread-Index: AcsnY2skhv9lCTXtROyAzp1NVx7eqgABV1nw
References: <BF3BB6D12298F54B89C8DCC1E4073D8001D4402B@CORPUSMX50A.corp.emc.com>
From: Noveck_David@emc.com
To: Noveck_David@emc.com, nfsv4@ietf.org
X-OriginalArrivalTime: 19 Jul 2010 17:38:33.0023 (UTC) FILETIME=[355874F0:01CB2769]
X-EMM-EM: Active
Subject: Re: [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 17:38:37 -0000
Given that my last attempt to communicate has gotten gable by someone stepping on fonts and colors, I've attached the message as an html file. Let me know if this is not readable either. -----Original Message----- From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf Of Noveck_David@emc.com Sent: Monday, July 19, 2010 12:57 PM To: nfsv4@ietf.org Subject: [nfsv4] Issue with EXCHANGE_ID case 4 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? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] Issue with EXCHANGE_ID case 4 Noveck_David
- Re: [nfsv4] Issue with EXCHANGE_ID case 4 Noveck_David