Re: [storm] iSER - what to do

Alexander Nezhinsky <> Tue, 17 July 2012 18:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A58D21F869A for <>; Tue, 17 Jul 2012 11:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tfi327KsRFrR for <>; Tue, 17 Jul 2012 11:44:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CBE421F84BF for <>; Tue, 17 Jul 2012 11:44:58 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so835508ggn.31 for <>; Tue, 17 Jul 2012 11:45:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lGWE6TZNnN3jTmmUNY99htsvy3mjmAFixLu9sK4sIx8=; b=f03O8HtIOTF102wy40k3BqLT8K9UIVBEPrdIb519xWqm1UIQqxJjMF4EbsCGK+nj28 dd0bK3wOEaXzQ13L3rqGPTTzOiCR2yUwl7VnJjs0gQXbPYMXQtfeRKe0bq83Ko1ijtDt w9Nw1Adtdq1ZItDVCcZkFP79bdl026btAa0LhQ5kN2drey4O/w9uG+N3otIlGeA7jHfu Hy0EMDow36xGqVct8VL7/l6QrKcNRtdF9zZzSYo6UlQ6SQHX7Hg6KB90ZLYN8FSIhNCR HwXI+Cro9h5lZ8dUOZ2I7vkU93gZaxYr6q8bzHN9AGVZLyG45vQ+T7JNUQaBnjvIcEkq Vjmw==
MIME-Version: 1.0
Received: by with SMTP id u8mr4820992oeb.46.1342550746163; Tue, 17 Jul 2012 11:45:46 -0700 (PDT)
Received: by with HTTP; Tue, 17 Jul 2012 11:45:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 17 Jul 2012 21:45:46 +0300
Message-ID: <>
From: Alexander Nezhinsky <>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [storm] iSER - what to do
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jul 2012 18:44:59 -0000

On Tue, Jul 17, 2012 at 4:20 AM,  <> 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.


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

I'm ok with this