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

Michael Ko <mkosjc@gmail.com> Mon, 20 August 2012 01:48 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 B90B921F863C for <storm@ietfa.amsl.com>; Sun, 19 Aug 2012 18:48:39 -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 BwbTrm4f0vyM for <storm@ietfa.amsl.com>; Sun, 19 Aug 2012 18:48:38 -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 AE17321F863B for <storm@ietf.org>; Sun, 19 Aug 2012 18:48:37 -0700 (PDT)
Received: by qcac10 with SMTP id c10so4659188qca.31 for <storm@ietf.org>; Sun, 19 Aug 2012 18:48:36 -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=yjiqQiH6AR7/gj+M+cZu7UnEA9UXMeZ8/JEaOP4/bWY=; b=bl3rMb1w7S96+zdpI6M6Y7Vrxx0gh8g0KETkwtffxMUFsFO1mF32tvoF8QLAJpvqa5 LfQbMeZgnPyAfTyZ39RO33GOA7LtuSxinaMwW0qcbxgWC/PiWvhar0t+Jqt1Tw3vzLsn h5ck9QPb2cXNbDpGo0sMHIOmc+2mFvHct3MDZg9FPJV62EDhwKDvY2WKB566B8BehebP QohdiMYH+9pPiHvMZEevS8QvijR+lTBwLF34sPU6y/I3ED8px/4yEQ2dVWYEtJeObbFx /eoOUqjzF38235In2aEkC/cUJonVd7OjPtB8ho0flzPqsxlcC3rC3/VDIBYv2rdnk9MD +hTQ==
MIME-Version: 1.0
Received: by 10.229.135.4 with SMTP id l4mr11406987qct.39.1345427316588; Sun, 19 Aug 2012 18:48:36 -0700 (PDT)
Received: by 10.229.231.205 with HTTP; Sun, 19 Aug 2012 18:48:36 -0700 (PDT)
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208F127E3@MX15A.corp.emc.com>
References: <CAP_=6dLGh8D_0WUeSLcej0QJ4_k2KPtxh_JZBy+HpEizrEjfFA@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71208F127E3@MX15A.corp.emc.com>
Date: Sun, 19 Aug 2012 18:48:36 -0700
Message-ID: <CAP_=6dKKntRy77oxMdmradM68aKTCCpAmhdeGG6d1FufqmwYEw@mail.gmail.com>
From: Michael Ko <mkosjc@gmail.com>
To: "Black, David" <david.black@emc.com>
Content-Type: multipart/alternative; boundary=00248c6a560e46c11104c7a8b5f9
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: Mon, 20 Aug 2012 01:48:39 -0000

Changed “must be able to deal with” to “needs to be able to deal with” as
suggested.

For the rest of the suggestions, I have created new text that replaces the
"new" text in section 5.1.3:

An initiator that conforms to [RFC5046] allocates connection resources
before seding the Login Request with the T (Transit) bit set to 1 and the
NSG (Next Stage) field set to FullFeaturePhase.  (For brevity, this is
referred to as "early" connection allocation.)  The current iSER
specification relaxes this requirement to allow an initiator to allocate
connection resources after it receives the final Login Response PDU from
the target.  (For brevity, this is referred to as "late" connection
allocation.)  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.

In the following summary where "late" connection allocation is practised,
an initiator that follows [RFC5046] is referred to as an "old" initiator;
otherwise it is referred to as a "new" initiator.  Similarly, a target that
does not support the iSERHelloRequired key (and responds with
"NotUnderstood" when negotiating the iSERHelloRequired key) is referred to
as an "old" target; otherwise it is referred to as a "new" target.  Note
that an "old" target can still support the iSER Hello exchanges but this
fact is not known by the initiator.  A "new" target can also respond with
"No" when negotiating the iSERHelloREquired key.  In this case its beahvior
with respect to "late" connection allocation is similar to an "old" target.

A "new" initiator will work fine with a "new" target.

For an "old" initiator and an "old" target, the failure by the initiator to
handle the number of unexpected iSCSI control-type PDUs that are sent by
the target before the buffer resources are allocated at the initiator can
result in the failure of the iSER session caused by closure of the
underlying RCaP connection.  For the "old" target, there is known
implementation that sends one unexpected iSCSI control-type PDU after
sending the final Login Response and then waits awhile before sending the
next one.  This tends to alleviate somewhat the buffer allocation problem
at the initiator.

For a "new" initiator and an "old" target, the failure by the initiator to
handle the number of unexpected iSCSI control-type PDUs that are sent by
the target before the buffer resources are allocated at the initiator can
result in the failure of the iSER session caused by closure of the
underlying RCaP connection.  A "new" initiator MAY choose to terminate the
connection; otherwise it SHOULD do one of the following:

1. Allocate the connection resources before sending the final Login Request
PDU.

2. Allocate one or more buffers for receiving unexpected control-type PDUs
from the target before sending the final Login Request PDU.  This reduces
the possibility of the unexpected control-type PDUs causing the RCaP
connection to close before the connection resources have been allocated.

For an "old" initiator and a "new" target, if the iSERHelloRequired key is
not negotiated, a "new" target MUST still respond with the iSER HelloReply
Message when it receives the iSER Hello Message.  If the iSERHelloRequired
key is negotiated to "No" or "NotUnderstood", a "new" target MAY choose to
terminate the connection; otherwise it SHOULD delay sending any unexpected
control-type PDUs until one of the following events has occurred:

1. A PDU is received from the initiator after it sends the final Login
Response PDU.

2. A system configurable timeout period, say one second, has expired.

Mike

On Mon, Aug 13, 2012 at 3:27 PM, Black, David <david.black@emc.com> wrote:

> Mike,****
>
> ** **
>
> Thanks for posting this new text, and I apologize for the delayed response
> -****
>
> too much “stuff” going on in Vancouver ...****
>
> ** **
>
> I think we could also use some additional text that summarizes the
> new/old, old/new****
>
> and new/new implementation interactions.  Some comments on your posted
> text ...****
>
> ** **
>
> > If the iSCSI Layer on the initiator side allocates the connection
> resources****
>
> > to support RCaP only after it receives the final Login Response PDU from
> the****
>
> > target, then it may not be able to handle the number of unexpected iSCSI
> ****
>
> > control-type PDUs (as declared by the MaxOutstandingUnexpectedPDUs key
> from****
>
> > the initiator) that can be sent by the target before the buffer resources
> ****
>
> > are allocated at the initiator side.  In this case the iSERHelloRequired
> key****
>
> > MUST be negotiated to Yes so that the initiator can allocate the
> connection****
>
> > resources before sending the iSER Hello Message.  See section 5.1.3 for
> more****
>
> > details.****
>
> ** **
>
> That “MUST be negotiated to Yes” seems wrong, as that can’t be done if the
> target****
>
> responds with NotUnderstood.  Also, that text doesn’t provide a
> sufficiently blunt****
>
> warning, IMHO - it ought to state that the consequences of “may not be
> able to****
>
> handle” include failure of the iSER session caused by closure of the
> underlying****
>
> RCaP connection.****
>
> ** **
>
> > As the iSERHelloRequired key is not defined in [RFC5046], an
> initiator/target****
>
> > must be able to deal with a target/initiator that does not understand
> the key****
>
> > or support the iSER Hello exchanges.
>
> ****
>
> That’s correct, although I would change:****
>
>  “must be able to deal with” ->“needs to be able to deal with”.****
>
> ** **
>
> > For a target, if the iSERHelloRequired key is not negotiated, it MUST
> still
> > respond with the iSER HelloReply Message when it receives the iSER Hello
> Message.****
>
> > If the iSERHelloRequired key is negotiated to No or NotUnderstood, a
> target MAY****
>
> > choose to terminate the connection; otherwise it SHOULD delay sending any
> ****
>
> > unexpected control-type PDUs until one of the following events has
> occurred:****
>
> >** **
>
> > 1. A PDU is received from the initiator after it sends the final Login
> Response PDU.
> >
> > 2. A system configurable timeout period, say one second, has expired.***
> *
>
> ** **
>
> That’s ok, I think additional text is needed somewhere to point out that
> there is****
>
> known target code that sends one PDU and then delays - that might go in
> the additional****
>
> summary text that I suggest above, and also should be included as part of
> the****
>
> rationale for:****
>
> ** **
>
> > For an initiator, if the iSERHelloRequired key is negotiated to No or
> NotUnderstood,****
>
> > it MAY choose to terminate the connection; otherwise it SHOULD do one of
> the following:
> >
> > 1. Allocate the connection resources before sending the final Login
> Request PDU.
> >
> > 2. Allocate one or more buffers for receiving unexpected control-type
> PDUs from****
>
> > the target before sending the final Login Request PDU.  This reduces the
> possibility
> > of the unexpected control-type PDUs causing the RCaP connection to close
> before****
>
> > the connection resources have been allocated.
>
> ****
>
> ** **
>
> Thanks,
> --David****
>
> ** **
>
> *From:* storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] *On Behalf
> Of *Michael Ko
> *Sent:* Tuesday, July 24, 2012 8:27 PM
> *To:* storm@ietf.org
> *Subject:* [storm] Proposed text changes for the connection allocation
> problem****
>
> ** **
>
> These are the changes I intend to incorporate into the existing draft to
> solve the connection allocation problem by using the iSER Hello exchanges.
> Please comment.
>
> 5.1.1  Initiator Behavior
>
> original:
>
> 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.
>
> replacement:
>
> 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 SHOULD request the iSER Layer to allocate
> the connection resources necessary to support RCaP by invoking the
> Allocate_Connection_Resources Operational Primitive.
>
> deleted:
>
> If the iSER Layer at the initiator is successful in allocating the
> connection resources necessary to support RCaP, the following events MUST
> occur in the specified sequence:  [The numbered items will be retained but
> without the numbering.]
>
> new:
>
> If the iSCSI Layer on the initiator side allocates the connection
> resources to support RCaP only after it receives the final Login Response
> PDU from the target, then it may not be able to handle the number of
> unexpected iSCSI control-type PDUs (as declared by the
> MaxOutstandingUnexpectedPDUs key from the initiator) that can be sent by
> the target before the buffer resources are allocated at the initiator
> side.  In this case the iSERHelloRequired key MUST be negotiated to Yes so
> that the initiator can allocate the connection resources before sending the
> iSER Hello Message.  See section 5.1.3 for more details.
>
> 5.1.3  iSER Hello Exchange
>
> new:
>
> The connection resources can be allocated at the initiator side after it
> has received the final Login Response PDU from the target.  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, the iSER Hello exchanges can be used.
> This allows the initiator to allocate the connection resources before
> sending the 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.
>
> As the iSERHelloRequired key is not defined in [RFC5046], an
> initiator/target must be able to deal with a target/initiator that does not
> understand the key or support the iSER Hello exchanges.
>
> For a target, if the iSERHelloRequired key is not negotiated, it MUST
> still respond with the iSER HelloReply Message when it recieves the iSER
> Hello Message.  If the iSERHelloRequired key is negotiated to No or
> NotUnderstood, a target MAY choose to terminate the connection; otherwise
> it SHOULD delay sending any unexpected control-type PDUs until one of the
> following events has occurred:
>
> 1. A PDU is received from the initiator after it sends the final Login
> Response PDU.
>
> 2. A system configurable timeout period, say one second, has expired.
>
> For an initiator, if the iSERHelloRequired key is negotiated to No or
> NotUnderstood, it MAY choose to terminate the connection; otherwise it
> SHOULD do one of the following:
>
> 1. Allocate the connection resources before sending the final Login
> Request PDU.
>
> 2. Allocate one or more buffers for receiving unexpected control-type PDUs
> from the target before sending the final Login Request PDU.  This reduces
> the possibility of the unexpected control-type PDUs causing the RCaP
> connection to close before the connection resources have been allocated.
>
> 10.1.3.4 iSER Protocol Errors
>
> original:
>
> Conversely, it is a protocol error if the iSER Hello Message is sent by
> the iSER Layer at the initiator when iSERHelloRequired is negotiated to
> "No".
>
> new:
>
> Conversely, if the iSER Hello Message is sent by the iSER Layer at the
> initiator when iSERHelloRequired is negotiated to "No", the iSER Layer at
> the target MAY treat this as a protocol error or respond with an iSER
> HelloReply Message.
>
> Mike****
>