From david.black@emc.com Wed Aug 8 09:17:42 2012 Return-Path: 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 CF87F11E80C5 for ; Wed, 8 Aug 2012 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, 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 lwzoMw3-PpvJ for ; Wed, 8 Aug 2012 09:17:41 -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 DCAD711E80D5 for ; Wed, 8 Aug 2012 09:17:40 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q78GHdqM016678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Aug 2012 12:17:39 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Wed, 8 Aug 2012 12:17:31 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q78GHUBs017803 for ; Wed, 8 Aug 2012 12:17:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Wed, 8 Aug 2012 12:17:29 -0400 From: "Black, David" To: "storm@ietf.org" Date: Wed, 8 Aug 2012 12:17:28 -0400 Thread-Topic: iSCSI - exchange count Thread-Index: Ac1ZOXxpax03poRETBq12DKtgGMvyAcR0LaA Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208E80699@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208D3ACC3@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3ACC3@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [storm] iSCSI - exchange count X-BeenThere: storm@ietf.org 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: Wed, 08 Aug 2012 16:17:42 -0000 > The important question is: Is "6" the right number of exchanges that SHOU= LD be > allowed? There's nothing special about that number ... it "seemed like a= good idea at > the time". Here's a little more detail/insight into the thinking behind the number 6, = in the hope of engendering discussion ... this is about the overall login, not just number of exchanges for an individual text key. I see value in the fact that 6 is significantly larger than 3, as 3 would b= e too small. I see some value in guiding implementers to think about a larger number. W= hile 6 is arbitrary, there does seem to be a range here - I would have no problem wit= h 7 or 5, but both 3 and 10 seem unreasonable. Also, I'm passing along an off-list editorial suggestion: > An iSCSI initiator or target MAY terminate a negotiation that does not > terminate within an implementation-specific reasonable time or number of > exchanges, but SHOULD allow at least 6 exchanges. The use of "terminate" twice in the above sentence with different meanings = is a bit peculiar. The second instance of "terminate" should be changed to "complet= e" so that the new text would be: An iSCSI initiator or target MAY terminate a negotiation that does not complete within an implementation-specific reasonable time or number of exchanges, but SHOULD allow at least 6 exchanges. Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of > david.black@emc.com > Sent: Tuesday, July 03, 2012 12:33 PM > To: storm@ietf.org > Subject: [storm] iSCSI - exchange count > Importance: High >=20 > >=20 > I wanted to extract this change from Mallikarjun's long list of normative > changes to call it out for attention. >=20 > The important question is: Is "6" the right number of exchanges that SHOU= LD be > allowed? > There's nothing special about that number ... it "seemed like a good idea= at > the time". >=20 > Alternate suggestions are welcome, especially if this change could cause = any > problems for current implementations. >=20 > Section 6.2 > [from] > An iSCSI initiator or target MAY terminate a negotiation that does not en= d > within a reasonable time or number of exchanges. >=20 > [to] > An iSCSI initiator or target MAY terminate a negotiation that does not > terminate within an implementation-specific reasonable time or number of > exchanges, but SHOULD allow at least 6 exchanges. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Mon Aug 13 15:27:59 2012 Return-Path: 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 9D24B21F8620 for ; Mon, 13 Aug 2012 15:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.111, 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 OvW4iXXlpahY for ; Mon, 13 Aug 2012 15:27:55 -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 65BD521F84CE for ; Mon, 13 Aug 2012 15:27:54 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7DMRoKX010462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2012 18:27:51 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 13 Aug 2012 18:27:36 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7DMRa4s009987; Mon, 13 Aug 2012 18:27:36 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Mon, 13 Aug 2012 18:27:36 -0400 From: "Black, David" To: Michael Ko , "storm@ietf.org" Date: Mon, 13 Aug 2012 18:27:35 -0400 Thread-Topic: [storm] Proposed text changes for the connection allocation problem Thread-Index: Ac1p/Erbt/+tI1jERi+X6Dsu9vzZJgPoa0Ag Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208F127E3@MX15A.corp.emc.com> References: In-Reply-To: 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_8D3D17ACE214DC429325B2B98F3AE71208F127E3MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 22:27:59 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE71208F127E3MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 resourc= es > 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 fr= om > 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 connecti= on > resources before sending the iSER Hello Message. See section 5.1.3 for m= ore > 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 sufficientl= y 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 underl= ying RCaP connection. > As the iSERHelloRequired key is not defined in [RFC5046], an initiator/ta= rget > 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 sti= ll > respond with the iSER HelloReply Message when it receives the iSER Hello = Message. > If the iSERHelloRequired key is negotiated to No or NotUnderstood, a targ= et MAY > choose to terminate the connection; otherwise it SHOULD delay sending any > unexpected control-type PDUs until one of the following events has occurr= ed: > > 1. A PDU is received from the initiator after it sends the final Login Re= sponse 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 th= ere 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 t= he rationale for: > For an initiator, if the iSERHelloRequired key is negotiated to No or Not= Understood, > 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 Reque= st PDU. > > 2. Allocate one or more buffers for receiving unexpected control-type PDU= s 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 M= ichael Ko Sent: Tuesday, July 24, 2012 8:27 PM To: storm@ietf.org Subject: [storm] Proposed text changes for the connection allocation proble= m These are the changes I intend to incorporate into the existing draft to so= lve the connection allocation problem by using the iSER Hello exchanges. P= lease comment. 5.1.1 Initiator Behavior original: If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, th= en on the initiator side, prior to sending the Login Request with the T (Tr= ansit) 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 res= ources necessary to support RCaP by invoking the Allocate_Connection_Resour= ces Operational Primitive. replacement: If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, th= en on the initiator side, prior to sending the Login Request with the T (Tr= ansit) 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 r= esources necessary to support RCaP by invoking the Allocate_Connection_Reso= urces Operational Primitive. deleted: If the iSER Layer at the initiator is successful in allocating the connecti= on resources necessary to support RCaP, the following events MUST occur in = the specified sequence: [The numbered items will be retained but without t= he 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 t= he target, then it may not be able to handle the number of unexpected iSCSI= control-type PDUs (as declared by the MaxOutstandingUnexpectedPDUs key fro= m the initiator) that can be sent by the target before the buffer resources= are allocated at the initiator side. In this case the iSERHelloRequired k= ey MUST be negotiated to Yes so that the initiator can allocate the connect= ion 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 ha= s received the final Login Response PDU from the target. To prevent the po= tential problem caused by the target sending the number of unexpected iSCSI= control-type PDUs as determined by the MaxOustandingUnexpectedPDUs key all= owed in the FullFeaturePhase, the iSER Hello exchanges can be used. This a= llows 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 exch= anges. As the iSERHelloRequired key is not defined in [RFC5046], an initiator/targ= et must be able to deal with a target/initiator that does not understand th= e 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 M= essage. 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 Resp= onse PDU. 2. A system configurable timeout period, say one second, has expired. For an initiator, if the iSERHelloRequired key is negotiated to No or NotUn= derstood, 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 t= he possibility of the unexpected control-type PDUs causing the RCaP connect= ion 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 init= iator when iSERHelloRequired is negotiated to "No", the iSER Layer at the t= arget MAY treat this as a protocol error or respond with an iSER HelloReply= Message. Mike --_000_8D3D17ACE214DC429325B2B98F3AE71208F127E3MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 s= ummarizes the new/old, old/new

and ne= w/new implementation interactions.  Some comments on your posted text = ...

 

> If the iSCSI Layer on the initiator side allocates the con= nection resources

> to support RCa= P only after it receives the final Login Response PDU from the

> target, then it may not be able to handle th= e number of unexpected iSCSI

> con= trol-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 iSERHel= loRequired key

> MUST be negotiate= d 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 p= rovide 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.

&n= bsp;

> As the iSERHelloRequired key is = not defined in [RFC5046], an initiator/target

> must be able to deal with a target/initiator that does not un= derstand the key

> or support the = iSER Hello exchanges.

That= 217;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.<= o:p>

> If the iSERHelloRequired key is = negotiated to No or NotUnderstood, a target MAY

> choose to terminate the connection; otherwise it SHOULD del= ay sending any

> unexpected contro= l-type PDUs until one of the following events has occurred:

> 

>= ; 1. A PDU is received from the initiator after it sends the final Login Re= sponse PDU.
>
> 2. A system configurable timeout period, say on= e 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 th= at 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,<= /span>

> it MAY choose to terminate the connection; = otherwise it SHOULD do one of the following:
>
> 1. Allocate t= he 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 cl= ose before

> the connection resour= ces have been allocated.

=  

Thanks,
--David

 

From: storm-bounces@ietf.org [mailto:storm-bo= unces@ietf.org] On Behalf Of Michael Ko
Sent: Tuesday, Jul= y 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 inco= rporate 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 neg= otiation 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 t= he iSER Layer to allocate the connection resources necessary to support RCa= P by invoking the Allocate_Connection_Resources Operational Primitive.
<= br>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 s= et to FullFeaturePhase, the iSCSI Layer SHOULD request the iSER Layer to al= locate the connection resources necessary to support RCaP by invoking the A= llocate_Connection_Resources Operational Primitive.

deleted:

= If the iSER Layer at the initiator is successful in allocating the connecti= on resources necessary to support RCaP, the following events MUST occur in = the specified sequence:  [The numbered items will be retained but with= out the numbering.]

new:

If the iSCSI Layer on the initiator = side allocates the connection resources to support RCaP only after it recei= ves the final Login Response PDU from the target, then it may not be able t= o handle the number of unexpected iSCSI control-type PDUs (as declared by t= he 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 th= e 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 R= esponse PDU from the target.  To prevent the potential problem caused = by the target sending the number of unexpected iSCSI control-type PDUs as d= etermined by the MaxOustandingUnexpectedPDUs key allowed in the FullFeature= Phase, the iSER Hello exchanges can be used.  This allows the initiato= r to allocate the connection resources before sending the iSER Hello Messag= e.  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/tar= get must be able to deal with a target/initiator that does not understand t= he key or support the iSER Hello exchanges.

For a target, if the iSE= RHelloRequired key is not negotiated, it MUST still respond with the iSER H= elloReply Message when it recieves the iSER Hello Message.  If the iSE= RHelloRequired key is negotiated to No or NotUnderstood, a target MAY choos= e to terminate the connection; otherwise it SHOULD delay sending any unexpe= cted control-type PDUs until one of the following events has occurred:
<= br>1. A PDU is received from the initiator after it sends the final Login R= esponse PDU.

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

For an initiator, if the iSERHelloRequired key is neg= otiated to No or NotUnderstood, it MAY choose to terminate the connection; = otherwise it SHOULD do one of the following:

1. Allocate the connect= ion resources before sending the final Login Request PDU.

2. Allocat= e one or more buffers for receiving unexpected control-type PDUs from the t= arget before sending the final Login Request PDU.  This reduces the po= ssibility of the unexpected control-type PDUs causing the RCaP connection t= o 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 ini= tiator when iSERHelloRequired is negotiated to "No", the iSER Lay= er at the target MAY treat this as a protocol error or respond with an iSER= HelloReply Message.

Mike

= --_000_8D3D17ACE214DC429325B2B98F3AE71208F127E3MX15Acorpemccom_-- From mkosjc@gmail.com Sun Aug 19 18:48:39 2012 Return-Path: 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 ; 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 ; 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 ; Sun, 19 Aug 2012 18:48:37 -0700 (PDT) Received: by qcac10 with SMTP id c10so4659188qca.31 for ; 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: <8D3D17ACE214DC429325B2B98F3AE71208F127E3@MX15A.corp.emc.com> Date: Sun, 19 Aug 2012 18:48:36 -0700 Message-ID: From: Michael Ko To: "Black, David" Content-Type: multipart/alternative; boundary=00248c6a560e46c11104c7a8b5f9 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 01:48:39 -0000 --00248c6a560e46c11104c7a8b5f9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Changed =93must be able to deal with=94 to =93needs to be able to deal with= =94 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 wrote: > Mike,**** > > ** ** > > Thanks for posting this new text, and I apologize for the delayed respons= e > -**** > > too much =93stuff=94 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 fro= m > the**** > > > target, then it may not be able to handle the number of unexpected iSCS= I > **** > > > control-type PDUs (as declared by the MaxOutstandingUnexpectedPDUs key > from**** > > > the initiator) that can be sent by the target before the buffer resourc= es > **** > > > are allocated at the initiator side. In this case the iSERHelloRequire= d > 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 =93MUST be negotiated to Yes=94 seems wrong, as that can=92t be done= if the > target**** > > responds with NotUnderstood. Also, that text doesn=92t provide a > sufficiently blunt**** > > warning, IMHO - it ought to state that the consequences of =93may not be > able to**** > > handle=94 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=92s correct, although I would change:**** > > =93must be able to deal with=94 ->=93needs to be able to deal with=94.**= ** > > ** ** > > > For a target, if the iSERHelloRequired key is not negotiated, it MUST > still > > respond with the iSER HelloReply Message when it receives the iSER Hell= o > Message.**** > > > If the iSERHelloRequired key is negotiated to No or NotUnderstood, a > target MAY**** > > > choose to terminate the connection; otherwise it SHOULD delay sending a= ny > **** > > > 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=92s ok, I think additional text is needed somewhere to point out tha= t > 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 o= f > 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 th= e > possibility > > of the unexpected control-type PDUs causing the RCaP connection to clos= e > 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 alloca= te > 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 bu= t > 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 s= o > that the initiator can allocate the connection resources before sending t= he > 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 th= e > 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 n= ot > 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 PDU= s > 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**** > --00248c6a560e46c11104c7a8b5f9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Changed =93must be able to deal with=94 to =93needs to be able to deal with= =94 as suggested.

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

An i= nitiator that conforms to [RFC5046] allocates connection resources before s= eding the Login Request with the T (Transit) bit set to 1 and the NSG (Next= Stage) field set to FullFeaturePhase.=A0 (For brevity, this is referred to= as "early" connection allocation.)=A0 The current iSER specifica= tion relaxes this requirement to allow an initiator to allocate connection = resources after it receives the final Login Response PDU from the target.= =A0 (For brevity, this is referred to as "late" connection alloca= tion.)=A0 To prevent the potential problem caused by the target sending the= number of unexpected iSCSI control-type PDUs as determined by the MaxOusta= ndingUnexpectedPDUs key allowed in the FullFeaturePhase when "late&quo= t; connection allocation is practised, the iSER Hello exchanges MUST be use= d.=A0 This allows the initiator to allocate the connection resources before= sending the iSER Hello Messages.=A0 The iSERHelloRequired key is used by t= he initiator to determine if it is dealing with a target that supports the = iSER Hello exchanges.

In the following summary where "late" connection allocation i= s practised, an initiator that follows [RFC5046] is referred to as an "= ;old" initiator; otherwise it is referred to as a "new" init= iator.=A0 Similarly, a target that does not support the iSERHelloRequired k= ey (and responds with "NotUnderstood" when negotiating the iSERHe= lloRequired key) is referred to as an "old" target; otherwise it = is referred to as a "new" target.=A0 Note that an "old"= target can still support the iSER Hello exchanges but this fact is not kno= wn by the initiator.=A0 A "new" target can also respond with &quo= t;No" when negotiating the iSERHelloREquired key.=A0 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" targe= t.

For an "old" initiator and an "old" target, t= he failure by the initiator to handle the number of unexpected iSCSI contro= l-type PDUs that are sent by the target before the buffer resources are all= ocated at the initiator can result in the failure of the iSER session cause= d by closure of the underlying RCaP connection.=A0 For the "old" = target, there is known implementation that sends one unexpected iSCSI contr= ol-type PDU after sending the final Login Response and then waits awhile be= fore sending the next one.=A0 This tends to alleviate somewhat the buffer a= llocation problem at the initiator.

For a "new" initiator and an "old" target, the fail= ure 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 cl= osure of the underlying RCaP connection.=A0 A "new" initiator MAY= choose to terminate the connection; otherwise it SHOULD do one of the foll= owing:

1. Allocate the connection resources before sending the final Login Req= uest PDU.

2. Allocate one or more buffers for receiving unexpected c= ontrol-type PDUs from the target before sending the final Login Request PDU= .=A0 This reduces the possibility of the unexpected control-type PDUs causi= ng the RCaP connection to close before the connection resources have been a= llocated.

For an "old" initiator and a "new" target, if the i= SERHelloRequired key is not negotiated, a "new" target MUST still= respond with the iSER HelloReply Message when it receives the iSER Hello M= essage.=A0 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-t= ype 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 secon= d, has expired.

Mike

On Mon, Aug 1= 3, 2012 at 3:27 PM, Black, David <david.black@emc.com> wro= te:

Mike,

=A0

Thanks for po= sting this new text, and I apologize for the delayed response -

too much =93stuff=94 going on in Vancouver ...

=A0

I think we could also use some additional text that summar= izes the new/old, old/new

and new/= new implementation interactions.=A0 Some comments on your posted text ...

=A0

> If the i= SCSI Layer on the initiator side allocates the connection resources<= u>

> to support RCaP only after it receives the final Logi= n Response PDU from the

> targe= t, then it may not be able to handle the number of unexpected iSCSI<= u>

> control-type PDUs (as declared by the MaxOutstandingU= nexpectedPDUs key from

> the in= itiator) that can be sent by the target before the buffer resources<= u>

> are allocated at the initiator side.=A0 In this case = the iSERHelloRequired key

> MUS= T be negotiated to Yes so that the initiator can allocate the connection=

> resources before sending the iSER Hello Message.=A0 S= ee section 5.1.3 for more

> det= ails.

=A0

That =93MUST = be negotiated to Yes=94 seems wrong, as that can=92t be done if the target<= u>

responds with NotUnderstood.=A0 Also, that text doesn=92t = provide a sufficiently blunt

warni= ng, IMHO - it ought to state that the consequences of =93may not be able to=

handle=94 include failure of the iSER session caused by cl= osure of the underlying

RCaP conne= ction.

=A0

> As the i= SERHelloRequired key is not defined in [RFC5046], an initiator/target

> must be able to deal with a target/initiator that doe= s not understand the key

> or s= upport the iSER Hello exchanges.

That=92s correct, although I = would change:

=93mu= st be able to deal with=94 ->=93needs to be able to deal with=94.=

=A0

> For a target, if the iSERHelloRequired key is not neg= otiated, it MUST still
> respond with the iSER HelloReply Message whe= n it receives the iSER Hello Message.

> If the iSERHelloRequired key is negotiated to No or N= otUnderstood, a target MAY

<= span style=3D"font-size:10.0pt;font-family:"Courier New"">> ch= oose to terminate the connection; otherwise it SHOULD delay sending any<= /u>

> unexpected control-type PDUs until one of the followi= ng events has occurred:

>=A0

> 1. A PDU is received from the initiator after it send= s the final Login Response PDU.
>
> 2. A system configurable ti= meout period, say one second, has expired.

=A0

That=92s ok, = I think additional text is needed somewhere to point out that there is

known target code that sends one PDU and then delays - tha= t might go in the additional

summar= y text that I suggest above, and also should be included as part of the<= /u>

rationale for:

=A0

> For an initiator, if the iSERHelloRequired key is neg= otiated to No or NotUnderstood,

> i= t MAY choose to terminate the connection; otherwise it SHOULD do one of the= following:
>
> 1. Allocate the connection resources before se= nding the final Login Request PDU.
>
> 2. Allocate one or more buffers for receiving unexpected cont= rol-type PDUs from

> the target= before sending the final Login Request PDU.=A0 This reduces the possibilit= y
> of the unexpected control-type PDUs causing the RCaP connection to clo= se before

> the connection reso= urces have been allocated.

=A0

<= div>

Thanks,
--David

=A0=

From:= st= orm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Michael K= o
Sent: Tuesday, July 24, 2012 8:27 PM
To: storm@ietf.org
Subject: [s= torm] Proposed text changes for the connection allocation problem=

=A0

These are the changes I intend to incorp= orate into the existing draft to solve the connection allocation problem by= using the iSER Hello exchanges.=A0 Please comment.

5.1.1=A0 Initiator Behavior

original:

If the outcome of t= he 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 MU= ST request the iSER Layer to allocate the connection resources necessary to= support RCaP by invoking the Allocate_Connection_Resources Operational Pri= mitive.

replacement:

If the outcome of the iSCSI negotiation is to enabl= e iSER-assisted mode, then on the initiator side, prior to sending the Logi= n 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 a= llocate 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 all= ocating the connection resources necessary to support RCaP, the following e= vents MUST occur in the specified sequence:=A0 [The numbered items will be = retained but without the numbering.]

new:

If the iSCSI Layer on the initiator side allocates the conn= ection resources to support RCaP only after it receives the final Login Res= ponse PDU from the target, then it may not be able to handle the number of = unexpected iSCSI control-type PDUs (as declared by the MaxOutstandingUnexpe= ctedPDUs key from the initiator) that can be sent by the target before the = buffer resources are allocated at the initiator side.=A0 In this case the i= SERHelloRequired key MUST be negotiated to Yes so that the initiator can al= locate the connection resources before sending the iSER Hello Message.=A0 S= ee section 5.1.3 for more details.

5.1.3=A0 iSER Hello Exchange

new:

The connection resource= s can be allocated at the initiator side after it has received the final Lo= gin Response PDU from the target.=A0 To prevent the potential problem cause= d by the target sending the number of unexpected iSCSI control-type PDUs as= determined by the MaxOustandingUnexpectedPDUs key allowed in the FullFeatu= rePhase, the iSER Hello exchanges can be used.=A0 This allows the initiator= to allocate the connection resources before sending the iSER Hello Message= .=A0 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 understan= d the key or support the iSER Hello exchanges.

For a target, if the = iSERHelloRequired key is not negotiated, it MUST still respond with the iSE= R HelloReply Message when it recieves the iSER Hello Message.=A0 If the iSE= RHelloRequired key is negotiated to No or NotUnderstood, a target MAY choos= e to terminate the connection; otherwise it SHOULD delay sending any unexpe= cted 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 secon= d, has expired.

For an initiator, if the iSERHelloRequired key is ne= gotiated 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 Req= uest PDU.

2. Allocate one or more buffers for receiving unexpected c= ontrol-type PDUs from the target before sending the final Login Request PDU= .=A0 This reduces the possibility of the unexpected control-type PDUs causi= ng the RCaP connection to close before the connection resources have been a= llocated.

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 th= e initiator when iSERHelloRequired is negotiated to "No".

new:

Conversely, if the iSER Hello Message is sent by the iSER L= ayer at the initiator when iSERHelloRequired is negotiated to "No"= ;, the iSER Layer at the target MAY treat this as a protocol error or respo= nd with an iSER HelloReply Message.

Mike


--00248c6a560e46c11104c7a8b5f9--