Re: [storm] Proposed text changes for the connection allocation problem

Michael Ko <mkosjc@gmail.com> Sun, 16 September 2012 17:19 UTC

Return-Path: <mkosjc@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 E059721F8530 for <storm@ietfa.amsl.com>; Sun, 16 Sep 2012 10:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OCmbpPuppGh for <storm@ietfa.amsl.com>; Sun, 16 Sep 2012 10:19:40 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4E7521F852E for <storm@ietf.org>; Sun, 16 Sep 2012 10:19:39 -0700 (PDT)
Received: by qcac10 with SMTP id c10so4631686qca.31 for <storm@ietf.org>; Sun, 16 Sep 2012 10:19:39 -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=bQ4PcmyogK5naPheh75sL+yQ1aEZ61C/ZhhHATU459A=; b=DfDUDqw1IEsGl69CxhBIS5CNuRlKg5rPSgNIHboPpLdWnIy5HnXWDDTrO2bgp8584t /K5WjXJg3/XhiBDain/OjefhJhQPzp1udf7Z/vgNB2SkEFMsbqHp1FrF8CKKfIaukkD9 KtYccl7etwjOlSwgfwMpzlMmnH/zY31z42lzLqFCOXALXVQZc9puVwafg4Gg0e6fazDA AoImCAUHLjnIukvTFVXHhoqq474yGjyii92zP/j2ftoUs6WOTWMirJK3D0+vCWHqLupX dWWbjucmDQMTw7vUgkNqHR9gYw1LNmYAjJWbN6S1E7RCX4ZN/CXkW0D4rZvt8/WfB9eY 8JAA==
MIME-Version: 1.0
Received: by 10.224.203.193 with SMTP id fj1mr22219569qab.13.1347815979193; Sun, 16 Sep 2012 10:19:39 -0700 (PDT)
Received: by 10.229.231.205 with HTTP; Sun, 16 Sep 2012 10:19:39 -0700 (PDT)
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120DCD1566@MX15A.corp.emc.com>
References: <CAP_=6dLGh8D_0WUeSLcej0QJ4_k2KPtxh_JZBy+HpEizrEjfFA@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71208F127E3@MX15A.corp.emc.com> <CAP_=6dKKntRy77oxMdmradM68aKTCCpAmhdeGG6d1FufqmwYEw@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE7120DCD1566@MX15A.corp.emc.com>
Date: Sun, 16 Sep 2012 10:19:39 -0700
Message-ID: <CAP_=6d+mNeVHu61Hg3xkfTAaCiHdp-_JOz1CWbP5NtVP=g=hsg@mail.gmail.com>
From: Michael Ko <mkosjc@gmail.com>
To: "Black, David" <david.black@emc.com>
Content-Type: multipart/alternative; boundary=20cf30051232a994f404c9d4dc2c
Cc: "storm@ietf.org" <storm@ietf.org>
Subject: Re: [storm] Proposed text changes for the connection allocation problem
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: Sun, 16 Sep 2012 17:19:41 -0000

David,

I have submiited a new version of the iSER draft incorporating all the
latest changes so far, including your recommendations below.  I have also
reword item #7 in the summary of changes to reflect the new use of the
iSERHelloRequired key.

Mike

On Fri, Sep 14, 2012 at 5:25 PM, Black, David <david.black@emc.com> wrote:

> Mike,****
>
> ** **
>
> I apologize for the delay in getting to this.  I think your latest text is
> close to what’s****
>
> needed, but I want to rewrite the latter part of your second paragraph for
> clarity and to****
>
> remove a “MUST” that appears easy to misinterpret (IMHO):****
>
> ** **
>
> OLD****
>
>    To prevent the potential problem caused by the target sending the
> number of****
>
>    unexpected iSCSI control-type PDUs as determined by the
> MaxOustandingUnexpectedPDUs****
>
>    key allowed in the FullFeaturePhase when "late" connection allocation
> is practised,****
>
>    the iSER Hello exchanges MUST be used.  This allows the initiator to
> allocate the****
>
>    connection resources before sending the iSER Hello Messages.  The
> iSERHelloRequired****
>
>    key is used by the initiator to determine if it is dealing with a
> target that****
>
>    supports the iSER Hello exchanges.****
>
> NEW
>    An initiator that employs “late” connection allocation may encounter
> problems (e.g.,****
>
>    RCaP connection closure) with a target that sends unexpected iSCSI PDUs
> immediately****
>
>    upon transitioning to Full Feature Phase, as allowed by the negotiated
> value of the****
>
>    the MaxOustandingUnexpectedPDUs key.  The only way to prevent this
> situation in ****
>
>    full generality is to use iSER Hello Messages, as they enable the
> initiator to allocate****
>
>    its connection resources before sending its iSER Hello Message.  The
> iSERHelloRequired****
>
>    key is used by the initiator to determine if it is dealing with a
> target that****
>
>    supports the iSER Hello exchanges.  Fortunately, known iSER target
> implementations****
>
>    do not take full advantage of the number of allowed unexpected PDUs
> immediately upon****
>
>    transition into full feature phase, enabling an initiator workaround
> that involves****
>
>    a smaller quantity of connection resources prior to full-feature phase,
> as explained****
>
>    further below.****
>
> END****
>
> ** **
>
> Would you please go ahead and submit a revised version of the draft with
> the text changes****
>
> that we’ve agreed to.  I’ll want to review the changes one more time in
> the context of an****
>
> entire draft before (finally) sending it to our AD with a request to
> publish it as an RFC.****
>
> ** **
>
> Thank you for your patience with this.****
>
> ** **
>
> Thanks,
> --David****
>