Re: [storm] Removing iSCSI Markers?

"Mallikarjun Chadalapaka" <cbm@chadalapaka.com> Mon, 12 April 2010 22:44 UTC

Return-Path: <cbm@chadalapaka.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A993A684D for <storm@core3.amsl.com>; Mon, 12 Apr 2010 15:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3lb5Kfa8pDK for <storm@core3.amsl.com>; Mon, 12 Apr 2010 15:44:11 -0700 (PDT)
Received: from snt0-omc3-s16.snt0.hotmail.com (snt0-omc3-s16.snt0.hotmail.com [65.55.90.155]) by core3.amsl.com (Postfix) with ESMTP id 462243A6809 for <storm@ietf.org>; Mon, 12 Apr 2010 15:44:11 -0700 (PDT)
Received: from SNT131-DS15 ([65.55.90.135]) by snt0-omc3-s16.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Apr 2010 15:44:05 -0700
X-Originating-IP: [15.251.201.73]
X-Originating-Email: [cbm@chadalapaka.com]
Message-ID: <SNT131-ds15137672BC9770D25CF313A0120@phx.gbl>
From: "Mallikarjun Chadalapaka" <cbm@chadalapaka.com>
To: "'David Harrington'" <ietfdbh@comcast.net>, "'Mark S. Edwards'" <marke@muttsnuts.com>, <storm@ietf.org>
References: <C2D311A6F086424F99E385949ECFEBCB02162B4B@CORPUSMX80B.corp.emc.com> <690958.35528.qm@smtp111.biz.mail.re2.yahoo.com> <SNT131-ds389E5D120CA34D81D341FA01F0@phx.gbl> <D8CEBB6AE9D43848BD2220619A43F326539198@M31.equallogic.com> <SNT129-W39116021288D2177842E5DE61F0@phx.gbl> <D8CEBB6AE9D43848BD2220619A43F3265391BE@M31.equallogic.com> <288331.47396.qm@smtp113.biz.mail.re2.yahoo.com> <SNT129-W518EAD0118AE20545198F3E61F0@phx.gbl><719511.28420.qm@smtp115.biz.mail.re2.yahoo.com> <SNT131-ds195C4D77D99D90330C71A6A01F0@phx.gbl> <0bf201cad989$e40ee9d0$0600a8c0@china.huawei.com>
In-Reply-To: <0bf201cad989$e40ee9d0$0600a8c0@china.huawei.com>
Date: Mon, 12 Apr 2010 15:44:02 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrQJThGDTzNBBj3QkmOgIeCm47ZrQAANX9gAlhwygAAQjdzgA==
Content-Language: en-us
X-OriginalArrivalTime: 12 Apr 2010 22:44:05.0900 (UTC) FILETIME=[A81BFCC0:01CADA91]
Subject: Re: [storm] Removing iSCSI Markers?
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 12 Apr 2010 22:44:13 -0000

Hi David,

> I am just showing that dropping a feature is justified by IETF
> process.
> I would focus on the "interoperable implementation" question, not the
> "any implementation" question.

True, I agree.  Thanks for pointing this out.  

On this specific thread, the resounding answer to question #1 so far is
"No".  So I believe the WG is in agreement on removing iSCSI Markers.  Once
David is back from vacation on the 19th, I assume he will make the formal
consensus call, unless someone reports news of existing interoperable
implementations in the interim.

Thanks.

Mallikarjun
 

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net]
> Sent: Sunday, April 11, 2010 8:16 AM
> To: 'Mallikarjun Chadalapaka'; 'Mark S. Edwards'; storm@ietf.org
> Subject: RE: [storm] Removing iSCSI Markers?
> 
> <as an individual contributor>
> inline
> 
> > -----Original Message-----
> > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org]
> > On Behalf Of Mallikarjun Chadalapaka
> > Sent: Tuesday, March 30, 2010 12:42 PM
> > To: 'Mark S. Edwards'; storm@ietf.org
> > Subject: Re: [storm] Removing iSCSI Markers?
> >
> > I believe out of order placement continues to be critical for
> > efficient
> > RNIC/DDP implementations, and markers play a role there.
> >
> > Having said that, IMHO, that is not exactly the question we
> > should tackle on
> > this thread.
> >
> > We should focus on these two iSCSI-centric questions:
> >
> > 1) Are there implementations out there that implement iSCSI
> > Markers *as
> > defined by RFC 3720*? (Asgeir may have answered this question
> > as "yes", but
> > he referenced an RNIC so I am not sure if he's referring to
> > the MPA-version
> > of markers or iSCSI key-driven markers)
> >
> > 2) If "yes" to #1, if we drop iSCSI Markers in the new
> > Consolidated draft,
> > would that cause problems to any "applications" - i.e. iSCSI
> > and SCSI stacks
> > in either commercial O/S or proprietary embedded implementations?
> >
> >
> > If the answer to the second question is "No", we can go ahead
> > and drop it
> > from the iSCSI Consolidated draft, independent of MPA/DDP/RDMAP.
> 
> Even if the answer to the second question is "Yes", we can consider
> whether
> the feature is being used interoperably across vendors. If each
> application
> is designed to work specifically with the same vendor's stack, then an
> IETF
> standard for multi-vendor interoperability isn't needed, not even in
> an appendix.
> Dropping the feature from the standard would not necessarily impact
> existing
> interoperability.
> 
> This type of approach of dropping features is supported by the
> RFC2026-defined
> "bar" for moving from Proposed Standard to Draft Standard:
> 
>    The requirement for at least two independent and interoperable
>    implementations applies to all of the options and features of the
>    specification.  In cases in which one or more options or features
>    have not been demonstrated in at least two interoperable
>    implementations, the specification may advance to the Draft
> Standard
>    level only if those options or features are removed.
> 
> I am just showing that dropping a feature is justified by IETF
> process.
> I would focus on the "interoperable implementation" question, not the
> "any implementation" question.
> 
> (and I am not suggesting going for Draft Standard; that would be a
> separate discussion.
> You can drop features without advancing the draft.)
> 
> >
> > Thanks.
> >
> > Mallikarjun
> >
> >
> >
> >
> >
> >
> > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org]
> > On Behalf Of
> > Mark S. Edwards
> > Sent: Tuesday, March 30, 2010 9:22 AM
> > To: storm@ietf.org
> > Subject: Re: [storm] Removing iSCSI Markers?
> >
> > Asgeir,
> >
> > Yes, I do understand and remember all the arguments.  Indeed,
> > I remember one
> > of Randy's theoretical presentations positing that a marker aware
> 10GB
> > offload NIC might only require as little as 2K onboard buffering
> RAM.
> >
> > The point is, that at least for iSCSI the technology that
> > arrived seems to
> > marginalised the need for anyone to implement markers.  Given
> > the fact that
> > running code creates IETF consensus we have an opportunity at
> > this time to
> > remove unnecessary complications, markers are a candidate for
> > being made
> > optional or even being removed completely.
> >
> > Personally I would be happy to see them removed.  My original
> > note on this
> > topic was to try to be a good citizen by asking anyone who might be
> > affected, or know someone who would be affected, to speak up.
> >
> > Mark.
> >
> >
> > At 16:28 30/03/2010, Asgeir Eiriksson wrote:
> >
> > Paul, Mark
> >
> > The main selling point for markers is that they enable out or order
> > placement
> > (on receive) while preserving in order completions and
> > markers therefore
> > have the
> > potential of decreasing buffering requirements in RNIC and to
> > a less extent
> > in
> > iSCSI HBA.
> >
> > 'Asgeir
> >
> > ________________________________________
> > Date: Tue, 30 Mar 2010 15:49:11 +0100
> > To: storm@ietf.org
> > From: marke@muttsnuts.com
> > Subject: Re: [storm] Removing iSCSI Markers?
> >
> > Paul,
> >
> > That's pretty much my recollection, too.
> >
> > One of those things that was thought to be a reasonable solution to
> a
> > foreseeable change in the technology.  In the end, the
> > technology found a
> > different solution.
> >
> > They were fascinating presentations, though.
> >
> > Mark.
> >
> > At 15:22 30/03/2010, Paul Koning wrote:
> > Thanks Asgeir.
> >
> > As I recall, the original idea behind markers is to make it
> > possible to
> > build 10G HBAs that can run at wire speed, which was believed to be
> > impossible otherwise.
> >
> > The subsequent record indicates that this was in fact not the
> > case; 10G HBAs
> > are feasible and have been built without resorting to
> > markers.  There is no
> > other reason for using markers.  So if the one reason that
> > they were thought
> > to be needed in fact turned out not to be real, the obvious
> > thing to do is
> > to remove the unused complications from the spec.
> >
> > I suppose one could argue that, placed in an appendix and “optional
> to
> > implement” they do no harm.  That’s a fair point.  If there is still
> a
> > chance that they will turn out to be needed in the future we
> > may want to go
> > that way.  I personally would bet against that chance.
> >
> >                 paul
> >
> > From: Asgeir Eiriksson [ mailto:asgeir_eiriksson@hotmail.com]
> > Sent: Tuesday, March 30, 2010 9:24 AM
> > To: Paul Koning; cbm@chadalapaka.com; marke@muttsnuts.com;
> > storm@ietf.org
> > Subject: RE: [storm] Removing iSCSI Markers?
> >
> > Hello Paul,
> >
> > The Chelsio RNIC do support the marker feature, but as far as
> > I know the
> > feature
> > has never been used in the field, and it isn't supported by all RNIC
> > implementations.
> >
> > I periodically ask our AE and developers about this feature
> > and so far the
> > answer
> > is that no one uses it, and no one is asking for it (4 years
> > of data at this
> > point).
> >
> > Regards,
> >
> > Asgeir Eiriksson
> > CTO
> > Chelsio Communications Inc.
> >
> > > Date: Mon, 29 Mar 2010 21:01:49 -0400
> > > From: Paul_Koning@Dell.com
> > > To: cbm@chadalapaka.com; marke@muttsnuts.com; storm@ietf.org
> > > Subject: Re: [storm] Removing iSCSI Markers?
> > >
> > > I sure would like markers to go away. Rumors of their use
> > are somewhat
> > > interesting, but substantiated data would be more so.
> > >
> > > paul
> > >
> > > > -----Original Message-----
> > > > From: storm-bounces@ietf.org [
> > mailto:storm-bounces@ietf.org] On Behalf
> > > > Of Mallikarjun Chadalapaka
> > > > Sent: Monday, March 29, 2010 8:33 PM
> > > > To: 'Mark S. Edwards'; storm@ietf.org
> > > > Subject: [storm] Removing iSCSI Markers?
> > > >
> > > > Just to clarify...
> > > >
> > > > > On another removal topic, I seem to recall that Mallikarjun
> also
> > > said
> > > > > that he was removing markers.
> > > >
> > > > I had only said that it's one of the items I had heard
> > prior requests
> > > > on
> > > > (that it be removed). Thanks for initiating the list discussion
> > > > though!
> > > >
> > > > > but I do wonder if this will affect any HBA implementations ?
> > > >
> > > > Good question, I don't know. HBA vendors, especially
> > iSCSI/iSER/RNIC
> > > > "roto-tilled" implementations, please chime in.
> > > >
> > > >
> > > > Mallikarjun
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: storm-bounces@ietf.org [ mailto:storm-bounces@ietf.org]
> On
> > > > Behalf Of
> > > > Mark
> > > > > S. Edwards
> > > > > Sent: Saturday, March 27, 2010 6:56 AM
> > > > > To: storm@ietf.org
> > > > > Subject: Re: [storm] Draft minutes from Anaheim
> > > > >
> > > > > Regarding the feature removal discussion, can I add SLP
> > to the list
> > > ?
> > > > >
> > > > > The RFC 3721 states
> > > > >
> > > > > "iSCSI equipment that
> > > > > need discovery functions beyond SendTargets should at least
> > > > > implement SLP, and then consider iSNS when extended discovery
> > > > > management capabilities are required such as in larger
> > > storage
> > > > > networks. It should be noted that since iSNS will support
> > > > SLP,
> > > > > iSNS can be used to help manage the discovery information
> > > > returned
> > > > > by SLP."
> > > > >
> > > > > The implication is that targets and initiators should
> > expect to find
> > > > > support for SLP before considering iSNS.
> > > > >
> > > > > I remember our first iSCSI appliance and we spent ages
> > trying to get
> > > > > SLP working because it the above wording effectively made it
> > > > > mandatory. SLP turned out to be a complete bust and was
> > effectively
> > > > > killed off when Microsoft refused to support it in
> > their initiator
> > > > > and in their target logo tests.
> > > > >
> > > > > The result is that today I doubt you could find a target or
> > > initiator
> > > > > out there supporting SLP.
> > > > >
> > > > > For anybody that does still implement SLP we could change the
> > > wording
> > > > > for SLP a little to remove the implied hierarchy, or
> > just admit that
> > > > > running code has created IETF consensus.
> > > > >
> > > > >
> > > > > On another removal topic, I seem to recall that Mallikarjun
> also
> > > said
> > > > > that he was removing markers. I don't particularly
> > object to this
> > > > > but I do wonder if this will affect any HBA implementations ?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Mark.
> > > > >
> > > > >
> > > > > At 06:59 27/03/2010, Black_David@emc.com wrote:
> > > > > >Draft minutes are attached - please comment, correct, etc.
> > > > > >
> > > > > >Also, in the absence of objection on this mailing
> > list, decisions
> > > > > >recorded in the minutes are considered to be the rough
> > consensus of
> > > > > >this WG, *except* that two issues were identified as
> > sufficiently
> > > > > >important to discuss separately on the list (see separate
> > > messages):
> > > > > > - Text negotiation key for new iSCSI features (discussion
> > > > > > in progress)
> > > > > > - Features to remove from iSCSI (discussion to be started)
> > > > > >
> > > > > >Many thanks to Craig Carlson for taking notes during
> > the meeting.
> > > > > >
> > > > > >Thanks,
> > > > > >--David
> > > > > >----------------------------------------------------
> > > > > >David L. Black, Distinguished Engineer
> > > > > >EMC Corporation, 176 South St., Hopkinton, MA 01748
> > > > > >+1 (508) 293-7953 FAX: +1 (508) 293-7786
> > > > > >black_david@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
> > > _______________________________________________
> > > storm mailing list
> > > storm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/storm
> > ________________________________________
> > Hotmail is redefining busy with tools for the New Busy. Get
> > more from your
> > inbox. Sign up now.
> >
> > ________________________________________
> > Hotmail has tools for the New Busy. Search, chat and e-mail
> > from your inbox.
> > Learn More.
> >
> > _______________________________________________
> > storm mailing list
> > storm@ietf.org
> > https://www.ietf.org/mailman/listinfo/storm
> >