Re: [storm] iSER - what to do

<david.black@emc.com> Tue, 17 July 2012 19:57 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B930D21F8621 for <storm@ietfa.amsl.com>; Tue, 17 Jul 2012 12:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.49
X-Spam-Level:
X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9-BKUBAy0oL for <storm@ietfa.amsl.com>; Tue, 17 Jul 2012 12:57:24 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1819D21F86FC for <storm@ietf.org>; Tue, 17 Jul 2012 12:57:23 -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.4.3/Switch-3.4.3) with ESMTP id q6HJw9eo020362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2012 15:58:09 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 17 Jul 2012 15:57:54 -0400
Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6HJvsKg003929; Tue, 17 Jul 2012 15:57:54 -0400
Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Tue, 17 Jul 2012 15:57:54 -0400
From: <david.black@emc.com>
To: <mkosjc@gmail.com>
Date: Tue, 17 Jul 2012 15:57:51 -0400
Thread-Topic: [storm] iSER - what to do
Thread-Index: Ac1kT3Uzbd1tgTEcQhi1cB7kUBqG1QABbz0g
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208DD8957@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71208C14966@MX15A.corp.emc.com> <CAP_=6d+-VfyBOOP4pudwqZxy6dtRD=OPzeZ=W3br=KkPJGfnoQ@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71208C14A8F@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208D3B0CA@MX15A.corp.emc.com> <CAEkHY=esUJWgBoosDVLaoBnQLy0BH-v0gb0+z60AuoimXtCKag@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71208DD882E@MX15A.corp.emc.com> <CAEkHY=do10xhtgOUWwiJsQPvAL2QfSpF3FkFAKef+GvRuWj8=Q@mail.gmail.com> <CAP_=6d+pLvve9VOmbTHayR9tbHr0fLdskG4fFA6kWtmV+fCkpw@mail.gmail.com>
In-Reply-To: <CAP_=6d+pLvve9VOmbTHayR9tbHr0fLdskG4fFA6kWtmV+fCkpw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE71208DD8957MX15Acorpemccom_"
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: storm@ietf.org
Subject: Re: [storm] iSER - what to do
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2012 19:57:28 -0000

Mike,

In particular, we need to say that a new target MUST respond to iSERHello with iSERHello when the iSERHelloRequired key was omitted from the negotiation.  OTOH, if iSERHelloRequired was negotiated to No, target receipt of iSERHello indicates a protocol error by the initiator - the target MAY choose to treat that as an error (e.g., and close the RCaP connection) or the target MAY choose to continue by responding with an iSERHello.

We need to state a recommended timeout value, at least as a default.  1 second seems like a reasonable default, and it could be adjusted via other means (e.g., system configuration).  There's no need to state a single value that MUST be used in all implementations.

I believe the quoted text has to be changed to align with this discussion.

Thanks,
--David

From: Michael Ko [mailto:mkosjc@gmail.com]
Sent: Tuesday, July 17, 2012 3:07 PM
To: Alexander Nezhinsky
Cc: Black, David; storm@ietf.org
Subject: Re: [storm] iSER - what to do

An ""old" home-grown initiator implementation which will not send iSERHelloRequired=Yes but will send iSERHello" should not cause any problems.  An old target which does not support iSERHello will fail.  A new target will assume it is dealing with an old initiator which does not use iSERHello and will act according to the new spec for dealing with old initiators.  So when iSERHello shows up, it will follows the new spec for dealing with new initiators.

There are two other issues which need to be resolved.

1. Should the spec say anything about the timeout value?  I agree with Alex that there is no practical value that will work in all cases.  So how about simply stating that the timeout values is outside the scope of the document?

2. In the current iSER spec, section 5.1.1 states that:

"If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, then on the initiator side, prior to sending the Login Request with the T (Transit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase, the iSCSI Layer MUST request the iSER Layer to allocate the connection resources necessary to support RCaP by
invoking the Allocate_Connection_Resources Operational Primitive."

Should the MUST requirement be weakened to a SHOULD as MaxOutstandingUnexpectedPDUs will not be allocated beofre Login Request is sent?

Mike
On Tue, Jul 17, 2012 at 11:45 AM, Alexander Nezhinsky <nezhinsky@gmail.com<mailto:nezhinsky@gmail.com>> wrote:
On Tue, Jul 17, 2012 at 4:20 AM,  <david.black@emc.com<mailto:david.black@emc.com>> wrote:
> We can update the spec now - what do you think a reasonable timeframe
> is to push out that code?

I can estimate that the target part can be ready within a month.
It's harder for me to make a correct estimation about the initiator.
But I would bet on a similar time frame.

>From there it should be taken up by the distributions. Each one has
its own pace.
At least RHEL 6.3 was released a couple of weeks ago, so if all goes
well we can
be pretty sure that the changes are included in RH 6.4.

>>    As we are trying to neutralize the shortcomings of the existing
>>    targets, the initiator can bet that the target won't send split
>>    login responses, as it regularly does not do so today.
>
> Ok, this does need to be stated as something that existing targets
> do not do.

Hmm, my second thought is that this may be incorrect in general.
They don't do it in a "normal" setup, where the initiator sends a
small number of keys,
so the target answers with the response of a comparable size.
I need to check how well split responses are generated and tolerated right now.
Probably we should not bet on their absence anyway.

>> 4. "New" target will recognize an "old" initiator by having received
>>    iSERHelloRequired=No either implicitly or explicitly.
>
> "implicitly or explicitly" means either iSERHelloRequired was not
> received or iSERHelloRequired=No was received.  Both cases MUST be
> treated in the same fashion.
>
>>    Then it must
>>    ignore the iSERHello absence
>
> Those aren't the right words.  The target knows that iSERHello will
> not be used - it can choose to terminate the negotiation without setting
> up iSER.

At least in theory, there could be an "old" home-grown initiator implementation
which will not send  iSERHelloRequired=Yes but will send iSERHello.
Should not we allow this ?

> ... then the target SHOULD do one of the following:
>
>>    * delaying sending any "unexpected" PDUs until the first PDU is
>>      received from the initiator after the final login response
>>      has been sent
>>    * taking a reasonable timeout, say a second (the exact value
>>      does not matter as the initiator can't count on it anyway and
>>      no value will solve the problem in full, theoretically).
>>    * doing both, that is waiting for the first incoming PDU and
>>      taking a timer to start sending NOP-INs in case no PDUs arrived
>>      during the timeout period, to be able to detect silent connection
>>      failures.
>
> I believe the second and third bullets ought to be combined, in that
> receipt of a PDU is sufficient reason to end the timeout period before
> it would otherwise expire.

I agree

>
>> 5. "New" target and "new" initiator will count on iSERHello as the
>>    guarantee of proper buffer posting
>>
>> 6. "Old" target and "old" initiator will work as they do now, in their
>>    double bliss of ignorance.
>
> We also need to issue a warning about the latter combination risking
> RCaP session termination if unsolicited PDUs show up from the target
> before the initiator is ready.

Ok

> If the above looks close to correct, we can start working on text for
> the draft ...

I'm ok with this

Alexander
_______________________________________________
storm mailing list
storm@ietf.org<mailto:storm@ietf.org>
https://www.ietf.org/mailman/listinfo/storm