Re: [storm] Plan for iSCSI work

<david.black@emc.com> Thu, 30 June 2011 20:27 UTC

Return-Path: <david.black@emc.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 6FA4321F86E1 for <storm@ietfa.amsl.com>; Thu, 30 Jun 2011 13:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 rOVzUey0C1Ll for <storm@ietfa.amsl.com>; Thu, 30 Jun 2011 13:27:03 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id D291021F85B9 for <storm@ietf.org>; Thu, 30 Jun 2011 13:27:02 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5UKQw02012772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jun 2011 16:26:59 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 30 Jun 2011 16:26:46 -0400
Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.221.56.102]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5UKMWM2006984; Thu, 30 Jun 2011 16:22:32 -0400
Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub13.corp.emc.com ([128.221.56.102]) with mapi; Thu, 30 Jun 2011 16:22:32 -0400
From: <david.black@emc.com>
To: <hemal@broadcom.com>, <cbm@chadalapaka.com>, <pthaler@broadcom.com>, <storm@ietf.org>
Date: Thu, 30 Jun 2011 16:22:31 -0400
Thread-Topic: [storm] Plan for iSCSI work
Thread-Index: AQCUfOqLFecrTE8dOe+/hpcfY+kOJQIRzTq9AgfEPyEC0X+ZOALMKXeKAZ2F7W4CMc4IEQIKcUnlAchkSwmWus8xoIAADTeggAAlA0A=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058931036F@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F426C5@MX14A.corp.emc.com> <SNT131-ds2DE0F0F2022D63A4AD747A0760@phx.gbl> <76DBE161893C324BA6D4BB507EE4C384951235CB38@IRVEXCHCCR02.corp.ad.broadcom.com> <SNT131-ds117065D22D7BF8583485DBA0790@phx.gbl> <76DBE161893C324BA6D4BB507EE4C38495124C4828@IRVEXCHCCR02.corp.ad.broadcom.com> <SNT131-ds219B987FD6FA0437A497FDA06D0@phx.gbl> <76DBE161893C324BA6D4BB507EE4C3849513370AB5@IRVEXCHCCR02.corp.ad.broadcom.com> <SNT131-ds1709A999A40FA52B3C247A0590@phx.gbl> <DBFBCB90599B2C46992032279293D10020A74038C5@SJEXCHCCR01.corp.ad.broadcom.com> <SNT131-ds13E5904E7EA7050ED37F89A0580@phx.gbl> <76DBE161893C324BA6D4BB507EE4C3849513371174@IRVEXCHCCR02.corp.ad.broadcom.com>
In-Reply-To: <76DBE161893C324BA6D4BB507EE4C3849513371174@IRVEXCHCCR02.corp.ad.broadcom.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] Plan for iSCSI work
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: Thu, 30 Jun 2011 20:27:04 -0000

<WG chair hat off> I think use of "SHOULD" is the right approach here. </WG chair hat off>

<WG chair hat on> Based on list discussion, I believe "SHOULD" is the rough consensus of the WG. </WG chair hat on>

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Hemal Shah [mailto:hemal@broadcom.com]
> Sent: Thursday, June 30, 2011 2:09 PM
> To: Mallikarjun Chadalapaka; Pat Thaler; Black, David; storm@ietf.org
> Subject: RE: [storm] Plan for iSCSI work
>
> Thanks Mallikarjun!
>
> Hemal
>
> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> Sent: Thursday, June 30, 2011 11:06 AM
> To: Pat Thaler; Hemal Shah; david.black@emc.com; storm@ietf.org
> Subject: RE: [storm] Plan for iSCSI work
>
> Hi Pat,
>
> Thanks for flagging the inconsistency in 10.7, that's a good catch.  Given
> that and your/Hemal's feedback, I think turning the current MUST into a
> SHOULD is probably the right resolution.   That syncs them both to SHOULD.
> Unless I see other comments, I will get this into the next revision.
>
> Thanks.
>
> Mallikarjun
>
>
>   -----Original Message-----
>   From: Pat Thaler [mailto:pthaler@broadcom.com]
>   Sent: Wednesday, June 29, 2011 4:03 PM
>   To: Mallikarjun Chadalapaka; Hemal Shah; david.black@emc.com;
>   storm@ietf.org
>   Subject: RE: [storm] Plan for iSCSI work
>
>   Hi Malikarjun,
>
>   10.7 in the consolidated draft says that FastAbort is a SHOULD:
> "Therefore,
>   both iSCSI target and initiator implementations SHOULD support FastAbort
>   multi-task abort semantics (Section 4.2.3.4)."
>
>   When 4.2.3.5 saying "If an iSCSI target implementation is capable of
>   supporting TaskReporting=FastAbort functionality" implies that the
>   implementation was allowed to not implement FastAbort. You might
>   interpret "supporting" = (implemented and negotiated to TaskAbort) as you
>   say below, but "capable of supporting" still reads as implemented. When
>   the standard puts an if in front of that, it implies that an
> implementation is
>   allowed to be not capable of supporting FastAbort.
>
>   Neither of these is consistent with MUST implement for FastAbort. The
>   rationale for requiring FastAbort doesn't seem strong and I'd prefer that
> the
>   inconsistency be resolved by not requiring its implementation.
>
>   Regards,
>   Pat
>
>   -----Original Message-----
>   From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
>   Of Mallikarjun Chadalapaka
>   Sent: Wednesday, June 29, 2011 3:16 PM
>   To: Hemal Shah; david.black@emc.com; storm@ietf.org
>   Subject: Re: [storm] Plan for iSCSI work
>
>   Hi Hemal,
>
>   >1.     The implementation of TaskReporting is required and NotUnderstood
>   response for TaskReporting key is not permitted
>
>   No.  Note that TaskReporting is not defined in RFC 3720.  Patrick
> MacArthur
>   proposed on this list a couple of weeks ago that we should fix this
>   disconnect in the consolidated draft - which I agreed with because I think
>   it's a good suggestion.
>
>    >2.    To enable FastAbort on a session, the negotiation of TaskReporting
>   key is required.
>
>   Correct, specifically "TaskReporting=FastAbort" must be negotiated.
>
>   >3.     Only when the TaskReporting=FastAbort functionality is supported,
>   the protocol behavior specified in Section 4.2.3.4 is required to be
>   implemented and exhibited.
>
>   If I were to attempt re-writing your idea, I would say:
>
>   When the protocol behavior specified in Section 4.2.3.4 is implemented and
>   TaskReporting=FastAbort is operational on a session, then the FastAbort
>   functionality is supported/exhibited on that session by the
> implementation.
>
>   >a.     Section 4.2.3.5: If an iSCSI target implementation is capable of
>   supporting
>   >TaskReporting=FastAbort functionality (Section 13.23).
>
>   "Supporting" = implemented and negotiated to "TaskReporting=FastAbort".
>   Note that if even if an implementation has implemented this functionality
>   and wants to use it, it will not be able to negotiate it on any session if
> it's
>   only communicating with a bunch of RFC 3720 implementations.
>
>    >b.    Section 4.2.2.3.3: Whenever the TaskReporting key (Section 12.23
>   "Task Reporting") is negotiated to ResponseFence or FastAbort for an iSCSI
>   session.
>   >c.     Section 4.2.2.3.4: Whenever the TaskReporting key (Section 13.23)
> is
>   negotiated to ResponseFence or FastAbort for an iSCSI session.
>
>   I don't see an issue.  Note that the discussion in these two sections is
> on
>   response fencing, not fast abort per se.
>
>   >4.     ...prefixed with some text like "Only when the
>   TaskReporting=FastAbort functionality is supported..".
>
>   Please see the above responses.  Your wording is vague for me, as I don't
>   comprehend a standalone notion of "supporting" a feature, other than
>   implementing a feature and negotiating the feature usage.   Current RFC
>   5048
>   requirement is that implementation is MUST, and negotiation is MUST
>   (may result in the feature to be used, or not).  So as such, there is
> already
>   ample flexibility for implementations.
>
>   I think you are restating your earlier suggestion to loosen the "MUST
>   implement" requirement in RFC5048.  And I've already shared how I feel
>   about it, :)  I think it would be a step in the wrong direction, when
> faster
>   error recovery with multi-task aborts with large # of
> sessions/LUs/initiators
>   is even more critical, due to increased consolidation in data centers.
>
>   At this point, I think it would be good to also hear from the rest of the
> list.
>
>   Thanks.
>
>   Mallikarjun
>
>
>
>
>
>   >Thanks Mallikarjun! I would still like to confirm my understanding of
>   >what
>   you describe as "MUST implement, but MUST negotiate".
>   >
>   >Here is my understanding:
>   >
>   >1.     The implementation of TaskReporting is required and NotUnderstood
>   response for TaskReporting key is not permitted based on the following
> text
>   from RFC5048 and Section 6.2 of the consolidated draft:
>   >                 All keys defined in [RFC3720] MUST be supported by all
>   >            compliant implementations; a NotUnderstood answer on any of
>   the
>   >            [RFC3720] keys therefore MUST be considered a protocol
>   > error
>   and
>   >            handled accordingly.
>   >2.     To enable FastAbort on a session, the negotiation of TaskReporting
>   key is required.
>   >3.     Only when the TaskReporting=FastAbort functionality is supported,
>   the protocol behavior specified in Section 4.2.3.4 is required to be
>   implemented and exhibited. There are several places in the spec that
>   indicate this type of conditionality.
>   >a.     Section 4.2.3.5: If an iSCSI target implementation is capable of
>   supporting
>   >TaskReporting=FastAbort functionality (Section 13.23).
>   >b.     Section 4.2.2.3.3: Whenever the TaskReporting key (Section 12.23
>   "Task Reporting") is negotiated to ResponseFence or FastAbort for an iSCSI
>   session.
>   >c.     Section 4.2.2.3.4: Whenever the TaskReporting key (Section 13.23)
> is
>   negotiated to ResponseFence or FastAbort for an iSCSI session.
>   >4.     If TaskReporting=FastAbort functionality is not supported, then
> the
>   protocol behavior specified in Section 4.2.3.4 is not required to be
>   implemented or exhibited. If this is true, then the first sentence in
> section
>   4.2.3.4 is misleading and should be removed or prefixed with some text
> like
>   "Only when the TaskReporting=FastAbort functionality is supported..".
>   >
>   >Hemal
>   >
>   >
>   >-----Original Message-----
>   >From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
>   >Sent: Friday, June 17, 2011 3:32 PM
>   >To: Hemal Shah; david.black@emc.com; storm@ietf.org
>   >Subject: RE: [storm] Plan for iSCSI work
>   >
>   >Hi Hemal,
>   >
>   >During RFC 5048 effort, I recall we settled on the "MUST implement, but
>   MUST
>   >negotiate" formulation after some list deliberation.
>   >
>   >With plain RFC 3720 semantics, there are some multi-initiator scenarios
>   >where multi-task aborts could essentially lead to target deadlocks,
>   >waiting on initiators on third-party sessions that may never respond.
>   >With the "Clarified" semantics in RFC 5048, the third-party deadlocks
>   >aren't a problem anymore, but issuing initiator could still experience
>   >timeouts and escalate error recovery - depending on the number of LUs,
>   sessions,
>   >connections and tasks affected with the issued TMF.    Escalated error
>   >recovery is usually something we want to avoid as it adds more
>   >delays/alerts/logs/failovers/failbacks etc.  Finally, "Updated"
>   >semantics
>   in
>   >RFC 5048 are meant to address this timeout problem - they permit
>   >targets to provide accelerated responses and allow them to deal with
>   >book-keeping/quiescing operations in a lazy fashion (which are the real
>   >culprits that trigger timeouts).
>   >
>   >Given all the above, the WG settled on FastAbort as a MUST-implement.
>   >The "MUST negotiate" part then is to enable backwards-compatibility
>   >with RFC
>   >3720 implementations.  At this point, I'd rather not loosen the
>   Consolidated
>   >iSCSI draft requirement from what it is in RFC 5048.  I suggest we
>   >leave it the way it is.
>   >
>   >Mallikarjun
>   >
>   >
>   >
>   >
>   >
>   >
>   >From: Hemal Shah [mailto:hemal@broadcom.com]
>   >Sent: Thursday, June 09, 2011 3:57 PM
>   >To: Mallikarjun Chadalapaka; david.black@emc.com; storm@ietf.org
>   >Subject: RE: [storm] Plan for iSCSI work
>   >
>   >Thanks Mallikarjun!
>   >
>   >The way I read Section 4.1.3 of RFC5048 and Section 4.2.3.4 of the
>   >consolidated draft, the implementation of "FastAbort" feature is a MUST.
>   >From the first paragraph text from Section 4.1.3 of RFC5048, the first
>   >sentence mandates that all iSCSI implementation comply to this section
>   >but the second sentence say that the requirement in this section is
>   >conditional to the negotiation of "FastAbort" key.
>   >
>   >Protocol behavior defined in this section MUST be implemented by all
>   >iSCSI implementations complying with this document. Protocol behavior
>   >defined in this section MUST be exhibited by iSCSI implementations on
>   >an iSCSI session when they negotiate the TaskReporting (Section 9.1)
>   >key to "FastAbort" on that session.
>   >
>   >
>   >This is confusing. I think it will be better to remove the first
>   >sentence from 4.2.3.4 and clarify that the requirements in this section
>   >is conditional. I suggest rewording the first two sentences to below:
>   >
>   >       iSCSI implementations may negotiate the TaskReporting (Section
>   >9.1) key to "FastAbort" on an iSCSI session. Protocol behavior defined
>   >in this section MUST be exhibited by iSCSI implementations on an iSCSI
>   >session when they negotiate the TaskReporting (Section 9.1) key to
>   >"FastAbort" on that session.
>   >
>   >Hemal
>   >
>   >
>   >-----Original Message-----
>   >From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
>   >Sent: Friday, May 27, 2011 5:29 PM
>   >To: Hemal Shah; david.black@emc.com; storm@ietf.org
>   >Subject: RE: [storm] Plan for iSCSI work
>   >
>   >Hi Hemal,
>   >
>   >The text in this draft came verbatim from section 4.1.3 of RFC 5048.
>   >There have been no changes in this area.
>   >
>   >The new text (as well as the old text) requires the TaskReporting key
>   >to be negotiated to "FastAbort" before the multi-task abort semantics
>   >can be used on an iSCSI session.
>   >
>   >Thanks.
>   >
>   >Mallikarjun
>   >
>   >
>   >
>   >
>   >  -----Original Message-----
>   >  From: Hemal Shah [mailto:hemal@broadcom.com]
>   >  Sent: Friday, May 27, 2011 4:51 PM
>   >  To: Mallikarjun Chadalapaka; david.black@emc.com; storm@ietf.org
>   >  Subject: RE: [storm] Plan for iSCSI work
>   >
>   >  Mallikarjun and David,
>   >
>   >  I noticed one problematic item in the consolidated draft. This item
>   > is
>   the
>   >  requirement to support FastAbort. This feature was already defined in
>   > the  implementation guide, but it was optional. In this draft, it
>   > became a  required feature MUST - see in section 4.2.3.4.
>   >
>   >  Do you know why the requirement was changed in the consolidated
>   draft?
>   >
>   >  I would like to keep the requirement optional as stated in the
>   > implementation guide and not break backward compatibility.
>   >
>   >  Hemal
>   >
>   >  -----Original Message-----
>   >  From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
>   > Behalf  Of Mallikarjun Chadalapaka
>   >  Sent: Thursday, May 26, 2011 6:50 PM
>   >  To: david.black@emc.com; storm@ietf.org
>   >  Subject: Re: [storm] Plan for iSCSI work
>   >
>   >  Hi David,
>   >
>   >  The list of changes you have called out are already done in the
>   >latest draft.  I
>   >  assume then that you are suggesting that the list itself should be
>   >included
>   >  in the next revision of the draft.
>   >
>   >  Here's what I recall we have done so far:
>   >  1)  iSCSIProtocolLevel specified as "1", and added a related
>   >normative
>   >  reference to iSCSI-SAM draft
>   >  2)  Markers and related keys were removed
>   >  3)  SPKM authentication and related keys were removed
>   >  4)  Added a new section on responding to obsoleted keys
>   >  5)  Have explicitly allowed initiator+target implementations
>   >throughout the
>   >  text
>   >  6)  Clarified that implementations SHOULD NOT rely on SLP-based
>   >discovery
>   >  7)  Added UML diagrams, and related conventions
>   >
>   >  The above is of course in addition to consolidating the different
>   >RFCs, and
>   >  making the related editorial changes.
>   >
>   >  Thanks.
>   >
>   >  Mallikarjun
>   >
>   >
>   >
>   >
>   >    -----Original Message-----
>   >    From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
>   Behalf
>   >    Of david.black@emc.com
>   >    Sent: Friday, May 20, 2011 2:49 PM
>   >    To: storm@ietf.org
>   >    Subject: [storm] Plan for iSCSI work
>   >
>   >    I thought I'd offer some advance planning/warning on this, as the
>   >    consolidated iSCSI draft (draft-ietf-storm-iscsi-cons) is large
>   >(over
>   >300
>   >    pages).  The current plan is to run a simultaneous WG Last Call on
>   >both
>   >  this
>   >    draft and the new features draft (draft-ietf-storm-iscsi-sam)
>   >starting in
>   >  mid-
>   >    June (probably the week of June 13, after I get back from a badly
>   needed
>   >    vacation).  That WG Last Call will run longer than the typical
>   >2-week time
>   >    period, due to the total size of the drafts, but will end by July
>   >5th
>   at
>   >the
>   >    latest so that the status of the drafts and the next steps are
>   >known prior
>   >  to
>   >    the T10 (SCSI standards) meetings during the week of July 11.  As
>   >July 11th
>   >    is also the draft cutoff deadline for the Quebec City IETF
>   >meetings, revised
>   >    draft versions may not show up until that meeting week (week of July
>   >    24th).
>   >
>   >    This is also a good point to announce that the storm WG will meet in
>   >    Quebec City.
>   >    I've only requested a 1-hour session, as we get most of our work
>   > done
>   on
>   >    the mailing list.  Among the items for that meeting will be
>   > figuring
>   out
>   >  what
>   >    to do with the RDMA extensions draft (despite its name,
>   >draft-ietf-storm-
>   >    rdmap-ext-00, it's not currently an official work item for the
>   >storm WG).
>   >
>   >    One thing that's missing from the consolidated iSCSI draft (and is
>   >a reason
>   >    why we're going to need a -03 version) is the changes that it makes
>   >to the
>   >    RFCs that it consolidates.  Off the top of my head, the major
>   >changes
>   >are:
>   >         - Removal of SPKM authentication
>   >         - Removal of the Marker appendix
>   >         - Removal of the SHOULD requirement for SLP implementation.
>   >    Have I missed anything significant?  The summary of this will need
>   >to
>   be
>   >    added to that draft.
>   >
>   >    WG Last Call will be an opportunity (in fact the final opportunity)
>   > to  discuss
>   >    whether anything else should be removed from iSCSI, but there's no
>   need
>   >    to wait
>   >    - I encourage people to review both drafts and post comments
>   whenever
>   >    they can.
>   >
>   >    In parallel, work will get started on any iSCSI MIB changes that
>   >are needed.
>   >    So far, I only see one MIB change - the iSCSIProtocolLevel from the
> new
>   >    features draft needs to be added to the MIB, probably with a
> structure
>   >    analogous to the iSCSI version support that's already in the MIB.
>   >
>   >    Thanks,
>   >    --David (storm WG co-chair)
>   >    ----------------------------------------------------
>   >    David L. Black, Distinguished Engineer
>   >    EMC Corporation, 176 South St., Hopkinton, MA  01748
>   >    +1 (508) 293-7953             FAX: +1 (508) 293-7786
>   >    david.black@emc.com        Mobile: +1 (978) 394-7754
>   >    ----------------------------------------------------
>   >
>   >    _______________________________________________
>   >    storm mailing list
>   >    storm@ietf.org
>   >    https://www.ietf.org/mailman/listinfo/storm
>   >
>   >  _______________________________________________
>   >  storm mailing list
>   >  storm@ietf.org
>   >  https://www.ietf.org/mailman/listinfo/storm
>   >
>   >
>   >
>   >
>   >
>   >
>   >
>   >
>   >
>
>   _______________________________________________
>   storm mailing list
>   storm@ietf.org
>   https://www.ietf.org/mailman/listinfo/storm
>
>
>
>
>