Re: [storm] iSER - what to do

Alexander Nezhinsky <nezhinsky@gmail.com> Tue, 17 July 2012 18:44 UTC

Return-Path: <nezhinsky@gmail.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 0A58D21F869A for <storm@ietfa.amsl.com>; Tue, 17 Jul 2012 11:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfi327KsRFrR for <storm@ietfa.amsl.com>; Tue, 17 Jul 2012 11:44:58 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBE421F84BF for <storm@ietf.org>; Tue, 17 Jul 2012 11:44:58 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so835508ggn.31 for <storm@ietf.org>; Tue, 17 Jul 2012 11:45:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.60.12.8 with SMTP id u8mr4820992oeb.46.1342550746163; Tue, 17 Jul 2012 11:45:46 -0700 (PDT)
Received: by 10.182.183.101 with HTTP; Tue, 17 Jul 2012 11:45:46 -0700 (PDT)
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208DD882E@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>
Date: Tue, 17 Jul 2012 21:45:46 +0300
Message-ID: <CAEkHY=do10xhtgOUWwiJsQPvAL2QfSpF3FkFAKef+GvRuWj8=Q@mail.gmail.com>
From: Alexander Nezhinsky <nezhinsky@gmail.com>
To: david.black@emc.com
Content-Type: text/plain; charset=UTF-8
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 18:44:59 -0000

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