Re: [storm] Removing iSCSI Markers?

Julian Satran <julian.satran@gmail.com> Tue, 30 March 2010 17:08 UTC

Return-Path: <julian.satran@gmail.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 035453A6A2E for <storm@core3.amsl.com>; Tue, 30 Mar 2010 10:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.85
X-Spam-Level:
X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619]
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 4gHL41aveB6A for <storm@core3.amsl.com>; Tue, 30 Mar 2010 10:08:02 -0700 (PDT)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 5D0073A6999 for <storm@ietf.org>; Tue, 30 Mar 2010 10:07:56 -0700 (PDT)
Received: by fg-out-1718.google.com with SMTP id l26so162953fgb.13 for <storm@ietf.org>; Tue, 30 Mar 2010 10:08:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Pe7/cB7KH0qiHVdhh7sTk4l/duVZeyGhRDVwmJrdeDM=; b=sq9K398m09gl8c2JHCeHGeGUQysDPC5AvsQaq4DYNAdAONXVoAdmkL1me8+/vtbcyH nI49TbZ1F3AoA9ljyMsbqwI0x1SQmXCaIRCXBH5lyzJ/XlqcGnIXITbtXBlV8R9XZLs4 kVcDHal+Vo7H9kMXjNJRuprfRDT9mgrIiauRQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=I7WraO+2hSQYoLicpmhjliX+iHgVC+pc/cPUABO8QWim9DrkrDVadCAUghnYZEcyD8 HGMk8z4mPxfC0bxmNFmaJwIUOSJ+aeJm3N02xsH7E0XMeCep/jdEY8IW3bfpqwC1wWdk 6jthTFZxCqxNXdbGiZ+zvC7qrWm74FdEbtu+o=
Received: by 10.102.210.18 with SMTP id i18mr3856425mug.92.1269968893035; Tue, 30 Mar 2010 10:08:13 -0700 (PDT)
Received: from Julo-MBP.local (IGLD-84-228-19-194.inter.net.il [84.228.19.194]) by mx.google.com with ESMTPS id n10sm24127091mue.12.2010.03.30.10.08.10 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 10:08:11 -0700 (PDT)
Message-ID: <4BB22FF9.70807@gmail.com>
Date: Tue, 30 Mar 2010 20:08:09 +0300
From: Julian Satran <julian.satran@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.2pre) Gecko/20100302 Lanikai/3.1b1
MIME-Version: 1.0
To: 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>
In-Reply-To: <SNT131-ds195C4D77D99D90330C71A6A01F0@phx.gbl>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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: Tue, 30 Mar 2010 17:08:05 -0000

  Dear All,

Just to get the "recollections" straight:

Markers where put in place because (some of us) could not handle 
"fighting" for an general purpose RDMA solution and getting iSCSI done 
at the same time and preferred to handle what we though more urgent 
(iSCSI). IETF was not inclined at the time to seriously consider an RDMA 
solution - except for using it over SCTP (a brand new transport at the 
time) - and many of us felt that the very conservative storage industry 
will not accept SCTP (too new!).

So we stopped (for a while) trying to get the things right and have IETF 
look for a generalized RDMA sollution (generic for TCP) and put 
something ugly but usable in place. The RDMA stuff was done after iSCSI 
was closed (and BTW has its own marker type solution when run over TCP - 
a bit costlier than iSCSI but workable). iSER is the result of having 
RDMA over TCP (yes with those ugly markers in place!).

With RDMA over TCP in place I am not sure we want to keep the iSCSI 
markers unless their removal breaks somebodys implementation. We will 
have to live with markers on RDMA over TCP - though.

And the problem never was processing at wire speed - processing is cheap 
- but rather conserving memory bandwidth.

Julo



On 30/03/10 19:42, Mallikarjun Chadalapaka wrote:
> 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.
>
> 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