From ips-bounces@ietf.org Thu Dec 01 12:04:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehrr2-0002uz-5g; Thu, 01 Dec 2005 12:04:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehrr0-0002up-Qp for ips@megatron.ietf.org; Thu, 01 Dec 2005 12:04:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18098 for ; Thu, 1 Dec 2005 12:03:32 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhsBW-0005SA-2B for ips@ietf.org; Thu, 01 Dec 2005 12:25:31 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 43546870E2; Thu, 1 Dec 2005 12:04:04 -0500 (EST) In-Reply-To: <20051130013405.77413.qmail@web51906.mail.yahoo.com> References: <20051130013405.77413.qmail@web51906.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: William Studenmund Subject: Re: [Ips] Fast multi-task abort model Date: Thu, 1 Dec 2005 09:03:55 -0800 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1411018430==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1411018430== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-530612524" Content-Transfer-Encoding: 7bit --Apple-Mail-1-530612524 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 29, 2005, at 5:34 PM, Mallikarjun C. wrote: > Hi Julian, > > Thanks for the review. > > I agree with you that CmdSN & StatSN ack wait on 3rd > party sessions wasn't the original intent, and both > should be errata noted in the implementer's guide. > > The third major source of delay comes from the TTT > wait - it's a cross-nexus delay and RFC 3720 requires > it for completing the original TMF. The Async-NopIn > exchange enables us to take this wait out of the > "performance path" by giving the target iSCSI layer a > definitive event to free up the TTTs in a lazy > fashion. Why does it need to be cross-nexus, other than the fact that RFC 3720 says it should be? My thought is that we just revise it to not be cross-nexus. Yes, a given session is in the "waiting for things to stop" state until the TTTs clear, but as long as the "instant of death" I mentioned in my other mail has happened, I don't think that the TMF needs to wait. > I don't like mandating TAS=1 for several reasons - a) > it's a SCSI feature, b) it's not a default control > mode page setting, c) it makes it harder to build > iSCSI-to-XYZ bridges, d) puts iSCSI in a minor > competitive disadvantage wrt other transports, e) it > does not address the TTT problem with a > multi-connection issuing session. So I am glad you > like the Async PDU approach. I agree with (c) and (e), and they are enough to make me not like the TAS=1-required idea. > I would let David comment on the RFC revision part - > but given all the other things we have been collecting > in the iSCSI implementer's guide and given the guide > will be published as an RFC that "updates" RFC 3720, I > think it should be OK to include the new behavior in > the guide. Just to be clear, I like both the new abort proposal (AsyncEvent 5) and also removing all long-wait inter-nexus delays. Obviously the abort/reset will have to have started on all nodes before the TMF is returned. :-) Take care, Bill --Apple-Mail-1-530612524 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDjy0BDJT2Egh26K0RAkj2AKCOKn6kHEHNfz6AYwoAGIgxSA2LSwCdG4LI VzyPCor6K+v++aPQfSKtEYA= =Gyfp -----END PGP SIGNATURE----- --Apple-Mail-1-530612524-- --===============1411018430== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1411018430==-- From ips-bounces@ietf.org Thu Dec 01 13:20:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eht34-0004Lu-40; Thu, 01 Dec 2005 13:20:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eht33-0004JG-Ao for ips@megatron.ietf.org; Thu, 01 Dec 2005 13:20:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28051 for ; Thu, 1 Dec 2005 13:20:02 -0500 (EST) From: Black_David@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhtNZ-0008IX-6F for ips@ietf.org; Thu, 01 Dec 2005 13:42:02 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.6) with ESMTP id jB1IKVLC024924 for ; Thu, 1 Dec 2005 13:20:31 -0500 (EST) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jB1IKLNu012675 for ; Thu, 1 Dec 2005 13:20:29 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Dec 2005 13:20:19 -0500 Message-ID: To: ips@ietf.org Date: Thu, 1 Dec 2005 13:20:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.12.1.19 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ips] IPS WG - MIB status X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IESG has just approved the FCIP MIB as an RFC; the announcement of this will appear shortly, after which it'll land in the RFC Editor's Queue, so this seems like a good time to update the WG on the status of our other MIBs. The iFCP MIB was approved by the IESG in October and is already in the RFC Editor's Queue. The SCSI MIB requires a revision to address issues found in expert review by the assigned MIB Doctor. That revised draft is expected in the next couple of weeks. The iSCSI MIB is in good shape - the expert review comments found by the assigned MIB Doctor have been addressed in the current version, but we're holding it up so that it will go to IETF Last Call together with the Authorization MIB. The Authorization MIB will need to be revised, but we don't have all the comments needed to generate the revision, yet. The end of year holidays are going to get in the way, but I hope to see this get through MIB Doctor expert review by mid-January after which a revised version will be needed. The iSNS MIB is still in the working group. Major changes (including significant reduction in scope) are going to be performed, and unfortunately, the authors have encountered delays in getting the changes done. The current ETA for the revised draft of this MIB with the structural change is the end of January, so it's going to miss the current December 2005 goal for submission to the IESG - given the continuing author delays on this MIB, my best current guess for its completion and submission to the IESG is now June 2006. Thanks, --David (IPS WG chair) ---------------------------------------------------- David L. Black, Senior Technologist 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 01 19:01:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhyMf-00083S-1l; Thu, 01 Dec 2005 19:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhyMd-00083M-3Z for ips@megatron.ietf.org; Thu, 01 Dec 2005 19:01:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05728 for ; Thu, 1 Dec 2005 19:00:36 -0500 (EST) Received: from web51904.mail.yahoo.com ([206.190.48.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ehyh7-0004cQ-Au for ips@ietf.org; Thu, 01 Dec 2005 19:22:38 -0500 Received: (qmail 59883 invoked by uid 60001); 2 Dec 2005 00:01:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Er2gMuPJIVOqfe3Qw2LYbX4ixqcT7UPMharpQTeQMRWUPpc/bAtQDMgX2sYYxRzE3RmtkIJpGuoIfpHoXxd+kOfzPlOGAuGs93Gk6L/CbNNXB3UPxJJyw06Pz2ri51IOLHullJ8Axj0DuIz0Ej/gLrXGdauCCyZcrwdqqhJYg2Y= ; Message-ID: <20051202000102.59881.qmail@web51904.mail.yahoo.com> Received: from [156.153.255.243] by web51904.mail.yahoo.com via HTTP; Thu, 01 Dec 2005 16:01:01 PST Date: Thu, 1 Dec 2005 16:01:01 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Fast multi-task abort model To: IPS In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 8bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > Why does it need to be cross-nexus, other than the > fact that RFC 3720 > says it should be? There's a good rationale behind RFC 3720 text: TMF cannot complete until all affected tasks are terminated on the target per SAM. Receiving stale data after tasks are terminated is a problem. Waiting for all active TTTs of all affected tasks (same and/or other nexus) to finish was thus the adopted approach to avoid stale data for any affected task. What the new proposal does is to make receiving stale data after task terminations a non-problem - via a separate accounting scheme and new target semantics. Mallikarjun --- William Studenmund wrote: > On Nov 29, 2005, at 5:34 PM, Mallikarjun C. wrote: > > > Hi Julian, > > > > Thanks for the review. > > > > I agree with you that CmdSN & StatSN ack wait on > 3rd > > party sessions wasn't the original intent, and > both > > should be errata noted in the implementer's guide. > > > > The third major source of delay comes from the TTT > > wait - it's a cross-nexus delay and RFC 3720 > requires > > it for completing the original TMF. The > Async-NopIn > > exchange enables us to take this wait out of the > > "performance path" by giving the target iSCSI > layer a > > definitive event to free up the TTTs in a lazy > > fashion. > > Why does it need to be cross-nexus, other than the > fact that RFC 3720 > says it should be? > > My thought is that we just revise it to not be > cross-nexus. Yes, a > given session is in the "waiting for things to stop" > state until the > TTTs clear, but as long as the "instant of death" I > mentioned in my > other mail has happened, I don't think that the TMF > needs to wait. > > > I don't like mandating TAS=1 for several reasons - > a) > > it's a SCSI feature, b) it's not a default control > > mode page setting, c) it makes it harder to build > > iSCSI-to-XYZ bridges, d) puts iSCSI in a minor > > competitive disadvantage wrt other transports, e) > it > > does not address the TTT problem with a > > multi-connection issuing session. So I am glad > you > > like the Async PDU approach. > > I agree with (c) and (e), and they are enough to > make me not like the > TAS=1-required idea. > > > I would let David comment on the RFC revision part > - > > but given all the other things we have been > collecting > > in the iSCSI implementer's guide and given the > guide > > will be published as an RFC that "updates" RFC > 3720, I > > think it should be OK to include the new behavior > in > > the guide. > > Just to be clear, I like both the new abort proposal > (AsyncEvent 5) and > also removing all long-wait inter-nexus delays. > Obviously the > abort/reset will have to have started on all nodes > before the TMF is > returned. :-) > > Take care, > > Bill > __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Dec 02 14:17:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiGPb-0003MH-Fl; Fri, 02 Dec 2005 14:17:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiGPZ-0003M6-Rs for ips@megatron.ietf.org; Fri, 02 Dec 2005 14:17:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03943 for ; Fri, 2 Dec 2005 14:16:49 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiGkI-0002yC-Vt for ips@ietf.org; Fri, 02 Dec 2005 14:39:03 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id jB2JHTec118768 for ; Fri, 2 Dec 2005 19:17:30 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB2JHNjJ209334 for ; Fri, 2 Dec 2005 20:17:23 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jB2JHNgn010670 for ; Fri, 2 Dec 2005 20:17:23 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jB2JHNe5010667; Fri, 2 Dec 2005 20:17:23 +0100 In-Reply-To: To: William Studenmund Subject: Re: [Ips] Fast multi-task abort model MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Julian Satran Message-ID: Date: Fri, 2 Dec 2005 21:17:20 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.51HF338 | June 21, 2004) at 02/12/2005 21:17:22 Content-Type: multipart/mixed; boundary="=_mixed 0069F46CC22570CB_=" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --=_mixed 0069F46CC22570CB_= Content-Type: multipart/alternative; boundary="=_alternative 0069F46FC22570CB_=" --=_alternative 0069F46FC22570CB_= Content-Type: text/plain; charset="US-ASCII" Regrdless of the TMF completion - discarding old TTT tagged data buffers is problems third party target sessions will face unless they know for sure that none can be expected in a safe way. Julo William Studenmund Sent by: ips-bounces@ietf.org 01-12-05 19:03 To "Mallikarjun C." cc IPS Subject Re: [Ips] Fast multi-task abort model On Nov 29, 2005, at 5:34 PM, Mallikarjun C. wrote: > Hi Julian, > > Thanks for the review. > > I agree with you that CmdSN & StatSN ack wait on 3rd > party sessions wasn't the original intent, and both > should be errata noted in the implementer's guide. > > The third major source of delay comes from the TTT > wait - it's a cross-nexus delay and RFC 3720 requires > it for completing the original TMF. The Async-NopIn > exchange enables us to take this wait out of the > "performance path" by giving the target iSCSI layer a > definitive event to free up the TTTs in a lazy > fashion. Why does it need to be cross-nexus, other than the fact that RFC 3720 says it should be? My thought is that we just revise it to not be cross-nexus. Yes, a given session is in the "waiting for things to stop" state until the TTTs clear, but as long as the "instant of death" I mentioned in my other mail has happened, I don't think that the TMF needs to wait. > I don't like mandating TAS=1 for several reasons - a) > it's a SCSI feature, b) it's not a default control > mode page setting, c) it makes it harder to build > iSCSI-to-XYZ bridges, d) puts iSCSI in a minor > competitive disadvantage wrt other transports, e) it > does not address the TTT problem with a > multi-connection issuing session. So I am glad you > like the Async PDU approach. I agree with (c) and (e), and they are enough to make me not like the TAS=1-required idea. > I would let David comment on the RFC revision part - > but given all the other things we have been collecting > in the iSCSI implementer's guide and given the guide > will be published as an RFC that "updates" RFC 3720, I > think it should be OK to include the new behavior in > the guide. Just to be clear, I like both the new abort proposal (AsyncEvent 5) and also removing all long-wait inter-nexus delays. Obviously the abort/reset will have to have started on all nodes before the TMF is returned. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0069F46FC22570CB_= Content-Type: text/html; charset="US-ASCII"
Regrdless of the TMF completion - discarding old TTT tagged data buffers is problems third party target sessions will face unless they know for sure that none can be expected in a safe way.

Julo


William Studenmund <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org

01-12-05 19:03

To
"Mallikarjun C." <cb_mallikarjun@yahoo.com>
cc
IPS <ips@ietf.org>
Subject
Re: [Ips] Fast multi-task abort model





On Nov 29, 2005, at 5:34 PM, Mallikarjun C. wrote:

> Hi Julian,
>
> Thanks for the review.
>
> I agree with you that CmdSN & StatSN ack wait on 3rd
> party sessions wasn't the original intent, and both
> should be errata noted in the implementer's guide.
>
> The third major source of delay comes from the TTT
> wait - it's a cross-nexus delay and RFC 3720 requires
> it for completing the original TMF.  The Async-NopIn
> exchange enables us to take this wait out of the
> "performance path" by giving the target iSCSI layer a
> definitive event to free up the TTTs in a lazy
> fashion.

Why does it need to be cross-nexus, other than the fact that RFC 3720
says it should be?

My thought is that we just revise it to not be cross-nexus. Yes, a
given session is in the "waiting for things to stop" state until the
TTTs clear, but as long as the "instant of death" I mentioned in my
other mail has happened, I don't think that the TMF needs to wait.

> I don't like mandating TAS=1 for several reasons - a)
> it's a SCSI feature, b) it's not a default control
> mode page setting, c) it makes it harder to build
> iSCSI-to-XYZ bridges, d) puts iSCSI in a minor
> competitive disadvantage wrt other transports, e) it
> does not address the TTT problem with a
> multi-connection issuing session.  So I am glad you
> like the Async PDU approach.

I agree with (c) and (e), and they are enough to make me not like the
TAS=1-required idea.

> I would let David comment on the RFC revision part -
> but given all the other things we have been collecting
> in the iSCSI implementer's guide and given the guide
> will be published as an RFC that "updates" RFC 3720, I
> think it should be OK to include the new behavior in
> the guide.

Just to be clear, I like both the new abort proposal (AsyncEvent 5) and
also removing all long-wait inter-nexus delays. Obviously the
abort/reset will have to have started on all nodes before the TMF is
returned. :-)

Take care,

Bill
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0069F46FC22570CB_=-- --=_mixed 0069F46CC22570CB_= Content-Type: application/octet-stream; name="PGP.sig" Content-Disposition: attachment; filename="PGP.sig" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoRGFy d2luKQ0KDQppRDhEQlFGRGp5MEJESlQyRWdoMjZLMFJBa2oyQUtDT0tuNmtIRUhOZno2QVl3b0FH SWd4U0EyTFN3Q2RHNExJDQpWenlQQ29yNksrdisrYVBRZlNLdEVZQT0NCj1HeWZwDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --=_mixed 0069F46CC22570CB_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_mixed 0069F46CC22570CB_=-- From ips-bounces@ietf.org Sat Dec 03 12:43:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EibPc-0004A3-5D; Sat, 03 Dec 2005 12:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6ql-0003hV-TT for ips@megatron.ietf.org; Tue, 29 Nov 2005 09:52:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15209 for ; Tue, 29 Nov 2005 09:52:11 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh7Ak-0006K1-73 for ips@ietf.org; Tue, 29 Nov 2005 10:13:41 -0500 Received: by wproxy.gmail.com with SMTP id i6so2511026wra for ; Tue, 29 Nov 2005 06:52:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=umTZFqPIZVp7XTv4dEgdfi13eIZ9lVoGgnJ75l9eibYrTwtlYJAmfKHnt6Ug8SoD/c9ArDWnj9FJNpBltTTfpkgkUZwJeNElJd4ZPqU3S6rX+HdBKoNLBR05L16FkWZyOQTTdXD2jOcSa1r3Q90/4OWSJWuxuWXCg+b1dM4hL1g= Received: by 10.54.118.6 with SMTP id q6mr8668526wrc; Tue, 29 Nov 2005 06:52:45 -0800 (PST) Received: from ?9.148.18.67? ( [192.114.107.4]) by mx.gmail.com with ESMTP id g9sm1964241wra.2005.11.29.06.52.44; Tue, 29 Nov 2005 06:52:45 -0800 (PST) Message-ID: <438C6B38.1000707@haifasphere.co.il> Date: Tue, 29 Nov 2005 16:52:40 +0200 User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Sears_Bill@emc.com Subject: Re: [Ips] Question regarding SessionType References: <05AADEB492F5824996D28D50468673990621AE@CORPUSMX40A.corp.emc.com> In-Reply-To: <05AADEB492F5824996D28D50468673990621AE@CORPUSMX40A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Julian Satran X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 03 Dec 2005 12:43:01 -0500 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bill, Unfortunately the text of RFC3720 does not agree with your assumptions. The session type can be specified at any stage as explicitly stated in chapters 11 and 12. I can't think of a good reason we should limit its use (or even recommend it as good practice in the implementor guide). Julo Sears_Bill@emc.com wrote: > > > > rfc3720 section 5.3 states: > > The initial login request of the first connection of a session MAY > also include the SessionType key=value pair. > > The use of the word 'MAY' here is bothersome. Does this mean that an > initiator may leave out the session type in the first request but then > explicitly specify it later? This seems possible but very annoying. > For example: > > During Security stage it seems that an initiator could leave out > SessionType but specify a TargetName=. Later during > operational stage the initiator could specify SessionType=Discovery. > It seems that this is allowed. > > Currently I am assuming that if the SessionType is not specified in > the initial login request of the first connection that the initiator > is implicitly negotiating for SessionType=Normal. In this case I > wont send SessionType=Normal in a response PDU but I will assume that > SessionType has been negotiated to its default value of Normal. I > regard seeing SessionType in any subsequent LoginRequest PDU as an > error. > > > > Bill > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Dec 03 12:43:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EibPc-0004AS-N1; Sat, 03 Dec 2005 12:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh7RJ-0000Ye-Lo for ips@megatron.ietf.org; Tue, 29 Nov 2005 10:30:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20339 for ; Tue, 29 Nov 2005 10:29:56 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh7lO-0007o8-Qc for ips@ietf.org; Tue, 29 Nov 2005 10:51:28 -0500 Received: by wproxy.gmail.com with SMTP id i6so2521180wra for ; Tue, 29 Nov 2005 07:30:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:from; b=J0YnlKnPrzqnbroP715/uINYvjcjhDRBDwMl4kE3zKnwUsPemdMdHDOpR5z1HkqWhWLFBQULxw+6UM0R1jzg2WFRrQzzNfabn7LCzSM735dJp63IedklBB7gVB9MGzdkFZa+WdrSdrOwBpGW1WlHrY5EmoIOvLJefhv7dgy5aqo= Received: by 10.54.119.17 with SMTP id r17mr6814434wrc; Tue, 29 Nov 2005 07:30:39 -0800 (PST) Received: from ?9.148.18.67? ( [192.114.107.4]) by mx.gmail.com with ESMTP id g9sm2039739wra.2005.11.29.07.30.37; Tue, 29 Nov 2005 07:30:38 -0800 (PST) Message-ID: <438C7418.50502@cs.haifa.ac.il> Date: Tue, 29 Nov 2005 17:30:32 +0200 User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: ips@ietf.org Subject: [Fwd: Re: [Ips] Question regarding SessionType] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Julian Satran X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 03 Dec 2005 12:43:01 -0500 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org -------- Original Message -------- Subject: Re: [Ips] Question regarding SessionType Date: Tue, 29 Nov 2005 16:52:40 +0200 From: Julian Satran To: Sears_Bill@emc.com CC: ips@ietf.org References: <05AADEB492F5824996D28D50468673990621AE@CORPUSMX40A.corp.emc.com> Bill, Unfortunately the text of RFC3720 does not agree with your assumptions. The session type can be specified at any stage as explicitly stated in chapters 11 and 12. I can't think of a good reason we should limit its use (or even recommend it as good practice in the implementor guide). Julo Sears_Bill@emc.com wrote: > > > > rfc3720 section 5.3 states: > > The initial login request of the first connection of a session MAY > also include the SessionType key=value pair. > > The use of the word 'MAY' here is bothersome. Does this mean that an > initiator may leave out the session type in the first request but then > explicitly specify it later? This seems possible but very annoying. > For example: > > During Security stage it seems that an initiator could leave out > SessionType but specify a TargetName=. Later during > operational stage the initiator could specify SessionType=Discovery. > It seems that this is allowed. > > Currently I am assuming that if the SessionType is not specified in > the initial login request of the first connection that the initiator > is implicitly negotiating for SessionType=Normal. In this case I > wont send SessionType=Normal in a response PDU but I will assume that > SessionType has been negotiated to its default value of Normal. I > regard seeing SessionType in any subsequent LoginRequest PDU as an > error. > > > > Bill > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Dec 03 13:54:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EicWj-0004Hg-G6; Sat, 03 Dec 2005 13:54:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EicWi-0004Hb-5i for ips@megatron.ietf.org; Sat, 03 Dec 2005 13:54:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22837 for ; Sat, 3 Dec 2005 13:53:40 -0500 (EST) From: Black_David@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eicrc-000862-ED for ips@ietf.org; Sat, 03 Dec 2005 14:16:06 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.6) with ESMTP id jB3IsALC016354; Sat, 3 Dec 2005 13:54:10 -0500 (EST) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id jB3Is7P1003502; Sat, 3 Dec 2005 13:54:07 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 3 Dec 2005 13:54:07 -0500 Message-ID: To: Julian_Satran@il.ibm.com Subject: RE: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement Date: Sat, 3 Dec 2005 13:54:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.12.3.20 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, HTML_50_70 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 1.2 (+) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347600936==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0347600936== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F83A.EDCD283D" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5F83A.EDCD283D Content-Type: text/plain Independent of "legal best", "practical best" is the Implementers Guide where we can say things like "not REQUIRED" to make it abundantly clear. RFC Errata processing is currently broken for all practical purposes at the RFC Editor. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist 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 ---------------------------------------------------- _____ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran Sent: Saturday, November 19, 2005 7:59 PM To: William Studenmund Cc: ips@ietf.org; Pittman, Joseph; ips-bounces@ietf.org Subject: Re: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement You are right and we have to fix this somewhere (errata is probably the legal best). Julo William Studenmund Sent by: ips-bounces@ietf.org 15-11-05 13:28 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org, "Pittman, Joseph" Subject Re: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement On Nov 15, 2005, at 1:29 AM, Julian Satran wrote: > William Studenmund wrote on 14-11-2005 > 21:26:31: > > > Waiting for other sessions to finish any form of processing is my > > biggest concern with how we handle aborts. > > Joseph concern (as I read it) was related to waiting for status ack on > other nexi before handing the initiator the response to the TM > command. > This is not required by iSCSI. Actually, I was just re-reading the Abort Task Set and Clear Task Set text, and the status ack requirement is in RFC 3720. It's in section 10.6.2 on page 136, in step d) of the "The target:" events section: d) Takes note of last-sent StatSN on each of the connections in the iSCSI sessions (one or more) sharing the affected task set, and waits for acknowledgement of each StatSN (may solicit for acknowledgement by way of a NOP-In). If some tasks originate from non-iSCSI I_T_L nexi then the means by which the target insures that all affected tasks have returned their status to the initiator are defined by the specific protocol. So the concern Joseph has (which I also have as best I understand everyone's position) does apply to RFC 3720. :-| Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C5F83A.EDCD283D Content-Type: text/html
Independent of "legal best", "practical best" is the Implementers
Guide where we can say things like "not REQUIRED" to make it
abundantly clear.
 
RFC Errata processing is currently broken for all practical purposes
at the RFC Editor.
 
Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
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
----------------------------------------------------


From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran
Sent: Saturday, November 19, 2005 7:59 PM
To: William Studenmund
Cc: ips@ietf.org; Pittman, Joseph; ips-bounces@ietf.org
Subject: Re: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement


You are right and we have to fix this somewhere (errata is probably the legal best). Julo


William Studenmund <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org

15-11-05 13:28

To
Julian Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org, "Pittman, Joseph" <Joseph.Pittman@netapp.com>
Subject
Re: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement





On Nov 15, 2005, at 1:29 AM, Julian Satran wrote:

> William Studenmund <wrstuden@wasabisystems.com> wrote on 14-11-2005
> 21:26:31:
>
>  > Waiting for other sessions to finish any form of processing is my
>  > biggest concern with how we handle aborts.
>
> Joseph concern (as I read it) was related to waiting for status ack on
> other nexi before handing the initiator the response to the TM
> command.
> This is not required by iSCSI.

Actually, I was just re-reading the Abort Task Set and Clear Task Set
text, and the status ack requirement is in RFC 3720. It's in section
10.6.2 on page 136, in step d) of the "The target:" events section:

         d) Takes note of last-sent StatSN on each of the connections in
            the iSCSI sessions (one or more) sharing the affected task
            set, and waits for acknowledgement of each StatSN (may
            solicit for acknowledgement by way of a NOP-In).  If some
            tasks originate from non-iSCSI I_T_L nexi then the means by
            which the target insures that all affected tasks have
            returned their status to the initiator are defined by the
            specific protocol.

So the concern Joseph has (which I also have as best I understand
everyone's position) does apply to RFC 3720. :-|

Take care,

Bill
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C5F83A.EDCD283D-- --===============0347600936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0347600936==-- From ips-bounces@ietf.org Sat Dec 03 14:06:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eicim-0000Ba-B6; Sat, 03 Dec 2005 14:06:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eicil-0000BV-1M for ips@megatron.ietf.org; Sat, 03 Dec 2005 14:06:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23926 for ; Sat, 3 Dec 2005 14:06:07 -0500 (EST) From: Black_David@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eid3h-0008RA-Or for ips@ietf.org; Sat, 03 Dec 2005 14:28:34 -0500 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.6) with ESMTP id jB3J6kLC019686 for ; Sat, 3 Dec 2005 14:06:46 -0500 (EST) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id jB3J6gLg025820 for ; Sat, 3 Dec 2005 14:06:42 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 3 Dec 2005 14:06:42 -0500 Message-ID: To: ips@ietf.org Subject: RE: [Ips] Fast multi-task abort model Date: Sat, 3 Dec 2005 14:06:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.12.3.20 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > > I would let David comment on the RFC revision part - > > but given all the other things we have been collecting > > in the iSCSI implementer's guide and given the guide > > will be published as an RFC that "updates" RFC 3720, I > > think it should be OK to include the new behavior in > > the guide. > > Just to be clear, I like both the new abort proposal (AsyncEvent 5) and > also removing all long-wait inter-nexus delays. Obviously the > abort/reset will have to have started on all nodes before the TMF is > returned. :-) Yes, as long as this is fully backwards compatible (which will be achieved via negotiation of the next text key on login), it's fine to include in the implementer's guide. Taking off my WG Chair hat, I think the new abort proposal (AsyncEvent 5) is a good idea, but I'm going to be looking to Mallikarjun, Bill, Julian, and others on the list to work through all the details. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Dec 03 14:20:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eicvk-00050r-0R; Sat, 03 Dec 2005 14:20:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eicvi-000507-Me for ips@megatron.ietf.org; Sat, 03 Dec 2005 14:20:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25165 for ; Sat, 3 Dec 2005 14:19:30 -0500 (EST) From: Black_David@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EidGe-0000NK-Hg for ips@ietf.org; Sat, 03 Dec 2005 14:41:57 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.6) with ESMTP id jB3JK8LC023785 for ; Sat, 3 Dec 2005 14:20:08 -0500 (EST) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id jB3JK6NL001346 for ; Sat, 3 Dec 2005 14:20:06 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 3 Dec 2005 14:20:06 -0500 Message-ID: To: ips@ietf.org Date: Sat, 3 Dec 2005 14:20:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.12.3.21 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Black_David@emc.com Subject: [Ips] IPS WG will meet in March in Dallas X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Unless I hear strong objections to the contrary, I will schedule a meeting of the IP Storage (ips) WG at the next (65th) IETF meeting in Dallas in March. I'm announcing this now since the IPS WG did not meet in Vancouver last month. There are two primary reasons for meeting in Dallas: - Progress check on the iSCSI Implementers Guide draft. In particular, some face-to-face time with diagrams could be quite useful in making sure that the details and corner cases are correct in the evolving multi-task abort proposal, as well as other task management cleanup. - Review of the structural and functional changes in the new iSNS MIB. In connection with the latter, this message serves to put the iSNS MIB draft authors on notice that a revised draft of the iSNS MIB that is deemed reasonably close to acceptable by the WG Chair (me), the WG MIB Expert (Keith) and the responsible AD (Allison) is required by the March IETF meeting, and the iSNS MIB draft authors should plan for multiple versions of the MIB between now and then to meet this goal. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Dec 05 01:17:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej9en-0008D7-Kd; Mon, 05 Dec 2005 01:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej9el-0008Cd-5R for ips@megatron.ietf.org; Mon, 05 Dec 2005 01:16:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04349 for ; Mon, 5 Dec 2005 01:16:07 -0500 (EST) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ej9zy-0003LQ-Qk for ips@ietf.org; Mon, 05 Dec 2005 01:38:55 -0500 Received: from [10.25.10.58] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1Ej9bI-0007Gh-00; Mon, 05 Dec 2005 06:13:24 +0000 From: "Ken Sandars" To: "'Julian Satran'" , Subject: RE: [Ips] Question regarding SessionType Date: Mon, 5 Dec 2005 17:15:54 +1100 Message-ID: <002701c5f963$6fab6830$640115ac@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <438C6B38.1000707@haifasphere.co.il> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Julo, I think there is merit in having a recommendation in the implementor = guide that if the SessionType key is going to be set to "Discovery", it should = be set in the initial Login request. Clearly this only affects named sessions since the only legal unnamed session requires SessionType=3DDiscovery in the initial Login request. Say an initiator wants to create a named discovery session but doesn't supply SessionType in the initial Login request. The target will assume = the SessionType is Normal (as it is the default value), and negotiate accordingly. Some consequences of this are: 1. The initiator will have to be prepared to negotiate Normal session parameters which the target may offer - such as MaxConnections, MaxBurstLength, etc. 2. If a target is configured to operate without security for Discovery sessions but with it for Normal sessions, the initiator cannot = successfully bypass the security phase. 3. The target might make different resource allocation decisions = dependant on the type of session. A Discovery session has much less scope for consuming system resources than a Normal session. The target = implementation may reject the login due to resource constraints when in fact there are = none for this session. 4. Some keys must be negotiated with knowledge of the SessionType. For example, in the implementor's guide, section 5.1 - the = ErrorRecoveryLevel value MUST be negotiated to 0 for Discovery sessions. MaxRecvDataSegmentLength might be declared differently for different = session types so the target has to hold off with its declaration until either = the final Login request or SessionType is explicitly declared. While none of these consequences are show-stoppers, they do add = complexity which would be nice to avoid. To recommend this in the implementor guide should have very little impact as I don't think the named-discovery = session is in common use (at all?). Thanks, Ken Sandars > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Julian Satran > Sent: 30 November 2005 01:53 > To: Sears_Bill@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] Question regarding SessionType >=20 >=20 > Bill, >=20 > Unfortunately the text of RFC3720 does not agree with your=20 > assumptions. > The session type can be specified at any stage as explicitly=20 > stated in=20 > chapters 11 and 12. > I can't think of a good reason we should limit its use (or even=20 > recommend it as good practice in the implementor guide). >=20 > Julo >=20 > Sears_Bill@emc.com wrote: > > > > =20 > > > > rfc3720 section 5.3 states: > > > > The initial login request of the first connection of a session MAY=20 > > also include the SessionType key=3Dvalue pair. > > > > The use of the word 'MAY' here is bothersome. Does this=20 > mean that an=20 > > initiator may leave out the session type in the first=20 > request but then=20 > > explicitly specify it later? This seems possible but very=20 > annoying. =20 > > For example: > > > > During Security stage it seems that an initiator could leave out=20 > > SessionType but specify a TargetName=3D. Later during=20 > > operational stage the initiator could specify=20 > SessionType=3DDiscovery. =20 > > It seems that this is allowed. > > > > Currently I am assuming that if the SessionType is not specified in=20 > > the initial login request of the first connection that the=20 > initiator=20 > > is implicitly negotiating for SessionType=3DNormal. In this case I = > > wont send SessionType=3DNormal in a response PDU but I will=20 > assume that=20 > > SessionType has been negotiated to its default value of Normal. I=20 > > regard seeing SessionType in any subsequent LoginRequest PDU as an=20 > > error.=20 > > > > =20 > > > > Bill > > > > =20 > > > >=20 > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > =20 >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Dec 05 07:08:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjF8z-0001ss-G3; Mon, 05 Dec 2005 07:08:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjF8x-0001s8-Mj for ips@megatron.ietf.org; Mon, 05 Dec 2005 07:08:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07565 for ; Mon, 5 Dec 2005 07:07:38 -0500 (EST) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjFUC-0006Kd-Dy for ips@ietf.org; Mon, 05 Dec 2005 07:30:29 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id jB5C8LLs092296 for ; Mon, 5 Dec 2005 12:08:21 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB5C8Dcr155958 for ; Mon, 5 Dec 2005 13:08:13 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jB5C8DZw006383 for ; Mon, 5 Dec 2005 13:08:13 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jB5C8CSP006374; Mon, 5 Dec 2005 13:08:13 +0100 In-Reply-To: <002701c5f963$6fab6830$640115ac@elipsan.com> To: "Ken Sandars" Subject: RE: [Ips] Question regarding SessionType MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Julian Satran Message-ID: Date: Mon, 5 Dec 2005 14:08:11 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.51HF338 | June 21, 2004) at 05/12/2005 14:08:12, Serialize complete at 05/12/2005 14:08:12 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Cc: ips@ietf.org, Sears_Bill@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0652435977==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0652435977== Content-Type: multipart/alternative; boundary="=_alternative 0042AA47C22570CE_=" This is a multipart message in MIME format. --=_alternative 0042AA47C22570CE_= Content-Type: text/plain; charset="US-ASCII" Ken, Even if we put is a good practice in the implementer's guide it would merely help in avoiding some nasty bugs in the initiator and/or target. And we can't mandate it in the implementoer's guide. The supporting code for all the exceptions you mention has to be there and not only because of the session type placement but because the normal session type has to be supported. All of your arguments would make sense only if you envision an implementation that supports the two session types with separate pieces of code or even boxes. Julo "Ken Sandars" Sent by: ips-bounces@ietf.org 05-12-05 08:15 To "'Julian Satran'" , cc ips@ietf.org Subject RE: [Ips] Question regarding SessionType Hi Julo, I think there is merit in having a recommendation in the implementor guide that if the SessionType key is going to be set to "Discovery", it should be set in the initial Login request. Clearly this only affects named sessions since the only legal unnamed session requires SessionType=Discovery in the initial Login request. Say an initiator wants to create a named discovery session but doesn't supply SessionType in the initial Login request. The target will assume the SessionType is Normal (as it is the default value), and negotiate accordingly. Some consequences of this are: 1. The initiator will have to be prepared to negotiate Normal session parameters which the target may offer - such as MaxConnections, MaxBurstLength, etc. 2. If a target is configured to operate without security for Discovery sessions but with it for Normal sessions, the initiator cannot successfully bypass the security phase. 3. The target might make different resource allocation decisions dependant on the type of session. A Discovery session has much less scope for consuming system resources than a Normal session. The target implementation may reject the login due to resource constraints when in fact there are none for this session. 4. Some keys must be negotiated with knowledge of the SessionType. For example, in the implementor's guide, section 5.1 - the ErrorRecoveryLevel value MUST be negotiated to 0 for Discovery sessions. MaxRecvDataSegmentLength might be declared differently for different session types so the target has to hold off with its declaration until either the final Login request or SessionType is explicitly declared. While none of these consequences are show-stoppers, they do add complexity which would be nice to avoid. To recommend this in the implementor guide should have very little impact as I don't think the named-discovery session is in common use (at all?). Thanks, Ken Sandars > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Julian Satran > Sent: 30 November 2005 01:53 > To: Sears_Bill@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] Question regarding SessionType > > > Bill, > > Unfortunately the text of RFC3720 does not agree with your > assumptions. > The session type can be specified at any stage as explicitly > stated in > chapters 11 and 12. > I can't think of a good reason we should limit its use (or even > recommend it as good practice in the implementor guide). > > Julo > > Sears_Bill@emc.com wrote: > > > > > > > > rfc3720 section 5.3 states: > > > > The initial login request of the first connection of a session MAY > > also include the SessionType key=value pair. > > > > The use of the word 'MAY' here is bothersome. Does this > mean that an > > initiator may leave out the session type in the first > request but then > > explicitly specify it later? This seems possible but very > annoying. > > For example: > > > > During Security stage it seems that an initiator could leave out > > SessionType but specify a TargetName=. Later during > > operational stage the initiator could specify > SessionType=Discovery. > > It seems that this is allowed. > > > > Currently I am assuming that if the SessionType is not specified in > > the initial login request of the first connection that the > initiator > > is implicitly negotiating for SessionType=Normal. In this case I > > wont send SessionType=Normal in a response PDU but I will > assume that > > SessionType has been negotiated to its default value of Normal. I > > regard seeing SessionType in any subsequent LoginRequest PDU as an > > error. > > > > > > > > Bill > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0042AA47C22570CE_= Content-Type: text/html; charset="US-ASCII"
Ken,

Even if we put is a good practice in the implementer's guide it would merely help in avoiding some nasty bugs in the initiator and/or target. And we can't mandate it in the implementoer's guide.

The supporting code for all the exceptions you mention has to be there and not only because of the session type placement but because the normal session type has to be supported. All of your arguments would make sense only if you envision an implementation that supports the two session types with separate pieces of code or even boxes.

Julo


"Ken Sandars" <ken_sandars@adaptec.com>
Sent by: ips-bounces@ietf.org

05-12-05 08:15

To
"'Julian Satran'" <julian.satran@gmail.com>, <Sears_Bill@emc.com>
cc
ips@ietf.org
Subject
RE: [Ips] Question regarding SessionType





Hi Julo,

I think there is merit in having a recommendation in the implementor guide
that if the SessionType key is going to be set to "Discovery", it should be
set in the initial Login request.

Clearly this only affects named sessions since the only legal unnamed
session requires SessionType=Discovery in the initial Login request.

Say an initiator wants to create a named discovery session but doesn't
supply SessionType in the initial Login request. The target will assume the
SessionType is Normal (as it is the default value), and negotiate
accordingly. Some consequences of this are:

1. The initiator will have to be prepared to negotiate Normal session
parameters which the target may offer - such as MaxConnections,
MaxBurstLength, etc.

2. If a target is configured to operate without security for Discovery
sessions but with it for Normal sessions, the initiator cannot successfully
bypass the security phase.

3. The target might make different resource allocation decisions dependant
on the type of session. A Discovery session has much less scope for
consuming system resources than a Normal session. The target implementation
may reject the login due to resource constraints when in fact there are none
for this session.

4. Some keys must be negotiated with knowledge of the SessionType. For
example, in the implementor's guide, section 5.1 - the ErrorRecoveryLevel
value MUST be negotiated to 0 for Discovery sessions.
MaxRecvDataSegmentLength might be declared differently for different session
types so the target has to hold off with its declaration until either the
final Login request or SessionType is explicitly declared.

While none of these consequences are show-stoppers, they do add complexity
which would be nice to avoid. To recommend this in the implementor guide
should have very little impact as I don't think the named-discovery session
is in common use (at all?).


Thanks,
Ken Sandars

> -----Original Message-----
> From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On
> Behalf Of Julian Satran
> Sent: 30 November 2005 01:53
> To: Sears_Bill@emc.com
> Cc: ips@ietf.org
> Subject: Re: [Ips] Question regarding SessionType
>
>
> Bill,
>
> Unfortunately the text of RFC3720 does not agree with your
> assumptions.
> The session type can be specified at any stage as explicitly
> stated in
> chapters 11 and 12.
> I can't think of a good reason we should limit its use (or even
> recommend it as good practice in the implementor guide).
>
> Julo
>
> Sears_Bill@emc.com wrote:
> >
> >  
> >
> > rfc3720 section 5.3 states:
> >
> > The initial login request of the first connection of a session MAY
> > also include the SessionType key=value pair.
> >
> > The use of the word 'MAY' here is bothersome.   Does this
> mean that an
> > initiator may leave out the session type in the first
> request but then
> > explicitly specify it later?  This seems possible but very
> annoying.  
> > For example:
> >
> > During Security stage it seems that an initiator could leave out
> > SessionType but specify a TargetName=<something>.   Later during
> > operational stage the initiator could specify
> SessionType=Discovery.  
> > It seems that this is allowed.
> >
> > Currently I am assuming that if the SessionType is not specified in
> > the initial login request of the first connection that the
> initiator
> > is implicitly negotiating for SessionType=Normal.   In this case I
> > wont send SessionType=Normal in a response PDU but I will
> assume that
> > SessionType has been negotiated to its default value of Normal.   I
> > regard seeing SessionType in any subsequent LoginRequest PDU as an
> > error.
> >
> >  
> >
> > Bill
> >
> >  
> >
> >
> --------------------------------------------------------------
> ----------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >  
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>
>



_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0042AA47C22570CE_=-- --===============0652435977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0652435977==-- From ips-bounces@ietf.org Mon Dec 05 10:28:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjIGk-0001Wa-FP; Mon, 05 Dec 2005 10:28:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjIGh-0001W4-Ok for ips@megatron.ietf.org; Mon, 05 Dec 2005 10:28:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02929 for ; Mon, 5 Dec 2005 10:27:54 -0500 (EST) From: Black_David@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjIbz-0005jo-1r for ips@ietf.org; Mon, 05 Dec 2005 10:50:45 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.6) with ESMTP id jB5FSNLC015121; Mon, 5 Dec 2005 10:28:23 -0500 (EST) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id jB5FSJAU025528; Mon, 5 Dec 2005 10:28:19 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Dec 2005 10:28:19 -0500 Message-ID: To: Julian_Satran@il.ibm.com Subject: RE: [Ips] Question regarding SessionType Date: Mon, 5 Dec 2005 10:28:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.12.5.13 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.9 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0478840034==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0478840034== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F9B0.813FFCDC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5F9B0.813FFCDC Content-Type: text/plain I think a "SHOULD" in the Implementer's Guide for the suggestion Ken makes is fine: if the SessionType key is going to be set to "Discovery", it SHOULD be set in the initial Login request Declaring one's intentions up front seems like a good idea in general. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist 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 ---------------------------------------------------- _____ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran Sent: Monday, December 05, 2005 7:08 AM To: Ken Sandars Cc: ips@ietf.org; Sears, Bill Subject: RE: [Ips] Question regarding SessionType Ken, Even if we put is a good practice in the implementer's guide it would merely help in avoiding some nasty bugs in the initiator and/or target. And we can't mandate it in the implementoer's guide. The supporting code for all the exceptions you mention has to be there and not only because of the session type placement but because the normal session type has to be supported. All of your arguments would make sense only if you envision an implementation that supports the two session types with separate pieces of code or even boxes. Julo "Ken Sandars" Sent by: ips-bounces@ietf.org 05-12-05 08:15 To "'Julian Satran'" , cc ips@ietf.org Subject RE: [Ips] Question regarding SessionType Hi Julo, I think there is merit in having a recommendation in the implementor guide that if the SessionType key is going to be set to "Discovery", it should be set in the initial Login request. Clearly this only affects named sessions since the only legal unnamed session requires SessionType=Discovery in the initial Login request. Say an initiator wants to create a named discovery session but doesn't supply SessionType in the initial Login request. The target will assume the SessionType is Normal (as it is the default value), and negotiate accordingly. Some consequences of this are: 1. The initiator will have to be prepared to negotiate Normal session parameters which the target may offer - such as MaxConnections, MaxBurstLength, etc. 2. If a target is configured to operate without security for Discovery sessions but with it for Normal sessions, the initiator cannot successfully bypass the security phase. 3. The target might make different resource allocation decisions dependant on the type of session. A Discovery session has much less scope for consuming system resources than a Normal session. The target implementation may reject the login due to resource constraints when in fact there are none for this session. 4. Some keys must be negotiated with knowledge of the SessionType. For example, in the implementor's guide, section 5.1 - the ErrorRecoveryLevel value MUST be negotiated to 0 for Discovery sessions. MaxRecvDataSegmentLength might be declared differently for different session types so the target has to hold off with its declaration until either the final Login request or SessionType is explicitly declared. While none of these consequences are show-stoppers, they do add complexity which would be nice to avoid. To recommend this in the implementor guide should have very little impact as I don't think the named-discovery session is in common use (at all?). Thanks, Ken Sandars > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Julian Satran > Sent: 30 November 2005 01:53 > To: Sears_Bill@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] Question regarding SessionType > > > Bill, > > Unfortunately the text of RFC3720 does not agree with your > assumptions. > The session type can be specified at any stage as explicitly > stated in > chapters 11 and 12. > I can't think of a good reason we should limit its use (or even > recommend it as good practice in the implementor guide). > > Julo > > Sears_Bill@emc.com wrote: > > > > > > > > rfc3720 section 5.3 states: > > > > The initial login request of the first connection of a session MAY > > also include the SessionType key=value pair. > > > > The use of the word 'MAY' here is bothersome. Does this > mean that an > > initiator may leave out the session type in the first > request but then > > explicitly specify it later? This seems possible but very > annoying. > > For example: > > > > During Security stage it seems that an initiator could leave out > > SessionType but specify a TargetName=. Later during > > operational stage the initiator could specify > SessionType=Discovery. > > It seems that this is allowed. > > > > Currently I am assuming that if the SessionType is not specified in > > the initial login request of the first connection that the > initiator > > is implicitly negotiating for SessionType=Normal. In this case I > > wont send SessionType=Normal in a response PDU but I will > assume that > > SessionType has been negotiated to its default value of Normal. I > > regard seeing SessionType in any subsequent LoginRequest PDU as an > > error. > > > > > > > > Bill > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C5F9B0.813FFCDC Content-Type: text/html
I think a "SHOULD" in the Implementer's Guide for the suggestion Ken
makes is fine:
 
    if the SessionType key is going to be set to "Discovery", it SHOULD
    be set in the initial Login request
 
Declaring one's intentions up front seems like a good idea in general.
 
Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
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
----------------------------------------------------


From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran
Sent: Monday, December 05, 2005 7:08 AM
To: Ken Sandars
Cc: ips@ietf.org; Sears, Bill
Subject: RE: [Ips] Question regarding SessionType


Ken,

Even if we put is a good practice in the implementer's guide it would merely help in avoiding some nasty bugs in the initiator and/or target. And we can't mandate it in the implementoer's guide.

The supporting code for all the exceptions you mention has to be there and not only because of the session type placement but because the normal session type has to be supported. All of your arguments would make sense only if you envision an implementation that supports the two session types with separate pieces of code or even boxes.

Julo


"Ken Sandars" <ken_sandars@adaptec.com>
Sent by: ips-bounces@ietf.org

05-12-05 08:15

To
"'Julian Satran'" <julian.satran@gmail.com>, <Sears_Bill@emc.com>
cc
ips@ietf.org
Subject
RE: [Ips] Question regarding SessionType





Hi Julo,

I think there is merit in having a recommendation in the implementor guide
that if the SessionType key is going to be set to "Discovery", it should be
set in the initial Login request.

Clearly this only affects named sessions since the only legal unnamed
session requires SessionType=Discovery in the initial Login request.

Say an initiator wants to create a named discovery session but doesn't
supply SessionType in the initial Login request. The target will assume the
SessionType is Normal (as it is the default value), and negotiate
accordingly. Some consequences of this are:

1. The initiator will have to be prepared to negotiate Normal session
parameters which the target may offer - such as MaxConnections,
MaxBurstLength, etc.

2. If a target is configured to operate without security for Discovery
sessions but with it for Normal sessions, the initiator cannot successfully
bypass the security phase.

3. The target might make different resource allocation decisions dependant
on the type of session. A Discovery session has much less scope for
consuming system resources than a Normal session. The target implementation
may reject the login due to resource constraints when in fact there are none
for this session.

4. Some keys must be negotiated with knowledge of the SessionType. For
example, in the implementor's guide, section 5.1 - the ErrorRecoveryLevel
value MUST be negotiated to 0 for Discovery sessions.
MaxRecvDataSegmentLength might be declared differently for different session
types so the target has to hold off with its declaration until either the
final Login request or SessionType is explicitly declared.

While none of these consequences are show-stoppers, they do add complexity
which would be nice to avoid. To recommend this in the implementor guide
should have very little impact as I don't think the named-discovery session
is in common use (at all?).


Thanks,
Ken Sandars

> -----Original Message-----
> From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On
> Behalf Of Julian Satran
> Sent: 30 November 2005 01:53
> To: Sears_Bill@emc.com
> Cc: ips@ietf.org
> Subject: Re: [Ips] Question regarding SessionType
>
>
> Bill,
>
> Unfortunately the text of RFC3720 does not agree with your
> assumptions.
> The session type can be specified at any stage as explicitly
> stated in
> chapters 11 and 12.
> I can't think of a good reason we should limit its use (or even
> recommend it as good practice in the implementor guide).
>
> Julo
>
> Sears_Bill@emc.com wrote:
> >
> >  
> >
> > rfc3720 section 5.3 states:
> >
> > The initial login request of the first connection of a session MAY
> > also include the SessionType key=value pair.
> >
> > The use of the word 'MAY' here is bothersome.   Does this
> mean that an
> > initiator may leave out the session type in the first
> request but then
> > explicitly specify it later?  This seems possible but very
> annoying.  
> > For example:
> >
> > During Security stage it seems that an initiator could leave out
> > SessionType but specify a TargetName=<something>.   Later during
> > operational stage the initiator could specify
> SessionType=Discovery.  
> > It seems that this is allowed.
> >
> > Currently I am assuming that if the SessionType is not specified in
> > the initial login request of the first connection that the
> initiator
> > is implicitly negotiating for SessionType=Normal.   In this case I
> > wont send SessionType=Normal in a response PDU but I will
> assume that
> > SessionType has been negotiated to its default value of Normal.   I
> > regard seeing SessionType in any subsequent LoginRequest PDU as an
> > error.
> >
> >  
> >
> > Bill
> >
> >  
> >
> >
> --------------------------------------------------------------
> ----------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >  
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>
>



_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C5F9B0.813FFCDC-- --===============0478840034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0478840034==-- From ips-bounces@ietf.org Mon Dec 05 16:01:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNSk-0001Og-0k; Mon, 05 Dec 2005 16:01:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNSh-0001Nf-4M for ips@megatron.ietf.org; Mon, 05 Dec 2005 16:01:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10248 for ; Mon, 5 Dec 2005 16:00:37 -0500 (EST) Received: from [64.238.111.98] (helo=thoth.ivivity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjNo2-0000mV-Az for ips@ietf.org; Mon, 05 Dec 2005 16:23:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Dec 2005 16:01:07 -0500 Message-ID: <0F31272A2BCBBE4FA01344C6E69DBF5029600A@thoth.ivivity.com> Thread-Topic: Qs: draft-ietf-rddp-rdmap-05 Thread-Index: AcX53wSMe3A3rJg9Q3iyLYxKBovaJQ== From: "Sanjay Goyal" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Subject: [Ips] Qs: draft-ietf-rddp-rdmap-05 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1418306006==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1418306006== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F9DF.03003503" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F9DF.03003503 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As per draft-ietf-rddp-rdmap-05.txt,=20 =20 page 50, Item14: =20 "A Send or RDMA Write Message MUST NOT be considered Complete=20 at the Local Peer (Data Source) until it has been successfully=20 completed at the DDP layer."=20 Q1. What does "successfully completed at the DDP layer" mean? Is it referring to TCP ack? =20 Also Section 8.2.1 item 1 mentions: "An RNIC MUST ensure that a specific Stream in a specific Protection Domain cannot access an STag in a different Protection Domain."=20 Q2. What does Protection Domain mean? =20 =20 Regards, =20 Sanjay Goyal 678-990-1550 x204 iVivity Inc. Norcross, GA 30093 ------_=_NextPart_001_01C5F9DF.03003503 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
As=20 per draft-ietf-rddp-rdmap-05.txt,=20
 
page 50, Item14:   =
    "A Send or=20 RDMA Write Message MUST NOT be considered Complete

    at the Local = Peer (Data=20 Source) until it has been successfully

    completed at = the DDP=20 layer."

Q1. What=20 does "successfully completed at the DDP layer" mean? Is it = referring=20 to TCP ack?

 

Also Section 8.2.1 = item 1=20 mentions:

  "An RNIC MUST ensure that = a specific=20 Stream in a  specific Protection Domain cannot = access an=20 STag in a different Protection=20 Domain." 

Q2. What does Protection Domain=20 mean?

 

 

Regards,
 
Sanjay Goyal
678-990-1550 = x204
iVivity Inc.
Norcross, GA=20 30093
= ------_=_NextPart_001_01C5F9DF.03003503-- --===============1418306006== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1418306006==-- From ips-bounces@ietf.org Mon Dec 05 16:35:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNzB-0001Mp-Cb; Mon, 05 Dec 2005 16:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNz7-0001Ln-Ab; Mon, 05 Dec 2005 16:34:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13911; Mon, 5 Dec 2005 16:34:07 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjOKU-0001t9-6X; Mon, 05 Dec 2005 16:57:02 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EjNz4-0005om-3V; Mon, 05 Dec 2005 16:34:54 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 05 Dec 2005 16:34:54 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Definitions of Managed Objects for FCIP' to Proposed Standard X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Definitions of Managed Objects for FCIP ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-mib-09.txt-09.txt Technical Summary This document defines a portion of the Management Information Base (MIB). It specifies objects for managing FCIP (Fibre Channel over TCP/IP) entities (RFC 3821), which are used to interconnect FC fabrics with IP networks. Working Group Summary The working group reached consensus on the MIB. The group hoped to have the MIB reviewed and published around the same time as RFC 3821, but it turned out the MIB review was not possible in the timeframe. Protocol Quality The working group's MIB advisor was Keith McCloghrie. The MIB Doctor was Bert Wijnen. There were two revisions of the MIB addressing review comments. The WG Chair shepherd is David Black, taking over from his former co-Chair, Elizabeth Rodriguez. Allison Mankin is the Responsible Area Director. Notes to RFC Editor Title, Abstract and Introduction: please expand the first use of FC and FCIP in each. Please make these expansions consistent with the expansions used in RFC 3821. Security Considerations OLD: In particular, write access to fcipDiscoveryDomainName and fcipEntityAddress can cause a loss of reachability to portions of the SAN NEW: In particular, write access to fcipDiscoveryDomainName and fcipEntityAddress can cause a loss of reachability to portions of the Fibre Channel fabric _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Dec 06 00:10:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjV5i-0006Nz-6l; Tue, 06 Dec 2005 00:10:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjV5g-0006Nk-Gn for ips@megatron.ietf.org; Tue, 06 Dec 2005 00:10:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04385 for ; Tue, 6 Dec 2005 00:09:22 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjVR6-0001ld-Io for ips@ietf.org; Tue, 06 Dec 2005 00:32:21 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id CA88E871E7; Tue, 6 Dec 2005 00:09:53 -0500 (EST) In-Reply-To: <002701c5f963$6fab6830$640115ac@elipsan.com> References: <002701c5f963$6fab6830$640115ac@elipsan.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <5fb5ff1ddb85b433a813dc5376254a4c@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Question regarding SessionType Date: Mon, 5 Dec 2005 21:09:41 -0800 To: "Ken Sandars" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 'Julian Satran' , Sears_Bill@emc.com, ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1516378199==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1516378199== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-919758468" Content-Transfer-Encoding: 7bit --Apple-Mail-1-919758468 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 4, 2005, at 10:15 PM, Ken Sandars wrote: > Hi Julo, > > I think there is merit in having a recommendation in the implementor > guide > that if the SessionType key is going to be set to "Discovery", it > should be > set in the initial Login request. > > Clearly this only affects named sessions since the only legal unnamed > session requires SessionType=Discovery in the initial Login request. > > Say an initiator wants to create a named discovery session but doesn't > supply SessionType in the initial Login request. The target will > assume the > SessionType is Normal (as it is the default value), and negotiate > accordingly. Some consequences of this are: Ken, a solution to this issue is that it is legitimate for the target to reject SessionType=Discovery. Thus if you get a SessionType=Discovery after the initial PDU, just reject it. Section 12.21 states this explicitly. Take care, Bill --Apple-Mail-1-919758468 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDlR0cDJT2Egh26K0RAuKKAJ9HjzSosSSIEsFUpPV/Q/9UXqgiuACbBjyn DVwUKaRU30kVggRbyceO5Jw= =zCL6 -----END PGP SIGNATURE----- --Apple-Mail-1-919758468-- --===============1516378199== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1516378199==-- From ips-bounces@ietf.org Tue Dec 06 00:13:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjV9J-00070v-GO; Tue, 06 Dec 2005 00:13:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjV9I-00070q-6t for ips@megatron.ietf.org; Tue, 06 Dec 2005 00:13:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04930 for ; Tue, 6 Dec 2005 00:13:05 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjVUh-0001t0-Q1 for ips@ietf.org; Tue, 06 Dec 2005 00:36:05 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id B7B30871C2; Tue, 6 Dec 2005 00:13:52 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <7a9ec49c2df97b205de0dddf8f4325de@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Fast multi-task abort model Date: Mon, 5 Dec 2005 21:13:45 -0800 To: Julian Satran X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1551932796==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1551932796== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-920002476" Content-Transfer-Encoding: 7bit --Apple-Mail-3-920002476 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 2, 2005, at 11:17 AM, Julian Satran wrote: > Regrdless of the TMF completion - discarding old TTT tagged data > buffers is problems third party target sessions will face unless they > know for sure that none can be expected in a safe way. Agreed. And unless the new abort model is used, I agree that each session will have to wait for all the TTTs on it to drain before it can, in the TAS=0 case, start accepting commands again. I _think_ we all agree on what each session must do once a reset happens. I think the only disagreement is how far along the actions on third-party sessions must be before the TMF can complete. I'm going to reply to David's EMail and see if I can explain the core of my concern. Then maybe folks can explain how I'm wrong. ;-) Take care, Bill --Apple-Mail-3-920002476 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDlR4QDJT2Egh26K0RAoJQAJ41AlaXfEgwH0BtEt+gYPjPXZ+oBACdFNOB 3KeHjsZu0JA++pZnvlezHe4= =LIOs -----END PGP SIGNATURE----- --Apple-Mail-3-920002476-- --===============1551932796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1551932796==-- From ips-bounces@ietf.org Tue Dec 06 00:14:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjV9p-00075d-1l; Tue, 06 Dec 2005 00:14:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjV9m-00075Y-UO for ips@megatron.ietf.org; Tue, 06 Dec 2005 00:14:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05077 for ; Tue, 6 Dec 2005 00:13:36 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjVVD-0001ty-Th for ips@ietf.org; Tue, 06 Dec 2005 00:36:36 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 595B4871C2; Tue, 6 Dec 2005 00:14:25 -0500 (EST) In-Reply-To: <20051202000102.59881.qmail@web51904.mail.yahoo.com> References: <20051202000102.59881.qmail@web51904.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <407f2c1f2c64758af6263dbac1fe84ff@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Fast multi-task abort model Date: Mon, 5 Dec 2005 21:14:24 -0800 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2060645600==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============2060645600== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4-920042183" Content-Transfer-Encoding: 7bit --Apple-Mail-4-920042183 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 1, 2005, at 4:01 PM, Mallikarjun C. wrote: >> Why does it need to be cross-nexus, other than the >> fact that RFC 3720 >> says it should be? > > There's a good rationale behind RFC 3720 text: > > TMF cannot complete until all affected tasks are > terminated on the target per SAM. Receiving stale > data after tasks are terminated is a problem. Waiting > for all active TTTs of all affected tasks (same and/or > other nexus) to finish was thus the adopted approach > to avoid stale data for any affected task. Shouldn't we leave how the target avoids/copes with stale data to the target? I guess I don't see how receiving "stale" data after a task has been terminated is a problem. Specifically I don't see how it's a problem to receive data you knew was in-flight at the moment the termination happened. You have your tcb structure (however you have it laid out), and you know what TTs are associated with it. Mark the tcb as terminated, then wait for the TTs to complete. When they are done, throw the whole thing out. > What the new proposal does is to make receiving stale > data after task terminations a non-problem - via a > separate accounting scheme and new target semantics. And I think this is a good thing. However I still think we need to abandon the inter-nexus TT wait for the old scheme. Take care, Bill --Apple-Mail-4-920042183 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDlR4wDJT2Egh26K0RAv9gAJ4+PVexDg60LkGTL7+9DGaIFXYlWQCfeJIQ 1Caqom0Phoh3gTxptcTR6XY= =0SBF -----END PGP SIGNATURE----- --Apple-Mail-4-920042183-- --===============2060645600== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2060645600==-- From ips-bounces@ietf.org Tue Dec 06 00:17:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjVCP-0007TS-IT; Tue, 06 Dec 2005 00:17:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjVCN-0007TL-Lp for ips@megatron.ietf.org; Tue, 06 Dec 2005 00:17:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05490 for ; Tue, 6 Dec 2005 00:16:17 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjVXo-00020o-Np for ips@ietf.org; Tue, 06 Dec 2005 00:39:17 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 0C8B7871C2; Tue, 6 Dec 2005 00:17:06 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <4232a940d3bceeacd539c79e710b7d11@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Fast multi-task abort model Date: Mon, 5 Dec 2005 21:16:30 -0800 To: Black_David@emc.com X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0255490639==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0255490639== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-920168046" Content-Transfer-Encoding: 7bit --Apple-Mail-5-920168046 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 3, 2005, at 11:06 AM, Black_David@emc.com wrote: >>> I would let David comment on the RFC revision part - >>> but given all the other things we have been collecting >>> in the iSCSI implementer's guide and given the guide >>> will be published as an RFC that "updates" RFC 3720, I >>> think it should be OK to include the new behavior in >>> the guide. >> >> Just to be clear, I like both the new abort proposal (AsyncEvent 5) >> and >> also removing all long-wait inter-nexus delays. Obviously the >> abort/reset will have to have started on all nodes before the TMF is >> returned. :-) > > Yes, as long as this is fully backwards compatible (which will > be achieved via negotiation of the next text key on login), it's > fine to include in the implementer's guide. My main concern is that there is a DoS issue lurking in the old method we have in RFC 3720. I think there is a change we can make, to remove inter-nexus delays waiting on the _completion_ of abort handling, that will not really be visible to the initiators yet will remove the DoS. Here's my thought process: I'm assuming that whatever we do with Clear Task Set/LU Reset/Target Warm Reset to clear tasks is the exact same thing we will do to tasks in face of a Persistent Reserve Out Preempt and Abort operation. So here's the scenario. We have a SAN with a primary initiator and a failover initiator for a specific application/service. To ensure exclusive access to the target, the primary initiator is using some form of reservation to keep others out of the LU(s), either RESERVE/RELEASE or PERSISTENT RESERVE OUT/IN. Now say the primary server fails and thus the failover initiator has to take over. One of the first things it has to do is get the reservation. And it will also want to clean up any half-completed tasks. If we have a RESERVE/RELEASE reservation, the failover initiator has to issue a TMF Target Warm Reset to clear the reservation. Note: the Windows HQL logo program for iSCSI requires this, so this reservation system isn't dead. :-) If we had a PERSISTENT RESERVE reservation, I believe we will want a PREEMPT AND ABORT service action. Either way, we will end up aborting all the old tasks. And we have the recover/failover initiator triggering a third-party cleanup on the session to the failed initiator. With the inter-nexus delay, the recovery initiator can't pick up for the failed initiator until the failed initiator completes its outstanding TTTs. The failed initiator, by definition, won't be cleaning up its TTTs. Thus nothing ever happens, thus a Denial of Service. So how in the world is this supposed to work? Am I missing something? I'd love it if someone could point it out! I understand that there are other ways you can make a cluster. However I think the two cases described above are things that we should support. But there's no way that can happen with what we have now. Given the above, I see no way that we can make the inter-nexus delay in RFC 3720 work as-is. Thus I believe we should unilaterally change it. I think it is sufficient to change it so that the TMF only has to wait for termination processing to have _started_ on other sessions. In the example above, if the recovery/failover initiator only had to wait for the failed initiator's TTTs to be marked to-die, then the TMF Target Warm Reset or the Persistent Reserve Out Preempt and Abort service action will proceed quickly, the tasks will be dead, and the failover can proceed. Also, while this is a notable change for targets, I do not believe that initiators will really notice. Can anyone else see a way that they will? Well, that it could cause hardship? > Taking off my WG Chair hat, I think the new abort proposal (AsyncEvent > 5) > is a good idea, but I'm going to be looking to Mallikarjun, Bill, > Julian, > and others on the list to work through all the details. I think it's a good idea too, and agree we need to look at details. Take care, Bill --Apple-Mail-5-920168046 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDlR7RDJT2Egh26K0RAg+/AJwMzOkphRtfkSb2oc/OB/1got1itQCghSIv fQhYnZHwwv1E2qddEnfZhHg= =5QL1 -----END PGP SIGNATURE----- --Apple-Mail-5-920168046-- --===============0255490639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0255490639==-- From ips-bounces@ietf.org Tue Dec 06 07:58:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjcOu-0003xL-H6; Tue, 06 Dec 2005 07:58:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjcOr-0003wU-9t for ips@megatron.ietf.org; Tue, 06 Dec 2005 07:58:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24014 for ; Tue, 6 Dec 2005 07:57:37 -0500 (EST) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjckK-0000Zs-FT for ips@ietf.org; Tue, 06 Dec 2005 08:20:42 -0500 Received: from [10.25.10.58] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1EjcLJ-0005X2-00; Tue, 06 Dec 2005 12:54:50 +0000 From: "Ken Sandars" To: "'William Studenmund'" Subject: RE: [Ips] Question regarding SessionType Date: Tue, 6 Dec 2005 23:57:11 +1100 Message-ID: <007d01c5fa64$abb11530$640115ac@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <5fb5ff1ddb85b433a813dc5376254a4c@wasabisystems.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: 'Julian Satran' , Sears_Bill@emc.com, ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Bill, Thanks for pointing that out - a handy escape hatch! Cheers Ken > -----Original Message----- > From: William Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: 06 December 2005 16:10 > To: Ken Sandars > Cc: 'Julian Satran'; Sears_Bill@emc.com; ips@ietf.org > Subject: Re: [Ips] Question regarding SessionType > > > On Dec 4, 2005, at 10:15 PM, Ken Sandars wrote: > > > Hi Julo, > > > > I think there is merit in having a recommendation in the > implementor > > guide > > that if the SessionType key is going to be set to "Discovery", it > > should be > > set in the initial Login request. > > > > Clearly this only affects named sessions since the only > legal unnamed > > session requires SessionType=Discovery in the initial Login request. > > > > Say an initiator wants to create a named discovery session > but doesn't > > supply SessionType in the initial Login request. The target will > > assume the > > SessionType is Normal (as it is the default value), and negotiate > > accordingly. Some consequences of this are: > > Ken, a solution to this issue is that it is legitimate for the target > to reject SessionType=Discovery. Thus if you get a > SessionType=Discovery after the initial PDU, just reject it. Section > 12.21 states this explicitly. > > Take care, > > Bill > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Dec 06 08:14:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejceb-0002BF-M6; Tue, 06 Dec 2005 08:14:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjceZ-0002Aa-KW for ips@megatron.ietf.org; Tue, 06 Dec 2005 08:14:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26858 for ; Tue, 6 Dec 2005 08:13:52 -0500 (EST) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejd03-0001Ll-T8 for ips@ietf.org; Tue, 06 Dec 2005 08:36:56 -0500 Received: from [10.25.10.58] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1EjcbI-0002JH-00; Tue, 06 Dec 2005 13:11:20 +0000 From: "Ken Sandars" To: "'William Studenmund'" , Subject: RE: [Ips] Fast multi-task abort model Date: Wed, 7 Dec 2005 00:13:48 +1100 Message-ID: <007e01c5fa66$fc12b5e0$640115ac@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4232a940d3bceeacd539c79e710b7d11@wasabisystems.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Bill, I'm thinking a sequence reception timeout for the outstanding TTT's will come into effect for your scenario. However, there's always the fun of determining how long that timeout needs to be... Also, the target might use Nop-In ping PDUs to detect path loss - dead initiators send no responses. This would lead to connection transport failure, another timeout and then more clearing effects. Again, how quickly this happens with respect to boiling HCT test scenarios is another matter. HTH, Ken > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of William Studenmund > Sent: 06 December 2005 16:17 > To: Black_David@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] Fast multi-task abort model > > > On Dec 3, 2005, at 11:06 AM, Black_David@emc.com wrote: > > >>> I would let David comment on the RFC revision part - > >>> but given all the other things we have been collecting > >>> in the iSCSI implementer's guide and given the guide > >>> will be published as an RFC that "updates" RFC 3720, I > >>> think it should be OK to include the new behavior in > >>> the guide. > >> > >> Just to be clear, I like both the new abort proposal > (AsyncEvent 5) > >> and > >> also removing all long-wait inter-nexus delays. Obviously the > >> abort/reset will have to have started on all nodes before > the TMF is > >> returned. :-) > > > > Yes, as long as this is fully backwards compatible (which will > > be achieved via negotiation of the next text key on login), it's > > fine to include in the implementer's guide. > > My main concern is that there is a DoS issue lurking in the > old method > we have in RFC 3720. I think there is a change we can make, to remove > inter-nexus delays waiting on the _completion_ of abort > handling, that > will not really be visible to the initiators yet will remove the DoS. > > Here's my thought process: > > I'm assuming that whatever we do with Clear Task Set/LU Reset/Target > Warm Reset to clear tasks is the exact same thing we will do to tasks > in face of a Persistent Reserve Out Preempt and Abort operation. > > So here's the scenario. We have a SAN with a primary initiator and a > failover initiator for a specific application/service. To ensure > exclusive access to the target, the primary initiator is using some > form of reservation to keep others out of the LU(s), either > RESERVE/RELEASE or PERSISTENT RESERVE OUT/IN. > > Now say the primary server fails and thus the failover > initiator has to > take over. > > One of the first things it has to do is get the reservation. And it > will also want to clean up any half-completed tasks. > > If we have a RESERVE/RELEASE reservation, the failover > initiator has to > issue a TMF Target Warm Reset to clear the reservation. Note: the > Windows HQL logo program for iSCSI requires this, so this reservation > system isn't dead. :-) > > If we had a PERSISTENT RESERVE reservation, I believe we will want a > PREEMPT AND ABORT service action. > > Either way, we will end up aborting all the old tasks. And we > have the > recover/failover initiator triggering a third-party cleanup on the > session to the failed initiator. > > With the inter-nexus delay, the recovery initiator can't pick up for > the failed initiator until the failed initiator completes its > outstanding TTTs. > > The failed initiator, by definition, won't be cleaning up its TTTs. > Thus nothing ever happens, thus a Denial of Service. > > So how in the world is this supposed to work? > > Am I missing something? I'd love it if someone could point it out! > > I understand that there are other ways you can make a > cluster. However > I think the two cases described above are things that we should > support. But there's no way that can happen with what we have now. > > > Given the above, I see no way that we can make the > inter-nexus delay in > RFC 3720 work as-is. > > Thus I believe we should unilaterally change it. I think it is > sufficient to change it so that the TMF only has to wait for > termination processing to have _started_ on other sessions. In the > example above, if the recovery/failover initiator only had to > wait for > the failed initiator's TTTs to be marked to-die, then the TMF Target > Warm Reset or the Persistent Reserve Out Preempt and Abort service > action will proceed quickly, the tasks will be dead, and the failover > can proceed. > > Also, while this is a notable change for targets, I do not > believe that > initiators will really notice. Can anyone else see a way that they > will? Well, that it could cause hardship? > > > Taking off my WG Chair hat, I think the new abort proposal > (AsyncEvent > > 5) > > is a good idea, but I'm going to be looking to Mallikarjun, Bill, > > Julian, > > and others on the list to work through all the details. > > I think it's a good idea too, and agree we need to look at details. > > Take care, > > Bill > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Dec 06 14:50:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjipB-0007Fa-Sd; Tue, 06 Dec 2005 14:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjipA-0007E5-M1 for ips@megatron.ietf.org; Tue, 06 Dec 2005 14:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14163 for ; Tue, 6 Dec 2005 14:49:13 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjjAg-00078k-EM for ips@ietf.org; Tue, 06 Dec 2005 15:12:21 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id F0342871E9; Tue, 6 Dec 2005 14:49:45 -0500 (EST) In-Reply-To: <78C934D0E1A588449B46F68346FB76C7156EC0@wcosmb08.cos.agilent.com> References: <78C934D0E1A588449B46F68346FB76C7156EC0@wcosmb08.cos.agilent.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: William Studenmund Subject: Re: [Ips] Question regarding SessionType Date: Tue, 6 Dec 2005 11:49:32 -0800 To: X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: julian.satran@gmail.com, ips@ietf.org, Sears_Bill@emc.com, ken_sandars@adaptec.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563896083==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0563896083== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-972549507" Content-Transfer-Encoding: 7bit --Apple-Mail-1-972549507 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 6, 2005, at 11:36 AM, wrote: > It is good that there is an escape. However, that means that offering > the key late might cause it to get rejected by a target that would > have accepted it when offered early. This is a good reason to suggest > in the implementer guide that the key "SHOULD" be set in the initial > Login request if Discovery is going to be offered. Enthusiastically agreed. Take care, Bill --Apple-Mail-1-972549507 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDletTDJT2Egh26K0RAjTCAKCbX2OVDdqFgoAPi2VbA4SS119FugCeNJUv SJUQJFVBVGhl8M87FFeFNSg= =pwSo -----END PGP SIGNATURE----- --Apple-Mail-1-972549507-- --===============0563896083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0563896083==-- From ips-bounces@ietf.org Tue Dec 06 15:17:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjjFK-0001Yf-3B; Tue, 06 Dec 2005 15:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjjFI-0001YZ-14 for ips@megatron.ietf.org; Tue, 06 Dec 2005 15:17:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17059 for ; Tue, 6 Dec 2005 15:16:11 -0500 (EST) From: pat.thaler@avagotech.com Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejjap-00084C-K8 for ips@ietf.org; Tue, 06 Dec 2005 15:39:20 -0500 Received-SPF: none (msgbas1x.cos.agilent.com: domain of pat.thaler@avagotech.com does not designate permitted sender hosts) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 323A627563 for ; Tue, 6 Dec 2005 13:16:53 -0700 (MST) Received: from wcosvs03.cos.agilent.com (wcosvs03.cos.agilent.com [130.29.152.233]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 10209557 for ; Tue, 6 Dec 2005 13:16:53 -0700 (MST) Received: from wcosbh03.cos.agilent.com ([130.29.152.128]) by wcosvs03.cos.agilent.com with InterScan Messaging Security Suite; Tue, 06 Dec 2005 13:16:52 -0700 Received: from wcosmb08.cos.agilent.com ([130.29.152.129]) by wcosbh03.cos.agilent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Dec 2005 13:16:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: address change; was: [Ips] Question regarding SessionType Date: Tue, 6 Dec 2005 13:16:50 -0700 Message-ID: <78C934D0E1A588449B46F68346FB76C7156EEA@wcosmb08.cos.agilent.com> Thread-Topic: address change; was: [Ips] Question regarding SessionType Thread-Index: AcX6njuTRA4AO5yhTu2ZBqo4BYFqlgAAr4bA To: , X-OriginalArrivalTime: 06 Dec 2005 20:16:51.0657 (UTC) FILETIME=[FE827B90:01C5FAA1] X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: julian.satran@gmail.com, ips@ietf.org, Sears_Bill@emc.com, ken_sandars@adaptec.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bill, Thanks for forwarding my email to the reflector. The original bounced = due to my address change.=20 For those who aren't aware, Agilent Technologies sold their = Semiconductor Products Group to investors. It is now Avago Technologies. = You don't need to rush to update your address books. It has been = announced that my division will be sold to PMC-Sierra shortly. My phone = numbers SHOULD be unaffected by the transitions. My Agilent email = address SHOULD forward to me until the PMC-Sierra transition. Regards, Pat -----Original Message----- From: William Studenmund [mailto:wrstuden@wasabisystems.com]=20 Sent: Tuesday, December 06, 2005 11:50 AM To: pat.thaler@avagotech.com Cc: ips@ietf.org; ken_sandars@adaptec.com; julian.satran@gmail.com; = Sears_Bill@emc.com Subject: Re: [Ips] Question regarding SessionType On Dec 6, 2005, at 11:36 AM, wrote: > It is good that there is an escape. However, that means that offering=20 > the key late might cause it to get rejected by a target that would=20 > have accepted it when offered early. This is a good reason to suggest=20 > in the implementer guide that the key "SHOULD" be set in the initial=20 > Login request if Discovery is going to be offered. Enthusiastically agreed. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Dec 06 15:34:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjjWL-0000QV-No; Tue, 06 Dec 2005 15:34:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejel8-0000Y4-Cu for ips@megatron.ietf.org; Tue, 06 Dec 2005 10:29:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13289 for ; Tue, 6 Dec 2005 10:28:46 -0500 (EST) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejf6d-00067N-IZ for ips@ietf.org; Tue, 06 Dec 2005 10:51:53 -0500 Received: from 10.10.64.121 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 06 Dec 2005 07:29:09 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com for ; Tue, 6 Dec 2005 07:29:08 -0800 Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CHN46252; Tue, 6 Dec 2005 07:29:01 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 1DE4E20501 for ; Tue, 6 Dec 2005 07:29:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Dec 2005 07:29:00 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F10C29DA@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: draft-ietf-rddp-rdmap Thread-Index: AcX6ZR0B7PDkgYO/Roee79VB2HjIkAAE5Vsw From: "Caitlin Bestler" To: ips@ietf.org X-WSS-ID: 6F8B71CF48G9074130-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 06 Dec 2005 15:34:41 -0500 Subject: [Ips] RE: draft-ietf-rddp-rdmap X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > Date: Mon, 5 Dec 2005 16:01:07 -0500 > From: "Sanjay Goyal" > Subject: [Ips] Qs: draft-ietf-rddp-rdmap-05 > To: > Message-ID: <0F31272A2BCBBE4FA01344C6E69DBF5029600A@thoth.ivivity.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi, > As per draft-ietf-rddp-rdmap-05.txt, >=20 > page 50, Item14: > "A Send or RDMA Write Message MUST NOT be considered Complete >=20 > at the Local Peer (Data Source) until it has been successfully >=20 > completed at the DDP layer." >=20 > Q1. What does "successfully completed at the DDP layer" mean? > Is it referring to TCP ack? >=20 >=20 It means that the DDP layer has informed the RDMAP layer that it no longer requires the original source buffers, this is typically because the LLP has so informed it. This could because the LLP has received an ACK of that output, or merely that it has its packets formulated and buffered and no longer needs the original buffers. It is important to note that completion of a Send or Write does NOT mean that the Data Sink has received the data. >=20 > Also Section 8.2.1 item 1 mentions: >=20 > "An RNIC MUST ensure that a specific Stream in a specific > Protection Domain cannot access an STag in a different > Protection Domain." >=20 > Q2. What does Protection Domain mean? >=20 > A Protection Domain encloses a set of RDMA Endpoints ("QP") and STags that can be used on those endpoints. It is an arbitrary scoping mechanism, typically matching a user process but sometimes narrower. For example iSER could scope a Protection Domain to match an iSCSI session. However a Protection Domain is used by the ULP, it prevents STags from being used on the wrong connection, especially somebody else's connection. So basically, other than the enforcement it provides, a Protection Domain has very little meaning at the DDP layer. It's real meaning and purpose is determined by the ULP that decides what Protection Domains to create, and why. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Dec 06 15:34:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjjWM-0000Qz-4I; Tue, 06 Dec 2005 15:34:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjicH-0001SR-Br for ips@megatron.ietf.org; Tue, 06 Dec 2005 14:36:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12624 for ; Tue, 6 Dec 2005 14:35:53 -0500 (EST) From: pat.thaler@avagotech.com Received: from msgbas2x.cos.agilent.com ([192.25.240.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejixp-0006dP-My for ips@ietf.org; Tue, 06 Dec 2005 14:59:02 -0500 Received-SPF: none (msgbas2x.cos.agilent.com: domain of pat.thaler@avagotech.com does not designate permitted sender hosts) Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id E42CF6C18 for ; Tue, 6 Dec 2005 12:36:28 -0700 (MST) Received: from wcosvs02.cos.agilent.com (wcosvs02.cos.agilent.com [130.29.152.188]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 853A48F3 for ; Tue, 6 Dec 2005 12:36:28 -0700 (MST) Received: from wcosbh02.cos.agilent.com ([130.29.152.126]) by wcosvs02.cos.agilent.com with InterScan Messaging Security Suite; Tue, 06 Dec 2005 12:36:25 -0700 Received: from wcosmb08.cos.agilent.com ([130.29.152.129]) by wcosbh02.cos.agilent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Dec 2005 12:36:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Question regarding SessionType Date: Tue, 6 Dec 2005 12:36:24 -0700 Message-ID: <78C934D0E1A588449B46F68346FB76C7156EC0@wcosmb08.cos.agilent.com> Thread-Topic: [Ips] Question regarding SessionType Thread-Index: AcX6ZQV4S8Sn2U0tTxCqX33he85MFAANoSUQ To: , X-OriginalArrivalTime: 06 Dec 2005 19:36:25.0719 (UTC) FILETIME=[5889B870:01C5FA9C] X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 06 Dec 2005 15:34:41 -0500 Cc: julian.satran@gmail.com, Sears_Bill@emc.com, ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org It is good that there is an escape. However, that means that offering = the key late might cause it to get rejected by a target that would have = accepted it when offered early. This is a good reason to suggest in the = implementer guide that the key "SHOULD" be set in the initial Login = request if Discovery is going to be offered. Regards, Pat -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = Ken Sandars Sent: Tuesday, December 06, 2005 4:57 AM To: 'William Studenmund' Cc: 'Julian Satran'; Sears_Bill@emc.com; ips@ietf.org Subject: RE: [Ips] Question regarding SessionType Hi Bill, Thanks for pointing that out - a handy escape hatch! Cheers Ken > -----Original Message----- > From: William Studenmund [mailto:wrstuden@wasabisystems.com]=20 > Sent: 06 December 2005 16:10 > To: Ken Sandars > Cc: 'Julian Satran'; Sears_Bill@emc.com; ips@ietf.org > Subject: Re: [Ips] Question regarding SessionType >=20 >=20 > On Dec 4, 2005, at 10:15 PM, Ken Sandars wrote: >=20 > > Hi Julo, > > > > I think there is merit in having a recommendation in the=20 > implementor=20 > > guide > > that if the SessionType key is going to be set to "Discovery", it=20 > > should be > > set in the initial Login request. > > > > Clearly this only affects named sessions since the only=20 > legal unnamed > > session requires SessionType=3DDiscovery in the initial Login = request. > > > > Say an initiator wants to create a named discovery session=20 > but doesn't > > supply SessionType in the initial Login request. The target will=20 > > assume the > > SessionType is Normal (as it is the default value), and negotiate > > accordingly. Some consequences of this are: >=20 > Ken, a solution to this issue is that it is legitimate for the target=20 > to reject SessionType=3DDiscovery. Thus if you get a=20 > SessionType=3DDiscovery after the initial PDU, just reject it. Section = > 12.21 states this explicitly. >=20 > Take care, >=20 > Bill >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Dec 06 17:26:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlGz-00057Y-V1; Tue, 06 Dec 2005 17:26:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlGw-00053J-QF for ips@megatron.ietf.org; Tue, 06 Dec 2005 17:26:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00163 for ; Tue, 6 Dec 2005 17:26:04 -0500 (EST) Received: from web51906.mail.yahoo.com ([206.190.48.69]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjlcT-0003vO-To for ips@ietf.org; Tue, 06 Dec 2005 17:49:12 -0500 Received: (qmail 53507 invoked by uid 60001); 6 Dec 2005 22:26:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FDQDXZAXNgUVJ/7swFZ23WQT/GAVoWwqbuV8Boamo6LVfoeDhgTuazG7g0tQCC4z56VxsKGCEFFHyyzurPGHf1RmBLw/jVsNCJYeBgZThAmA6mFI7Nm3VChgjr23FGVF1591VREFZUbBxBxx6z2odHnCLIJd9+Sv2a4d/nUnqa8= ; Message-ID: <20051206222640.53505.qmail@web51906.mail.yahoo.com> Received: from [156.153.255.243] by web51906.mail.yahoo.com via HTTP; Tue, 06 Dec 2005 14:26:40 PST Date: Tue, 6 Dec 2005 14:26:40 -0800 (PST) From: "Mallikarjun C." Subject: RE: [Ips] Question regarding SessionType To: ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA00163 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Agreed, the SHOULD is now added to section 5. Thanks. Mallikarjun --- Black_David@emc.com wrote: > I think a "SHOULD" in the Implementer's Guide for > the suggestion Ken > makes is fine: > =20 > if the SessionType key is going to be set to > "Discovery", it SHOULD > be set in the initial Login request > =20 > Declaring one's intentions up front seems like a > good idea in general. > =20 > Thanks, > --David > ---------------------------------------------------- >=20 > David L. Black, Senior Technologist=20 > EMC Corporation, 176 South St., Hopkinton, MA 01748 >=20 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 >=20 > black_david@emc.com Mobile: +1 (978) 394-7754 >=20 > ---------------------------------------------------- >=20 >=20 >=20 > _____ =20 >=20 > From: ips-bounces@ietf.org > [mailto:ips-bounces@ietf.org] On Behalf Of Julian > Satran > Sent: Monday, December 05, 2005 7:08 AM > To: Ken Sandars > Cc: ips@ietf.org; Sears, Bill > Subject: RE: [Ips] Question regarding SessionType >=20 >=20 >=20 > Ken,=20 >=20 > Even if we put is a good practice in the > implementer's guide it would merely > help in avoiding some nasty bugs in the initiator > and/or target. And we > can't mandate it in the implementoer's guide.=20 >=20 > The supporting code for all the exceptions you > mention has to be there and > not only because of the session type placement but > because the normal > session type has to be supported. All of your > arguments would make sense > only if you envision an implementation that supports > the two session types > with separate pieces of code or even boxes.=20 >=20 > Julo=20 >=20 >=20 >=20 > "Ken Sandars" =20 > Sent by: ips-bounces@ietf.org=20 >=20 >=20 > 05-12-05 08:15=20 >=20 >=20 > To > "'Julian Satran'" , > =20 >=20 > cc > ips@ietf.org=20 >=20 > Subject > RE: [Ips] Question regarding SessionType >=20 > =09 >=20 >=20 >=20 >=20 > Hi Julo, >=20 > I think there is merit in having a recommendation in > the implementor guide > that if the SessionType key is going to be set to > "Discovery", it should be > set in the initial Login request. >=20 > Clearly this only affects named sessions since the > only legal unnamed > session requires SessionType=3DDiscovery in the > initial Login request. >=20 > Say an initiator wants to create a named discovery > session but doesn't > supply SessionType in the initial Login request. The > target will assume the > SessionType is Normal (as it is the default value), > and negotiate > accordingly. Some consequences of this are: >=20 > 1. The initiator will have to be prepared to > negotiate Normal session > parameters which the target may offer - such as > MaxConnections, > MaxBurstLength, etc. >=20 > 2. If a target is configured to operate without > security for Discovery > sessions but with it for Normal sessions, the > initiator cannot successfully > bypass the security phase. >=20 > 3. The target might make different resource > allocation decisions dependant > on the type of session. A Discovery session has much > less scope for > consuming system resources than a Normal session. > The target implementation > may reject the login due to resource constraints > when in fact there are none > for this session. >=20 > 4. Some keys must be negotiated with knowledge of > the SessionType. For > example, in the implementor's guide, section 5.1 - > the ErrorRecoveryLevel > value MUST be negotiated to 0 for Discovery > sessions. > MaxRecvDataSegmentLength might be declared > differently for different session > types so the target has to hold off with its > declaration until either the > final Login request or SessionType is explicitly > declared. >=20 > While none of these consequences are show-stoppers, > they do add complexity > which would be nice to avoid. To recommend this in > the implementor guide > should have very little impact as I don't think the > named-discovery session > is in common use (at all?). >=20 >=20 > Thanks, > Ken Sandars >=20 > > -----Original Message----- > > From: ips-bounces@ietf.org > [mailto:ips-bounces@ietf.org] On=20 > > Behalf Of Julian Satran > > Sent: 30 November 2005 01:53 > > To: Sears_Bill@emc.com > > Cc: ips@ietf.org > > Subject: Re: [Ips] Question regarding SessionType > >=20 > >=20 > > Bill, > >=20 > > Unfortunately the text of RFC3720 does not agree > with your=20 > > assumptions. > > The session type can be specified at any stage as > explicitly=20 > > stated in=20 > > chapters 11 and 12. > > I can't think of a good reason we should limit its > use (or even=20 > > recommend it as good practice in the implementor > guide). > >=20 > > Julo > >=20 > > Sears_Bill@emc.com wrote: > > > > > > =20 > > > > > > rfc3720 section 5.3 states: > > > > > > The initial login request of the first > connection of a session MAY=20 > > > also include the SessionType key=3Dvalue pair. > > > > > > The use of the word 'MAY' here is bothersome. =20 > Does this=20 > > mean that an=20 > > > initiator may leave out the session type in the > first=20 > > request but then=20 > > > explicitly specify it later? This seems > possible but very=20 > > annoying. =20 > > > For example: > > > > > > During Security stage it seems that an initiator > could leave out=20 > > > SessionType but specify a > TargetName=3D. Later during=20 >=20 =3D=3D=3D message truncated =3D=3D=3D> _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 =09 __________________________________________=20 Yahoo! DSL =96 Something to write home about.=20 Just $16.99/mo. or less.=20 dsl.yahoo.com=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Dec 06 18:13:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejlzh-0001Ie-Gc; Tue, 06 Dec 2005 18:13:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejlzg-0001I4-1F for ips@megatron.ietf.org; Tue, 06 Dec 2005 18:13:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05102 for ; Tue, 6 Dec 2005 18:12:17 -0500 (EST) Received: from web51915.mail.yahoo.com ([206.190.48.78]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjmLG-0005ZD-5v for ips@ietf.org; Tue, 06 Dec 2005 18:35:26 -0500 Received: (qmail 16015 invoked by uid 60001); 6 Dec 2005 23:12:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SdVO8ywO2YHUZ807vWuGjCnoIt51Fzz5+qiBoB/XqPxoo/8thOIHvlnYzTha2jWfNC8jTmPBPHpAQKb9f906Un1x0xUows+FDSeqOz6A49gSWqrU9uhi3ffJ+LC/NAHBQtaVurZTGd7kvl0uw0YLsO6k//VVGjnwHP0fUQL0YUk= ; Message-ID: <20051206231258.16013.qmail@web51915.mail.yahoo.com> Received: from [156.153.255.243] by web51915.mail.yahoo.com via HTTP; Tue, 06 Dec 2005 15:12:58 PST Date: Tue, 6 Dec 2005 15:12:58 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Fast multi-task abort model To: IPS In-Reply-To: <407f2c1f2c64758af6263dbac1fe84ff@wasabisystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA05102 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >Mark > the tcb as=20 > terminated, then wait for the TTs to complete. When > they are done,=20 > throw the whole thing out. Reasonable, and this is in abstract what the new proposal does. RFC 3720 does not explicitly say "wait for TTTs to complete even after TMF is completed". The only default interpretation of the 3720 text today would be to invalidate the TTTs along with the buffer associations when a task is "terminated" and the TMF completion is generated. An invalid TTT/STag is in fact a problem for at least two reasons -=20 a) All Data-Out PDU (with the now invalid TTTs) are protocol errors that should be Reject'ed. b) Any DDP tagged data segment to an invalid STag immediately takes the connection down (for iSCSI/iSER). What I am suggesting in the new proposal is that there be an explicit event to conclude the "waiting for TTTs to complete" for a target at the iSCSI control protocol level (not at the Datamover level). That new event is the reception of the Nop-Out ack'ing the new Async PDU. And that brings us to the new proposal. I think the 3720 text is self-consistent (although it isn't the most efficient). Simply scratching the TTT cross-nexus requirement off the current text, IMHO, is not the right thing. We need to specify the new initiator and target semantics in the absence of that requirement, and that's what the fast multi-task abort proposal attempts. Mallikarjun =20 --- William Studenmund wrote: > On Dec 1, 2005, at 4:01 PM, Mallikarjun C. wrote: >=20 > >> Why does it need to be cross-nexus, other than > the > >> fact that RFC 3720 > >> says it should be? > > > > There's a good rationale behind RFC 3720 text: > > > > TMF cannot complete until all affected tasks are > > terminated on the target per SAM. Receiving stale > > data after tasks are terminated is a problem.=20 > Waiting > > for all active TTTs of all affected tasks (same > and/or > > other nexus) to finish was thus the adopted > approach > > to avoid stale data for any affected task. >=20 > Shouldn't we leave how the target avoids/copes with > stale data to the=20 > target? >=20 > I guess I don't see how receiving "stale" data after > a task has been=20 > terminated is a problem. Specifically I don't see > how it's a problem to=20 > receive data you knew was in-flight at the moment > the termination=20 > happened. You have your tcb structure (however you > have it laid out),=20 > and you know what TTs are associated with it. Mark > the tcb as=20 > terminated, then wait for the TTs to complete. When > they are done,=20 > throw the whole thing out. >=20 > > What the new proposal does is to make receiving > stale > > data after task terminations a non-problem - via a > > separate accounting scheme and new target > semantics. >=20 > And I think this is a good thing. However I still > think we need to=20 > abandon the inter-nexus TT wait for the old scheme. >=20 > Take care, >=20 > Bill >=20 >=20 =09 __________________________________________=20 Yahoo! DSL =96 Something to write home about.=20 Just $16.99/mo. or less.=20 dsl.yahoo.com=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 07 11:14:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek1vz-00088h-Rt; Wed, 07 Dec 2005 11:14:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek1vy-000889-DW for ips@megatron.ietf.org; Wed, 07 Dec 2005 11:14:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24634 for ; Wed, 7 Dec 2005 11:13:29 -0500 (EST) Received: from [64.238.111.98] (helo=thoth.ivivity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek2Hh-0005Ry-0V for ips@ietf.org; Wed, 07 Dec 2005 11:36:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Dec 2005 11:14:09 -0500 Message-ID: <0F31272A2BCBBE4FA01344C6E69DBF5029600F@thoth.ivivity.com> Thread-Topic: draft-ietf-rddp-rdmap: ddp QN 0, 1, 2 Thread-Index: AcX6ZR0B7PDkgYO/Roee79VB2HjIkAAE5VswADP8DVA= From: "Sanjay Goyal" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [Ips] draft-ietf-rddp-rdmap: ddp QN 0, 1, 2 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi, What is the advantage of using 2 separate DDP Queues, 0 for Send Messages and 1 for=20 Read Request Messages? Even if the messages are received with the same DDP QN, RDMAP layer would know from the op-code which Message it is, so from RDMAP layer perspective why did we decide to use 2 different QN. Regards, =20 Sanjay Goyal 678-990-1550 x204 iVivity Inc. Norcross, GA 30093 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 07 18:10:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek8QP-0004im-HG; Wed, 07 Dec 2005 18:10:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek8QO-0004if-4r for ips@megatron.ietf.org; Wed, 07 Dec 2005 18:10:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14705 for ; Wed, 7 Dec 2005 18:09:18 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek8mA-0004x2-OT for ips@ietf.org; Wed, 07 Dec 2005 18:32:43 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 7C9DD87141; Wed, 7 Dec 2005 18:10:01 -0500 (EST) In-Reply-To: <20051206231258.16013.qmail@web51915.mail.yahoo.com> References: <20051206231258.16013.qmail@web51915.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <7d06e1a34bf0da5ce25c145c9abcb4d8@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Fast multi-task abort model Date: Wed, 7 Dec 2005 15:09:50 -0800 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1191863227==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1191863227== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4-1070968161" Content-Transfer-Encoding: 7bit --Apple-Mail-4-1070968161 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 6, 2005, at 3:12 PM, Mallikarjun C. wrote: >> Mark >> the tcb as >> terminated, then wait for the TTs to complete. When >> they are done, >> throw the whole thing out. > > Reasonable, and this is in abstract what the new > proposal does. > > RFC 3720 does not explicitly say "wait for TTTs to > complete even after TMF is completed". The only > default interpretation of the 3720 text today would be > to invalidate the TTTs along with the buffer > associations when a task is "terminated" and the TMF > completion is generated. An invalid TTT/STag is in > fact a problem for at least two reasons - If the target breaks the buffer associations, does it really have to invalidate the TTT? We're dragging in a lot of details that feel like they are implementation specific. Our target has no trouble with the idea that a task is dead yet has active TTTs, the contents of which will never be used. We just let the TTTs drain off and clean up the task. We do this as you've done a good job of explaining to me that things are REALLY messy if we don't. :-) As long as data received "after" (in terms of some atomic state change) the termination will be discarded, does the termination act really care how how the cleanup gets done? Put another way, I think it's fine for a task to be terminated at the SCSI level yet still have things going on (being cleaned up) at the iSCSI level. As long as cleanup transfers aren't actually placed to the SCSI device, I don't see why a target can't do this. I understand that the STags won't be able to go away. But as long as the target device doesn't use the buffers the STag goes into, is there a problem? Thus if a target breaks buffer associations, we should be fine, shouldn't we? > a) All Data-Out PDU (with the now invalid TTTs) are > protocol errors that should be Reject'ed. > b) Any DDP tagged data segment to an invalid STag > immediately takes the connection down (for > iSCSI/iSER). > > What I am suggesting in the new proposal is that there > be an explicit event to conclude the "waiting for TTTs > to complete" for a target at the iSCSI control > protocol level (not at the Datamover level). That new > event is the reception of the Nop-Out ack'ing the new > Async PDU. And that brings us to the new proposal. I understand that. But that's orthogonal to what I'm very concerned about. I'm not concerned that session A waits for its TTTs, nor that session B waits for its TTTs, nor that session C waits for its TTTs, but that session D has to wait for all of them to complete a TMF. I think that session A waiting for TTTs or using the new Async PDU is fine. As for session B and session C. > I think the 3720 text is self-consistent (although it > isn't the most efficient). Simply scratching the TTT > cross-nexus requirement off the current text, IMHO, is > not the right thing. We need to specify the new > initiator and target semantics in the absence of that > requirement, and that's what the fast multi-task abort > proposal attempts. We have a denial of service window. I don't see how we can get rid of it w/o ripping out the cross-nexus TTT wait. I also don't understand why it's ok to remove the inter-nexus wait for the new technique and not for the old? The only alternatives I see are to either migrate everyone to the new Async PDU or to warn implementors and administrators that failover can take a long time on iSCSI. The latter will be a real shame. My understanding is that FibreChannel doesn't have such delays, so we'll be at a competitive disadvantage. Take care, Bill --Apple-Mail-4-1070968161 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDl2vEDJT2Egh26K0RAi+EAJ9gX+Yz7oC/DuRnsrmXb+5LaRhJhQCeJxZ7 cxk8Po5Ygwf9qewWlFguW3I= =xArv -----END PGP SIGNATURE----- --Apple-Mail-4-1070968161-- --===============1191863227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1191863227==-- From ips-bounces@ietf.org Wed Dec 07 18:22:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek8cR-0008GS-7E; Wed, 07 Dec 2005 18:22:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek8cP-0008FJ-4d for ips@megatron.ietf.org; Wed, 07 Dec 2005 18:22:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15890 for ; Wed, 7 Dec 2005 18:21:43 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek8yA-0005NL-Ve for ips@ietf.org; Wed, 07 Dec 2005 18:45:08 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 3EAE1871C7; Wed, 7 Dec 2005 18:22:34 -0500 (EST) In-Reply-To: <007e01c5fa66$fc12b5e0$640115ac@elipsan.com> References: <007e01c5fa66$fc12b5e0$640115ac@elipsan.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <4ba6524572cef6ca22ee245cc5cb0d50@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Fast multi-task abort model Date: Wed, 7 Dec 2005 15:22:27 -0800 To: "Ken Sandars" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0305828493==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0305828493== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-1071724479" Content-Transfer-Encoding: 7bit --Apple-Mail-5-1071724479 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 6, 2005, at 5:13 AM, Ken Sandars wrote: > Hi Bill, > > I'm thinking a sequence reception timeout for the outstanding TTT's > will > come into effect for your scenario. However, there's always the fun of > determining how long that timeout needs to be... > > Also, the target might use Nop-In ping PDUs to detect path loss - dead > initiators send no responses. This would lead to connection transport > failure, another timeout and then more clearing effects. Again, how > quickly > this happens with respect to boiling HCT test scenarios is another > matter. You're right, and that's why I was talking about timeouts earlier in this thread. Like a month or two ago. The problem I see with this is that we have, until now, left timeouts to the implementors. But now for this all to work, we have to pay attention to them. And, to how _other_ initiators have timeouts configured. Since to perform the abort, I have to wait for someone else's TTTs to clear. Also, as an administrator, I would really object to having to wait for the TTT timeouts. I'm _aborting_ the task, why do I have to wait for it to time out? :-) Take care, Bill --Apple-Mail-5-1071724479 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDl264DJT2Egh26K0RAivgAJ0QCL1cGEzHTLhLOWX8kqu1f2vzIgCeJ85D 6x67rs1FLeE+kqoMwJaG11w= =M8Y/ -----END PGP SIGNATURE----- --Apple-Mail-5-1071724479-- --===============0305828493== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0305828493==-- From ips-bounces@ietf.org Wed Dec 07 18:37:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek8r9-0002fp-UZ; Wed, 07 Dec 2005 18:37:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek8r9-0002fY-6h for ips@megatron.ietf.org; Wed, 07 Dec 2005 18:37:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17270 for ; Wed, 7 Dec 2005 18:36:59 -0500 (EST) Received: from webmail2.silverbacksystems.com ([65.172.158.65] helo=silverbacksystems.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek9Cr-0005pr-4o for ips@ietf.org; Wed, 07 Dec 2005 19:00:21 -0500 Received: from [10.0.16.116] (account sgupta@silverbacksystems.com) by silverbacksystems.com (CommuniGate Pro IMAP 4.3.7) with XMIT id 530992 for ips@ietf.org; Wed, 07 Dec 2005 15:37:28 -0800 Subject: [Ips] Fast multi-task abort model Date: Wed, 07 Dec 2005 15:36:35 -0800 Message-Id: <798981da4f2ab748a830f9cf10a767d2@mail2.silverbacksystems.com> MIME-Version: 1.0 Thread-Topic: [Ips] Fast multi-task abort model Priority: Normal Importance: normal X-MSMail-Priority: normal X-Priority: 3 Sensitivity: Normal Thread-Index: AcX7bvAMROhmDBJHQ0CNiBJcoKxd+QAF+JnQ From: "Somesh Gupta" To: "ips@ietf.org" X-MAPI-LastModified: Wed, 07 Dec 2005 15:36:35 -0800 X-Mailer: CommuniGate Pro MAPI Connector 1.1.21/1.1.25(local) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org (My first attempt did not seem to make it through. Apologies if people see a duplicate.) The discussion prompted me to take a closer look at the fast multi-task abort model. In principal, I agree that the new async PDU helps the target and initiator reach a common understanding of which tasks have been cleared, and stop processing them. However, I think the language of the proposal puts too much knowledge in the target transport layer - the language implies that the target transport layer is managing the task set for a LUN - it is responsible for determining which initiators have active tasks on a specific LUN, and which tasks these are, what their disposition is - and for sending a TMF response (and which TMFs are supported and what the back-end impact of each is). It is not so simple since the values of the TAS, TST and Qerr bits really determine the actions. There is some unavoidable interaction/modification of the SCSI layer to handle this situation correctly - because only the SCSI layer knows whether for the cleared tasks a. the initiator is really not expecting anything (the nexus is the same as which received the tmf command) b. should be sent an explicit status of ABORTED BY ANOTHER INITIATOR c. No impact d. Needs to be cleaned up through the asynch notification mechanism (different nexus, TST=3D0:Qerr=3D01b;TAS=3D0) c. Whether the initiator is likely to be dead (LUN Reset with reserve/release model or equivalent behavior in persistent reservation model) In other words, the asynch PDU must be explicitly triggered by the SCSI layer on each impacted Nexus - if adding the asynch PDU becomes an issues, we can use a new response code which would be sent for every command. In any case, the statsn acknowledgement rule should help the initiator and target flush all impacted commands in the pipe, and have a common understanding of what is impacted. Bill makes a very valid point about the real world situation of clusters. Shouldn't the SCSI layer be able to send a response for the TMF when it has triggered the asynch PDU on each of the Nexuses (is it Nexi?). The acknowledgement or time-out is only for the purposes of recovering the buffers? >-----Original Message----- >From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On >Behalf Of Mallikarjun C. >Sent: Tuesday, December 06, 2005 3:13 PM >To: IPS >Subject: Re: [Ips] Fast multi-task abort model > > >>Mark >> the tcb as >> terminated, then wait for the TTs to complete. When >> they are done, >> throw the whole thing out. > >Reasonable, and this is in abstract what the new >proposal does. > >RFC 3720 does not explicitly say "wait for TTTs to >complete even after TMF is completed". The only >default interpretation of the 3720 text today would be >to invalidate the TTTs along with the buffer >associations when a task is "terminated" and the TMF >completion is generated. An invalid TTT/STag is in >fact a problem for at least two reasons - > >a) All Data-Out PDU (with the now invalid TTTs) are >protocol errors that should be Reject'ed. >b) Any DDP tagged data segment to an invalid STag >immediately takes the connection down (for >iSCSI/iSER). > >What I am suggesting in the new proposal is that there >be an explicit event to conclude the "waiting for TTTs >to complete" for a target at the iSCSI control >protocol level (not at the Datamover level). That new >event is the reception of the Nop-Out ack'ing the new >Async PDU. And that brings us to the new proposal. > >I think the 3720 text is self-consistent (although it >isn't the most efficient). Simply scratching the TTT >cross-nexus requirement off the current text, IMHO, is >not the right thing. We need to specify the new >initiator and target semantics in the absence of that >requirement, and that's what the fast multi-task abort >proposal attempts. > >Mallikarjun > > > > >--- William Studenmund >wrote: > >> On Dec 1, 2005, at 4:01 PM, Mallikarjun C. wrote: >> >> >> Why does it need to be cross-nexus, other than >> the >> >> fact that RFC 3720 >> >> says it should be? >> > >> > There's a good rationale behind RFC 3720 text: >> > >> > TMF cannot complete until all affected tasks are >> > terminated on the target per SAM. Receiving stale >> > data after tasks are terminated is a problem. >> Waiting >> > for all active TTTs of all affected tasks (same >> and/or >> > other nexus) to finish was thus the adopted >> approach >> > to avoid stale data for any affected task. >> >> Shouldn't we leave how the target avoids/copes with >> stale data to the >> target? >> >> I guess I don't see how receiving "stale" data after >> a task has been >> terminated is a problem. Specifically I don't see >> how it's a problem to >> receive data you knew was in-flight at the moment >> the termination >> happened. You have your tcb structure (however you >> have it laid out), >> and you know what TTs are associated with it. Mark >> the tcb as >> terminated, then wait for the TTs to complete. When >> they are done, >> throw the whole thing out. >> >> > What the new proposal does is to make receiving >> stale >> > data after task terminations a non-problem - via a >> > separate accounting scheme and new target >> semantics. >> >> And I think this is a good thing. However I still >> think we need to >> abandon the inter-nexus TT wait for the old scheme. >> >> Take care, >> >> Bill >> >> > > > > >__________________________________________ >Yahoo! DSL - Something to write home about. >Just $16.99/mo. or less. >dsl.yahoo.com > > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 08 13:45:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQlc-0000Sc-73; Thu, 08 Dec 2005 13:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQlY-0000Q3-2v for ips@megatron.ietf.org; Thu, 08 Dec 2005 13:45:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22937 for ; Thu, 8 Dec 2005 13:44:23 -0500 (EST) Received: from web51913.mail.yahoo.com ([206.190.48.76]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkQlZ-0003oD-S9 for ips@ietf.org; Thu, 08 Dec 2005 13:45:18 -0500 Received: (qmail 87911 invoked by uid 60001); 8 Dec 2005 18:45:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FAYyMhWp3rji4s942D+il7Zcna90c6q68Nbqb686f8nWKpC6im82So4kPgGOOZwXmsaFXoEbaBvLxRsEHuBZEIWT/46+f6/j0OTsB9TCQVrGiRpbBICEOBvBK0ECSnw+TqXW27Xb2krV2xsOaPdcQ9O5V4zeqhcJNYTQZ5S3zBU= ; Message-ID: <20051208184506.87909.qmail@web51913.mail.yahoo.com> Received: from [156.153.255.243] by web51913.mail.yahoo.com via HTTP; Thu, 08 Dec 2005 10:45:06 PST Date: Thu, 8 Dec 2005 10:45:06 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Fast multi-task abort model To: William Studenmund In-Reply-To: <7d06e1a34bf0da5ce25c145c9abcb4d8@wasabisystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 8bit Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > If the target breaks the buffer associations, does > it really have to > invalidate the TTT? We may be using different terminologies..... I think of: "invalidating the TTT" = "breaking the buffer association" = "not having a buffer behind a TTT" And that can be a serious problem in iSCSI-3720, and fatal in iSCSI/iSER. >I think it's fine for a task to be > terminated at the > SCSI level yet still have things going on (being > cleaned up) at the > iSCSI level. Precisely. That's the fast multi-task abort model. I don't see a disagreement wrt the preferred behavior. Only on the mechanics of how to phase it in. I think if the inter-nexus TTT wait requirement from the 3720 text is deleted, we have to add several careful sentences on how it would still work well with both iSCSI-3720 and iSCSI/iSER. By then, we would have suggested enough deltas to protocol behavior that it would be very close to the new proposal. Note that this is different from scratching the other two waits - inter-nexus CmdSN gap wait, inter-nexus StatSN ack wait. They can be simply dropped without any additional mandates. >either migrate > everyone to the new > Async PDU or to warn implementors and administrators > that failover can > take a long time on iSCSI. >.... so we'll be at a > competitive disadvantage. Yes, multi-task abort affecting multiple nexuses (i.e., excluding Abort Task Set) may indeed take a long time in iSCSI today. And yes, it is a competititve disadvantage. That is what prompted several on the list to point out the current problems, and prompted me to propose the new model. We will have seriously improved the situation in a few months. Mallikarjun --- William Studenmund wrote: > On Dec 6, 2005, at 3:12 PM, Mallikarjun C. wrote: > > >> Mark > >> the tcb as > >> terminated, then wait for the TTs to complete. > When > >> they are done, > >> throw the whole thing out. > > > > Reasonable, and this is in abstract what the new > > proposal does. > > > > RFC 3720 does not explicitly say "wait for TTTs to > > complete even after TMF is completed". The only > > default interpretation of the 3720 text today > would be > > to invalidate the TTTs along with the buffer > > associations when a task is "terminated" and the > TMF > > completion is generated. An invalid TTT/STag is > in > > fact a problem for at least two reasons - > > If the target breaks the buffer associations, does > it really have to > invalidate the TTT? > > We're dragging in a lot of details that feel like > they are > implementation specific. Our target has no trouble > with the idea that a > task is dead yet has active TTTs, the contents of > which will never be > used. We just let the TTTs drain off and clean up > the task. We do this > as you've done a good job of explaining to me that > things are REALLY > messy if we don't. :-) > > As long as data received "after" (in terms of some > atomic state change) > the termination will be discarded, does the > termination act really care > how how the cleanup gets done? > > Put another way, I think it's fine for a task to be > terminated at the > SCSI level yet still have things going on (being > cleaned up) at the > iSCSI level. As long as cleanup transfers aren't > actually placed to the > SCSI device, I don't see why a target can't do this. > > I understand that the STags won't be able to go > away. But as long as > the target device doesn't use the buffers the STag > goes into, is there > a problem? Thus if a target breaks buffer > associations, we should be > fine, shouldn't we? > > > a) All Data-Out PDU (with the now invalid TTTs) > are > > protocol errors that should be Reject'ed. > > b) Any DDP tagged data segment to an invalid STag > > immediately takes the connection down (for > > iSCSI/iSER). > > > > What I am suggesting in the new proposal is that > there > > be an explicit event to conclude the "waiting for > TTTs > > to complete" for a target at the iSCSI control > > protocol level (not at the Datamover level). That > new > > event is the reception of the Nop-Out ack'ing the > new > > Async PDU. And that brings us to the new > proposal. > > I understand that. But that's orthogonal to what I'm > very concerned > about. I'm not concerned that session A waits for > its TTTs, nor that > session B waits for its TTTs, nor that session C > waits for its TTTs, > but that session D has to wait for all of them to > complete a TMF. > > I think that session A waiting for TTTs or using the > new Async PDU is > fine. As for session B and session C. > > > I think the 3720 text is self-consistent (although > it > > isn't the most efficient). Simply scratching the > TTT > > cross-nexus requirement off the current text, > IMHO, is > > not the right thing. We need to specify the new > > initiator and target semantics in the absence of > that > > requirement, and that's what the fast multi-task > abort > > proposal attempts. > > We have a denial of service window. I don't see how > we can get rid of > it w/o ripping out the cross-nexus TTT wait. > > I also don't understand why it's ok to remove the > inter-nexus wait for > the new technique and not for the old? > > The only alternatives I see are to either migrate > everyone to the new > Async PDU or to warn implementors and administrators > that failover can > take a long time on iSCSI. > > The latter will be a real shame. My understanding is > that FibreChannel > doesn't have such delays, so we'll be at a > competitive disadvantage. > > Take care, > > Bill > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 08 14:28:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRQz-0005H3-Dq; Thu, 08 Dec 2005 14:28:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRQw-0005Fa-Fs for ips@megatron.ietf.org; Thu, 08 Dec 2005 14:28:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29127 for ; Thu, 8 Dec 2005 14:27:01 -0500 (EST) Received: from web51904.mail.yahoo.com ([206.190.48.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkRQp-0005fe-MM for ips@ietf.org; Thu, 08 Dec 2005 14:27:57 -0500 Received: (qmail 30384 invoked by uid 60001); 8 Dec 2005 19:27:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=t1DZmIBihI+xX0B6/u5WkpHGo2BRDFvKCNwv2netwsoGM88WUMNwFFqXa6BYMS3dFgvnmSxyah9RrJ2tRIWcRWCV2XD09iXCjVDtS1yXVnZ+PuC+aRLLyasZIEsFGcwqcOM4cM5cmK/Tb8zzRoUzCxlyZVqsEfAgdvwC2NhTadA= ; Message-ID: <20051208192743.30382.qmail@web51904.mail.yahoo.com> Received: from [156.153.255.243] by web51904.mail.yahoo.com via HTTP; Thu, 08 Dec 2005 11:27:43 PST Date: Thu, 8 Dec 2005 11:27:43 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Fast multi-task abort model To: "ips@ietf.org" In-Reply-To: <798981da4f2ab748a830f9cf10a767d2@mail2.silverbacksystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 8bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Somesh, Thanks for the review. The new model does not require any additional knowledge in the iSCSI layer than the layer already has, and SCSI layer should not get involved in generating iSCSI Async PDUs either. The model intends that the iSCSI layer decides when to generate an Async PDU based on its standard state information (active TTTs, task-session-connection affinity, LUN-TTT association). The new (or the old) model does not require iSCSI layer to know about TMF-support-capabilities of the back-end. SCSI-level TMF Response is generated by the SCSI back-end as always. If the back-end does not support a TMF function, I expect none of the steps after #1 will happen. You're right that the Nop-Out ack/timeout is only for the purpose of recovering buffer resources behind affected TTTs. Hope that clarifies the model description. Mallikarjun --- Somesh Gupta wrote: > (My first attempt did not seem to make it through. > Apologies > if people see a duplicate.) > > The discussion prompted me to take a closer look at > the fast multi-task abort model. In principal, I > agree > that the new async PDU helps the target and > initiator > reach a common understanding of which tasks have > been cleared, and stop processing them. > > However, I think the language of the proposal puts > too much knowledge in the target transport layer - > the language implies that the target transport layer > is managing the task set for a LUN - it is > responsible > for determining which initiators have active tasks > on > a specific LUN, and which tasks these are, what > their > disposition is - and for sending a TMF response (and > which > TMFs are supported and what the back-end impact of > each is). > > It is not so simple since the values of the TAS, TST > and > Qerr bits really determine the actions. > > There is some unavoidable interaction/modification > of > the SCSI layer to handle this situation correctly - > because only the SCSI layer knows whether for the > cleared tasks > a. the initiator is really not expecting anything > (the nexus is the same as which received the tmf > command) > b. should be sent an explicit status of ABORTED BY > ANOTHER > INITIATOR > c. No impact > d. Needs to be cleaned up through the asynch > notification > mechanism (different nexus, TST=0:Qerr=01b;TAS=0) > c. Whether the initiator is likely to be dead (LUN > Reset > with reserve/release model or equivalent behavior > in > persistent reservation model) > > In other words, the asynch PDU must be explicitly > triggered > by the SCSI layer on each impacted Nexus - if adding > the > asynch PDU becomes an issues, we can use a new > response > code which would be sent for every command. In any > case, > the statsn acknowledgement rule should help the > initiator > and target flush all impacted commands in the pipe, > and > have a common understanding of what is impacted. > > Bill makes a very valid point about the real world > situation > of clusters. Shouldn't the SCSI layer be able to > send a > response for the TMF when it has triggered the > asynch PDU on > each of the Nexuses (is it Nexi?). The > acknowledgement or > time-out is only for the purposes of recovering the > buffers? > -- Mallikarjun Mallikarjun Chadalapaka __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 08 15:15:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSAm-0005AN-AW; Thu, 08 Dec 2005 15:15:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSAj-000597-FS for ips@megatron.ietf.org; Thu, 08 Dec 2005 15:15:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05940 for ; Thu, 8 Dec 2005 15:14:20 -0500 (EST) Received: from webmail2.silverbacksystems.com ([65.172.158.65] helo=silverbacksystems.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSAd-0007vo-B7 for ips@ietf.org; Thu, 08 Dec 2005 15:15:16 -0500 Received: from [10.0.16.116] (account sgupta@silverbacksystems.com) by silverbacksystems.com (CommuniGate Pro IMAP 4.3.7) with XMIT id 532120 for ips@ietf.org; Thu, 08 Dec 2005 12:15:00 -0800 Subject: RE: [Ips] Fast multi-task abort model Date: Thu, 08 Dec 2005 12:14:59 -0800 Message-Id: In-Reply-To: <20051208192743.30382.qmail@web51904.mail.yahoo.com> MIME-Version: 1.0 Thread-Topic: [Ips] Fast multi-task abort model Priority: Normal Importance: normal X-MSMail-Priority: normal X-Priority: 3 Sensitivity: Normal Thread-Index: AcX8NBC9Rzlcz2lPSqO6w7/A1uZt4g== From: "Somesh Gupta" To: "ips@ietf.org" X-MAPI-LastModified: Thu, 08 Dec 2005 12:14:59 -0800 X-Mailer: CommuniGate Pro MAPI Connector 1.1.21/1.1.25(local) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, I am sort of missing the point. Are you saying that the Mode Control Page belongs to the transport layer? It is not sufficient to know the active TTTs, task-session-connection affinity, and LUN-TTT association. You have to know the TAS, TST and Qerr bit settings to determine if the commands are to be aborted without response, with response, no impact, blocked. So either the transport layer has to be know the Mode Control Page or the SCSI layer has to explicitly trigger the abort - it does not say send an async PDU, but something like abort all commands on the lun and the nexus receiving tmf was xxxx. Also as you say the target does not progress beyond step 1 - but step 1 is where the commands start to get aborted (immediately) - even if the tmf is not supported by the SCSI layer? BTW the new mechanism is not only useful for getting a common understanding between target and initiator for tmf commands, but may be useful for Unit Attention conditions as well (without having to implement SPC-3). Somesh >-----Original Message----- >From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On >Behalf Of Mallikarjun C. >Sent: Thursday, December 08, 2005 11:28 AM >To: ips@ietf.org >Subject: Re: [Ips] Fast multi-task abort model > > >Hi Somesh, > >Thanks for the review. > >The new model does not require any additional >knowledge in the iSCSI layer than the layer already >has, and SCSI layer should not get involved in >generating iSCSI Async PDUs either. The model >intends that the iSCSI layer decides when to generate >an Async PDU based on its standard state information >(active TTTs, task-session-connection affinity, >LUN-TTT association). > >The new (or the old) model does not require iSCSI >layer to know about TMF-support-capabilities of the >back-end. SCSI-level TMF Response is generated by the >SCSI back-end as always. If the back-end does not >support a TMF function, I expect none of the steps >after #1 will happen. > >You're right that the Nop-Out ack/timeout is only for >the purpose of recovering buffer resources behind >affected TTTs. > >Hope that clarifies the model description. > >Mallikarjun > > > > > >--- Somesh Gupta >wrote: > >> (My first attempt did not seem to make it through. >> Apologies >> if people see a duplicate.) >> >> The discussion prompted me to take a closer look at >> the fast multi-task abort model. In principal, I >> agree >> that the new async PDU helps the target and >> initiator >> reach a common understanding of which tasks have >> been cleared, and stop processing them. >> >> However, I think the language of the proposal puts >> too much knowledge in the target transport layer - >> the language implies that the target transport layer >> is managing the task set for a LUN - it is >> responsible >> for determining which initiators have active tasks >> on >> a specific LUN, and which tasks these are, what >> their >> disposition is - and for sending a TMF response (and >> which >> TMFs are supported and what the back-end impact of >> each is). >> >> It is not so simple since the values of the TAS, TST >> and >> Qerr bits really determine the actions. >> >> There is some unavoidable interaction/modification >> of >> the SCSI layer to handle this situation correctly - >> because only the SCSI layer knows whether for the >> cleared tasks >> a. the initiator is really not expecting anything >> (the nexus is the same as which received the tmf >> command) >> b. should be sent an explicit status of ABORTED BY >> ANOTHER >> INITIATOR >> c. No impact >> d. Needs to be cleaned up through the asynch >> notification >> mechanism (different nexus, TST=3D0:Qerr=3D01b;TAS=3D0) >> c. Whether the initiator is likely to be dead (LUN >> Reset >> with reserve/release model or equivalent behavior >> in >> persistent reservation model) >> >> In other words, the asynch PDU must be explicitly >> triggered >> by the SCSI layer on each impacted Nexus - if adding >> the >> asynch PDU becomes an issues, we can use a new >> response >> code which would be sent for every command. In any >> case, >> the statsn acknowledgement rule should help the >> initiator >> and target flush all impacted commands in the pipe, >> and >> have a common understanding of what is impacted. >> >> Bill makes a very valid point about the real world >> situation >> of clusters. Shouldn't the SCSI layer be able to >> send a >> response for the TMF when it has triggered the >> asynch PDU on >> each of the Nexuses (is it Nexi?). The >> acknowledgement or >> time-out is only for the purposes of recovering the >> buffers? >> > > >-- >Mallikarjun > > >Mallikarjun Chadalapaka > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 08 20:54:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkXT0-0001Kj-RI; Thu, 08 Dec 2005 20:54:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkXSz-0001Gq-Ed for ips@megatron.ietf.org; Thu, 08 Dec 2005 20:54:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19863 for ; Thu, 8 Dec 2005 20:53:31 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkXSs-00069N-IK for ips@ietf.org; Thu, 08 Dec 2005 20:54:29 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id EFA8B871E8; Thu, 8 Dec 2005 20:54:07 -0500 (EST) In-Reply-To: <20051208184506.87909.qmail@web51913.mail.yahoo.com> References: <20051208184506.87909.qmail@web51913.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <767e135a3db952c60cbea708209022db@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Fast multi-task abort model Date: Thu, 8 Dec 2005 17:53:59 -0800 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0807139536==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0807139536== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--980266465" Content-Transfer-Encoding: 7bit --Apple-Mail-1--980266465 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 8, 2005, at 10:45 AM, Mallikarjun C. wrote: >> If the target breaks the buffer associations, does >> it really have to >> invalidate the TTT? > > We may be using different terminologies..... Probably. > I think of: > "invalidating the TTT" = "breaking the buffer > association" = "not having a buffer behind a TTT" > > And that can be a serious problem in iSCSI-3720, and > fatal in iSCSI/iSER. Because of that concern, I would like to suggest we refine our terminology, and make a distinction that hasn't been made before. I suggest we consider "breaking the buffer association" at the SCSI layer to be separate from breaking it at the iSCSI level. All the task state diagram in SAM-2 (and later SAM) care about is the SCSI layer. Specifically, I think it'd be fine for an abort to leave the TTT's buffer around and simply do nothing with it once the TTT is done. Thus all the PDUs flying at the target still find a destination (either in TCP iSCSI or iSER). >> I think it's fine for a task to be >> terminated at the >> SCSI level yet still have things going on (being >> cleaned up) at the >> iSCSI level. > > Precisely. That's the fast multi-task abort model. > > I don't see a disagreement wrt the preferred behavior. > Only on the mechanics of how to phase it in. I think > if the inter-nexus TTT wait requirement from the 3720 > text is deleted, we have to add several careful > sentences on how it would still work well with both > iSCSI-3720 and iSCSI/iSER. By then, we would have > suggested enough deltas to protocol behavior that it > would be very close to the new proposal. Kind of. I agree we will need to add text, but I don't think it will be that bad. I see the inter-nexus-TTT-fixup idea as an intermediate step between what we have now and the new multi-task abort model. We add the idea of not waiting for inter-nexus cleanup to finish (we do wait for it to start!) and we add the idea that data arriving after cleanup started to not get used by the SCSI layer. The new multi-task abort model then adds a method by which we can cleanly fix multiple tasks at once. > Note that this is different from scratching the other > two waits - inter-nexus CmdSN gap wait, inter-nexus > StatSN ack wait. They can be simply dropped without > any additional mandates. I still don't see how dropping the TTT wait will hurt more than the others. I'm really trying to, but can't. I fully agree I'm proposing a notable protocol change. :-) The reason I'm contemplating it, much less strongly suggesting it, is that 1) I think the wait we have isn't workable. Something needs to be done. 2) I'm not really sure how initiators will notice the change. Since the on-the-wire PDUs won't change, I suspect many initiators will never notice. Take care, Bill --Apple-Mail-1--980266465 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDmOO+DJT2Egh26K0RAlZFAJ47LPTeWPZ2j0vFF4vuNWepCsoE5gCcCef9 730ALMm/6P+KJzjqWGjr5xE= =ko59 -----END PGP SIGNATURE----- --Apple-Mail-1--980266465-- --===============0807139536== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0807139536==-- From ips-bounces@ietf.org Fri Dec 09 18:52:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eks2S-0004Vz-Ci; Fri, 09 Dec 2005 18:52:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eks2Q-0004Tz-2c for ips@megatron.ietf.org; Fri, 09 Dec 2005 18:52:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29578 for ; Fri, 9 Dec 2005 18:51:26 -0500 (EST) Received: from web51915.mail.yahoo.com ([206.190.48.78]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eks2V-000402-6H for ips@ietf.org; Fri, 09 Dec 2005 18:52:38 -0500 Received: (qmail 54395 invoked by uid 60001); 9 Dec 2005 23:52:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Fc43pPU8Z5mIsKo3yFbqmN7RQYx/2vBYfiJPlgmVsS9smjUG4Ss8XvyF/USeZNRqgYl28mYunpQKVhHBluUqLixtU9WtbIUCXpiD7qkXijxQLPEsQnj17t6Wc9VTGnhljzm/ydzuILpnidJCVulrzxvqEPoXRn6bzy0jLsedgIg= ; Message-ID: <20051209235206.54393.qmail@web51915.mail.yahoo.com> Received: from [156.153.255.243] by web51915.mail.yahoo.com via HTTP; Fri, 09 Dec 2005 15:52:06 PST Date: Fri, 9 Dec 2005 15:52:06 -0800 (PST) From: "Mallikarjun C." Subject: RE: [Ips] Fast multi-task abort model To: "ips@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 8bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Somesh, I do not see anything new per se. The new abort model does not change: a) the SCSI-iSCSI interface specific to the implementation (Async can be keyed off the same API touch points), b) division of labor between iSCSI and SCSI layers (e.g., mode pages etc.), and c) state information maintained at the iSCSI layer (standard state information I listed earlier). You however have a valid point on the text when you flagged "immediately" in step #1 - I now see how it can be read. Without going into implementation specifics even while keeping the text precise, I suggest changing: 1. Target iSCSI layer initiates the termination proceedings on all affected tasks immediately - this may involve interacting with the local SCSI layer. to: 1. Target iSCSI layer initiates the termination proceedings on all affected tasks via notifying the local SCSI layer. I hope that addresses your concern. Thanks. Mallikarjun --- Somesh Gupta wrote: > Mallikarjun, > > I am sort of missing the point. Are you saying that > the > Mode Control Page belongs to the transport layer? > It is not sufficient to know the active TTTs, > task-session-connection affinity, and LUN-TTT > association. > > You have to know the TAS, TST and Qerr bit settings > to determine if the commands are to be aborted > without > response, with response, no impact, blocked. > > So either the transport layer has to be know the > Mode > Control Page or the SCSI layer has to explicitly > trigger the abort - it does not say send an async > PDU, > but something like abort all commands on the lun and > the nexus receiving tmf was xxxx. > > Also as you say the target does not progress beyond > step > 1 - but step 1 is where the commands start to get > aborted > (immediately) - even if the tmf is not supported by > the > SCSI layer? > > BTW the new mechanism is not only useful for getting > a > common understanding between target and initiator > for > tmf commands, but may be useful for Unit Attention > conditions as well (without having to implement > SPC-3). > > Somesh > > >-----Original Message----- > >From: ips-bounces@ietf.org > [mailto:ips-bounces@ietf.org] On > >Behalf Of Mallikarjun C. > >Sent: Thursday, December 08, 2005 11:28 AM > >To: ips@ietf.org > >Subject: Re: [Ips] Fast multi-task abort model > > > > > >Hi Somesh, > > > >Thanks for the review. > > > >The new model does not require any additional > >knowledge in the iSCSI layer than the layer already > >has, and SCSI layer should not get involved in > >generating iSCSI Async PDUs either. The model > >intends that the iSCSI layer decides when to > generate > >an Async PDU based on its standard state > information > >(active TTTs, task-session-connection affinity, > >LUN-TTT association). > > > >The new (or the old) model does not require iSCSI > >layer to know about TMF-support-capabilities of the > >back-end. SCSI-level TMF Response is generated by > the > >SCSI back-end as always. If the back-end does not > >support a TMF function, I expect none of the steps > >after #1 will happen. > > > >You're right that the Nop-Out ack/timeout is only > for > >the purpose of recovering buffer resources behind > >affected TTTs. > > > >Hope that clarifies the model description. > > > >Mallikarjun __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Dec 09 22:05:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekv3X-00063B-2c; Fri, 09 Dec 2005 22:05:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekv3W-000624-9q for ips@megatron.ietf.org; Fri, 09 Dec 2005 22:05:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02062 for ; Fri, 9 Dec 2005 22:04:51 -0500 (EST) Received: from web51902.mail.yahoo.com ([206.190.48.65]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ekv3i-0005Yd-6h for ips@ietf.org; Fri, 09 Dec 2005 22:06:04 -0500 Received: (qmail 32311 invoked by uid 60001); 10 Dec 2005 03:05:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5OvrYzQSr/IEi3IrKBLLSMMqtYTtotoahN2jJQQ8fxz9pndNF9LAFzP6mkEOlsbymRnuOjAw9dcfiUFNwpKHBtYnGGZHBSBBQd38Hhqt3DWYQvzES1SZ/bOCQT8AvS8huSL4QUrAo0CnvGEF1R8bSlY4KNeIFXqOdQMclZptftQ= ; Message-ID: <20051210030533.32309.qmail@web51902.mail.yahoo.com> Received: from [128.120.216.135] by web51902.mail.yahoo.com via HTTP; Fri, 09 Dec 2005 19:05:33 PST Date: Fri, 9 Dec 2005 19:05:33 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Fast multi-task abort model To: IPS In-Reply-To: <767e135a3db952c60cbea708209022db@wasabisystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 8bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bill, > I still don't see how dropping the TTT wait will > hurt more than the > others. I'm really trying to, but can't. OK. Let me attempt to be more specific. Here are some spec implications if we eliminate the inter-nexus TTT wait from RFC 3720 text. All these must be specified in addition to deleting the TTT wait. - Do not deallocate the buffers assigned to the currently active TTTs at the time of task termination. - Do not assign the outstanding TTT-LUN pairs to other tasks on the matching session-connection until a "TMF TTT-Buffer release event" although tasks that own the TTTs are terminated. - Do not Reject any Data-Out PDUs with an invalid ITT-TTT combination if the combination has a buffer assignment. Place the inbound data in the assigned buffer and ignore the data. - The outstanding TTTs and the assigned buffers can be freed only upon the corresponding "TMF TTT-Buffer release event". The event can be one of: a) Last Data-Out PDU with the F-bit set for that TTT-LUN combination (not an ideal fit for iSCSI/iSER) b) Implementation-specific timeout c) Connection/session termination And on the initiator side, we have to specify that an initiator must continue to respond to an outstanding TTT via Data-out PDUs even after the tasks are terminated - i.e. even after TMF Response with "success" is received. These are fairly invasive changes to current model. These *can* however be done. Assume we have them all specified as RFC 3720 "errata", how far off would then the new multi-task abort model be? I see only two additional items remaining - sending an Async PDU, and specifying one additional TMF TTT-Buffer Release event:"d) Receiving a Nop-Out ack for the Async PDU" Given all this, I still think the best course of specifying this whole area is: (1) Make two specific deltas to RFC 3720 model as "errata" (a) Delete 3rd-party CmdSN gap wait (b) Delete 3rd-party StatSN ack wait This would be the new default iSCSI behavior. (2) Define the new multi-task abort model separately. This includes the above two deltas and the TTT-wait delta. This will be the operational behavior only if "FastMultiTaskAbort=Yes" is negotiated. Mallikarjun --- William Studenmund wrote: > On Dec 8, 2005, at 10:45 AM, Mallikarjun C. wrote: > > >> If the target breaks the buffer associations, > does > >> it really have to > >> invalidate the TTT? > > > > We may be using different terminologies..... > > Probably. > > > I think of: > > "invalidating the TTT" = "breaking the buffer > > association" = "not having a buffer behind a TTT" > > > > And that can be a serious problem in iSCSI-3720, > and > > fatal in iSCSI/iSER. > > Because of that concern, I would like to suggest we > refine our > terminology, and make a distinction that hasn't been > made before. > > I suggest we consider "breaking the buffer > association" at the SCSI > layer to be separate from breaking it at the iSCSI > level. All the task > state diagram in SAM-2 (and later SAM) care about is > the SCSI layer. > > Specifically, I think it'd be fine for an abort to > leave the TTT's > buffer around and simply do nothing with it once the > TTT is done. Thus > all the PDUs flying at the target still find a > destination (either in > TCP iSCSI or iSER). > > >> I think it's fine for a task to be > >> terminated at the > >> SCSI level yet still have things going on (being > >> cleaned up) at the > >> iSCSI level. > > > > Precisely. That's the fast multi-task abort > model. > > > > I don't see a disagreement wrt the preferred > behavior. > > Only on the mechanics of how to phase it in. I > think > > if the inter-nexus TTT wait requirement from the > 3720 > > text is deleted, we have to add several careful > > sentences on how it would still work well with > both > > iSCSI-3720 and iSCSI/iSER. By then, we would have > > suggested enough deltas to protocol behavior that > it > > would be very close to the new proposal. > > Kind of. I agree we will need to add text, but I > don't think it will be > that bad. > > I see the inter-nexus-TTT-fixup idea as an > intermediate step between > what we have now and the new multi-task abort model. > We add the idea of > not waiting for inter-nexus cleanup to finish (we do > wait for it to > start!) and we add the idea that data arriving after > cleanup started to > not get used by the SCSI layer. The new multi-task > abort model then > adds a method by which we can cleanly fix multiple > tasks at once. > > > Note that this is different from scratching the > other > > two waits - inter-nexus CmdSN gap wait, > inter-nexus > > StatSN ack wait. They can be simply dropped > without > > any additional mandates. > > I still don't see how dropping the TTT wait will > hurt more than the > others. I'm really trying to, but can't. > > I fully agree I'm proposing a notable protocol > change. :-) The reason > I'm contemplating it, much less strongly suggesting > it, is that 1) I > think the wait we have isn't workable. Something > needs to be done. 2) > I'm not really sure how initiators will notice the > change. Since the > on-the-wire PDUs won't change, I suspect many > initiators will never > notice. > > Take care, > > Bill > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Dec 10 00:07:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekwwy-00014d-DG; Sat, 10 Dec 2005 00:07:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekwwv-00014H-FY for ips@megatron.ietf.org; Sat, 10 Dec 2005 00:07:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12144 for ; Sat, 10 Dec 2005 00:06:02 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekwx2-0000TE-TG for ips@ietf.org; Sat, 10 Dec 2005 00:07:17 -0500 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 5B4728719A; Sat, 10 Dec 2005 00:06:30 -0500 (EST) In-Reply-To: <20051210030533.32309.qmail@web51902.mail.yahoo.com> References: <20051210030533.32309.qmail@web51902.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <27a3a5b824d52efbeef6310fe24ad71a@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Fast multi-task abort model Date: Fri, 9 Dec 2005 21:06:19 -0800 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1617008148==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1617008148== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10--882326822" Content-Transfer-Encoding: 7bit --Apple-Mail-10--882326822 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 9, 2005, at 7:05 PM, Mallikarjun C. wrote: > Bill, > >> I still don't see how dropping the TTT wait will >> hurt more than the >> others. I'm really trying to, but can't. > > OK. Let me attempt to be more specific. Here are > some spec implications if we eliminate the inter-nexus > TTT wait from RFC 3720 text. All these must be > specified in addition to deleting the TTT wait. > > - Do not deallocate the buffers assigned to the > currently active TTTs at the time of task termination. > > - Do not assign the outstanding TTT-LUN pairs to other > tasks on the matching session-connection until a "TMF > TTT-Buffer release event" although tasks that own the > TTTs are terminated. These details assume a specific implementation. I favor mentioning them as a suggestion, but different implementations may or may not need them. For instance, an implementation that deals with mbuf chains may not need the buffers anymore. Just notice that the PDU is destined for a dying TTT and drop the mbuf chain. > - Do not Reject any Data-Out PDUs with an invalid > ITT-TTT combination if the combination has a buffer > assignment. Place the inbound data in the assigned > buffer and ignore the data. All we really need is for the PDUs to not be rejected. How exactly the target throws away the data is up to it. :-) > - The outstanding TTTs and the assigned buffers can be > freed only upon the corresponding "TMF TTT-Buffer > release event". The event can be one of: > a) Last Data-Out PDU with the F-bit set for that > TTT-LUN combination (not an ideal fit for > iSCSI/iSER) > b) Implementation-specific timeout > c) Connection/session termination As above, this is an implementation detail. A target can just as reasonably close all connections after sending a "closing connection, you can immediately log back in" event. It's not as efficient, but it works. :-) I do, however, like the idea of mentioning an implementation-specific timeout. > And on the initiator side, we have to specify that an > initiator must continue to respond to an outstanding > TTT via Data-out PDUs even after the tasks are > terminated - i.e. even after TMF Response with > "success" is received. I'm sorry, I only have been concerned about the inter-nexus delay. I think it's fine for the aborting/terminating session to have to be all cleaned up before proceeding. Thus the aborting session will not see the TMF response until after all its tasks have stopped. Hmmm... Let me be firmer. I think we should leave the intra-nexus delay in place. Thus no session should have to sustain tasks after a "succesful" TMF Response. > These are fairly invasive changes to current model. > These *can* however be done. Assume we have them all > specified as RFC 3720 "errata", how far off would then > the new multi-task abort model be? I see only two > additional items remaining - sending an Async PDU, and > specifying one additional TMF TTT-Buffer Release > event:"d) Receiving a Nop-Out ack for the Async PDU" This is a good question. The difference is that, at least as I envision things, the initiators will need no changes. Initiators designed for the old model will still work with this intermediate one. Also, we will not be changing the on-the-wire packets. I like the new model, I just think that we need to fix the old one in addition to adding it. > Given all this, I still think the best course of > specifying this whole area is: > > (1) Make two specific deltas to RFC 3720 model as > "errata" > (a) Delete 3rd-party CmdSN gap wait > (b) Delete 3rd-party StatSN ack wait > This would be the new default iSCSI behavior. > > (2) Define the new multi-task abort model separately. > This > includes the above two deltas and the TTT-wait > delta. > This will be the operational behavior only if > "FastMultiTaskAbort=Yes" is negotiated. Well, we disagree. :-) What does everyone else think? Take care, Bill --Apple-Mail-10--882326822 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDmmJRDJT2Egh26K0RAvZwAJ44tygq76iRTzcFwOUdC1aYFiCPOgCbBirk bwyayI4ekS5ZwNT0v5bYd7s= =/fFT -----END PGP SIGNATURE----- --Apple-Mail-10--882326822-- --===============1617008148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1617008148==-- From ips-bounces@ietf.org Fri Dec 16 09:44:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnGoV-0003A5-0W; Fri, 16 Dec 2005 09:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnGoT-00039b-Lg for ips@megatron.ietf.org; Fri, 16 Dec 2005 09:44:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28235 for ; Fri, 16 Dec 2005 09:43:01 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnGq5-0001Ph-MR for ips@ietf.org; Fri, 16 Dec 2005 09:45:42 -0500 Received: by xproxy.gmail.com with SMTP id t12so509629wxc for ; Fri, 16 Dec 2005 06:43:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=kXYKvFcqEqHGrEJYbklLoe+7yl6IbQO4ynY2KlvMja3cdlNWT4g8z8kcBXNNO50vdpj+4PmHtHn1AmZDF/rPyZYnGaK5NdCP+FREIsYnMNUZxxNQe9S5kR+Q4pWqFvLGG5YoKTSWBg6iZTBT/FR+IvTZM0RrQihGiz2EYc+kol0= Received: by 10.70.7.5 with SMTP id 5mr994631wxg; Fri, 16 Dec 2005 06:43:58 -0800 (PST) Received: by 10.70.24.6 with HTTP; Fri, 16 Dec 2005 06:43:58 -0800 (PST) Message-ID: Date: Fri, 16 Dec 2005 20:13:58 +0530 From: Aravind Rajagopal To: ips@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ips] Doubt regarding DataIn sequence. X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1054176146==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1054176146== Content-Type: multipart/alternative; boundary="----=_Part_5105_29447873.1134744238021" ------=_Part_5105_29447873.1134744238021 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi iSCSI Authors, I'm into implementing an iSCSI target, and I came across a scenario while testing the same where I would like some clarification. When there are multiple SCSI Read commands received by a target, is it lega= l for the DataIn PDU's corresponding to the two commands to be sent in an interleaved manner? I think not, given what section "3.2.4.2 Data Transfer Overview" says, but nevertheless thought I'd get it clarified. Thanks in advance, Aravind Rajagopal. ------=_Part_5105_29447873.1134744238021 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi iSCSI Authors,

I'm into implementing an iSCSI target, and I came across a scenario while testing the same where I would like some clarification.

When there are multiple SCSI Read commands received by a target, is it legal for the DataIn PDU's corresponding to the two commands to be sent in an interleaved manner? I think not, given what section "3.2.4.2 Data Transfer Overview" says, but nevertheless thought I'd get it clarified= .

Thanks in advance,
Aravind Rajagopal.

------=_Part_5105_29447873.1134744238021-- --===============1054176146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1054176146==-- From ips-bounces@ietf.org Tue Dec 20 18:52:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EorGy-0005cl-2O; Tue, 20 Dec 2005 18:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EorGv-0005bS-Ru for ips@megatron.ietf.org; Tue, 20 Dec 2005 18:51:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19619 for ; Tue, 20 Dec 2005 18:50:54 -0500 (EST) Received: from web51910.mail.yahoo.com ([206.190.48.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EorJR-00042C-J4 for ips@ietf.org; Tue, 20 Dec 2005 18:54:34 -0500 Received: (qmail 75918 invoked by uid 60001); 20 Dec 2005 23:51:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zp8x5t2lk+5ojP68B/9sOM+eyiQw2cAklCDraxNvLFrzn64n4CZd2qKRgSWoOeOJs2ftlB9HAtsr0cEyX0didUFSpaEbXDGplQIFqEIUE0AX0jZTwSPH+2cxkUgQ8vlIa6RErXMvuwqUQNTiSZ+xFewGGszoJ5LJFV16eI4Fong= ; Message-ID: <20051220235146.75916.qmail@web51910.mail.yahoo.com> Received: from [156.153.255.243] by web51910.mail.yahoo.com via HTTP; Tue, 20 Dec 2005 15:51:46 PST Date: Tue, 20 Dec 2005 15:51:46 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Fast multi-task abort model To: IPS In-Reply-To: <27a3a5b824d52efbeef6310fe24ad71a@wasabisystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 8bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org What I outlined calls out the RFC3720-legal implementation aspects that will now be illegal (if we "fix" the 3720-model beyond simple errata). So some implementation-specifics do become important in this discussion. > Well, we disagree. :-) What does everyone else > think? Yes, at this point, it'd be good to get feedback from others on the spec approach. My last email summarizes the tactical approach I intend to take for the next draft revision. Thanks. Mallikarjun --- William Studenmund wrote: > On Dec 9, 2005, at 7:05 PM, Mallikarjun C. wrote: > > > Bill, > > > >> I still don't see how dropping the TTT wait will > >> hurt more than the > >> others. I'm really trying to, but can't. > > > > OK. Let me attempt to be more specific. Here are > > some spec implications if we eliminate the > inter-nexus > > TTT wait from RFC 3720 text. All these must be > > specified in addition to deleting the TTT wait. > > > > - Do not deallocate the buffers assigned to the > > currently active TTTs at the time of task > termination. > > > > - Do not assign the outstanding TTT-LUN pairs to > other > > tasks on the matching session-connection until a > "TMF > > TTT-Buffer release event" although tasks that own > the > > TTTs are terminated. > > These details assume a specific implementation. I > favor mentioning them > as a suggestion, but different implementations may > or may not need > them. > > For instance, an implementation that deals with mbuf > chains may not > need the buffers anymore. Just notice that the PDU > is destined for a > dying TTT and drop the mbuf chain. > > > - Do not Reject any Data-Out PDUs with an invalid > > ITT-TTT combination if the combination has a > buffer > > assignment. Place the inbound data in the > assigned > > buffer and ignore the data. > > All we really need is for the PDUs to not be > rejected. How exactly the > target throws away the data is up to it. :-) > > > - The outstanding TTTs and the assigned buffers > can be > > freed only upon the corresponding "TMF TTT-Buffer > > release event". The event can be one of: > > a) Last Data-Out PDU with the F-bit set for that > > TTT-LUN combination (not an ideal fit > for > > iSCSI/iSER) > > b) Implementation-specific timeout > > c) Connection/session termination > > As above, this is an implementation detail. A target > can just as > reasonably close all connections after sending a > "closing connection, > you can immediately log back in" event. It's not as > efficient, but it > works. :-) > > I do, however, like the idea of mentioning an > implementation-specific > timeout. > > > And on the initiator side, we have to specify that > an > > initiator must continue to respond to an > outstanding > > TTT via Data-out PDUs even after the tasks are > > terminated - i.e. even after TMF Response with > > "success" is received. > > I'm sorry, I only have been concerned about the > inter-nexus delay. I > think it's fine for the aborting/terminating session > to have to be all > cleaned up before proceeding. Thus the aborting > session will not see > the TMF response until after all its tasks have > stopped. > > Hmmm... Let me be firmer. I think we should leave > the intra-nexus delay > in place. Thus no session should have to sustain > tasks after a > "succesful" TMF Response. > > > These are fairly invasive changes to current > model. > > These *can* however be done. Assume we have them > all > > specified as RFC 3720 "errata", how far off would > then > > the new multi-task abort model be? I see only two > > additional items remaining - sending an Async PDU, > and > > specifying one additional TMF TTT-Buffer Release > > event:"d) Receiving a Nop-Out ack for the Async > PDU" > > This is a good question. > > The difference is that, at least as I envision > things, the initiators > will need no changes. Initiators designed for the > old model will still > work with this intermediate one. Also, we will not > be changing the > on-the-wire packets. > > I like the new model, I just think that we need to > fix the old one in > addition to adding it. > > > Given all this, I still think the best course of > > specifying this whole area is: > > > > (1) Make two specific deltas to RFC 3720 model as > > "errata" > > (a) Delete 3rd-party CmdSN gap wait > > (b) Delete 3rd-party StatSN ack wait > > This would be the new default iSCSI behavior. > > > > (2) Define the new multi-task abort model > separately. > > This > > includes the above two deltas and the TTT-wait > > delta. > > This will be the operational behavior only if > > "FastMultiTaskAbort=Yes" is negotiated. > > Well, we disagree. :-) What does everyone else > think? > > Take care, > > Bill > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 21 15:51:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpAw0-000727-M8; Wed, 21 Dec 2005 15:51:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpAuc-0006QA-6c; Wed, 21 Dec 2005 15:50:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19546; Wed, 21 Dec 2005 15:49:09 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpAx8-0006ft-1d; Wed, 21 Dec 2005 15:52:52 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EpAuQ-0005Xx-BN; Wed, 21 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Dec 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-scsi-mib-08.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definition of Managed Objects for SCSI Entities Author(s) : M. Hallak, et al. Filename : draft-ietf-ips-scsi-mib-08.txt Pages : 95 Date : 2005-12-21 This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-scsi-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-scsi-mib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-21122145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-scsi-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-scsi-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-21122145.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Wed Dec 21 18:12:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpD8H-0004no-7w; Wed, 21 Dec 2005 18:12:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpD8F-0004mN-8y for ips@megatron.ietf.org; Wed, 21 Dec 2005 18:12:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25121 for ; Wed, 21 Dec 2005 18:11:21 -0500 (EST) Received: from web51902.mail.yahoo.com ([206.190.48.65]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EpDAu-0001x8-Uk for ips@ietf.org; Wed, 21 Dec 2005 18:15:15 -0500 Received: (qmail 13341 invoked by uid 60001); 21 Dec 2005 23:12:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qLP1OAb+rchi3i35FL91Sm8l8/ilEe4Go9+EUsxtHqztjUKtTbLH2dFMZ7GciZ7JaK+QgXgQzQUXKc2YuExh6t8MXoYxI3pfG4LSr03HgR0WoOf/X/S7cffKVxeQEE0vL0MOYecHo/gvK+oUXThAU0KnpLijIyynQ2eMKfJGOGU= ; Message-ID: <20051221231215.13339.qmail@web51902.mail.yahoo.com> Received: from [156.153.255.243] by web51902.mail.yahoo.com via HTTP; Wed, 21 Dec 2005 15:12:15 PST Date: Wed, 21 Dec 2005 15:12:15 -0800 (PST) From: "Mallikarjun C." Subject: RE: [Ips] Fast multi-task abort model To: IPS In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA25121 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Dmitry, Thanks for the feedback. Yes, the FastMultiTaskAbort should be a session-scoped key, and wait should be contingent on this key being negotiated to "Yes" on each session. I will make that clear in the text. Mallikarjun=20 --- Dmitry Fomichev wrote: > Mallikarjun, >=20 > Just wanted to give my thumbs up to the new fast > multi-task abort model. > It seems, this model can help to speed up the > operations in question, > especially in multi-path configurations. >=20 > My only suggestion is to clarify the whole procedure > for scenarios > where some of the sessions to a LU have negotiated > FastMultiTaskAbort=3DYes and > others may have negotiated > FastMultiTaskAbort=3DNo/NotUnderstood. In such > cases, I think there still should be TTT wait on > those sessions > that don't use the new model. >=20 > Best, > Dmitry >=20 >=20 > -----Original Message----- > From: ips-bounces@ietf.org > [mailto:ips-bounces@ietf.org]On Behalf Of > Mallikarjun C. > Sent: 20 =E4=E5=EA=E0=E1=F0=FF 2005 =E3. 18:52 > To: IPS > Subject: Re: [Ips] Fast multi-task abort model >=20 >=20 > What I outlined calls out the RFC3720-legal > implementation aspects that will now be illegal (if > we > "fix" the 3720-model beyond simple errata). So some > implementation-specifics do become important in this > discussion. >=20 > > Well, we disagree. :-) What does everyone else > > think? >=20 > Yes, at this point, it'd be good to get feedback > from > others on the spec approach. My last email > summarizes > the tactical approach I intend to take for the next > draft revision. >=20 > Thanks. >=20 > Mallikarjun >=20 >=20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 21 18:49:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpDiZ-0004si-3N; Wed, 21 Dec 2005 18:49:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpDiX-0004sd-Ta for ips@megatron.ietf.org; Wed, 21 Dec 2005 18:49:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28794 for ; Wed, 21 Dec 2005 18:48:52 -0500 (EST) From: pat.thaler@avagotech.com Received: from msgbas9x.lvld.agilent.com ([192.25.144.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpDlG-0003Lj-7p for ips@ietf.org; Wed, 21 Dec 2005 18:52:46 -0500 Received-SPF: none (msgbas9x.lvld.agilent.com: domain of pat.thaler@avagotech.com does not designate permitted sender hosts) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas9x.lvld.agilent.com (Postfix) with ESMTP id 177F15D for ; Wed, 21 Dec 2005 16:49:36 -0700 (MST) Received: from wcosvs03.cos.agilent.com (wcosvs03.cos.agilent.com [130.29.152.233]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 963E3CBC for ; Wed, 21 Dec 2005 16:49:35 -0700 (MST) Received: from wcosbh03.cos.agilent.com ([130.29.152.128]) by wcosvs03.cos.agilent.com with InterScan Messaging Security Suite; Wed, 21 Dec 2005 16:49:35 -0700 Received: from wcosmb08.cos.agilent.com ([130.29.152.129]) by wcosbh03.cos.agilent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Dec 2005 16:49:34 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Dec 2005 16:49:33 -0700 Message-ID: <78C934D0E1A588449B46F68346FB76C7334B38@wcosmb08.cos.agilent.com> Thread-Topic: mib document is "not found" Thread-Index: AcYGhCg8xFULK+T2SFSw6s/9rQOaJgABKbrw To: X-OriginalArrivalTime: 21 Dec 2005 23:49:34.0627 (UTC) FILETIME=[32076730:01C60689] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Subject: [Ips] mib document is "not found" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I got the following announcement but when I go to download the document, = it the website says it is not found. I got the same behavior when I used = the link in the message and when I went in through the internet-drafts = data base interface entry. Pat --------------------------------------------------------------------- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = Internet-Drafts@ietf.org Sent: Wednesday, December 21, 2005 12:50 PM To: i-d-announce@ietf.org Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-scsi-mib-08.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definition of Managed Objects for SCSI Entities Author(s) : M. Hallak, et al. Filename : draft-ietf-ips-scsi-mib-08.txt Pages : 95 Date : 2005-12-21 =09 This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-08.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Dec 23 09:00:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpnTI-0007oi-AW; Fri, 23 Dec 2005 09:00:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek69O-00047b-DU for ips@megatron.ietf.org; Wed, 07 Dec 2005 15:44:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24427 for ; Wed, 7 Dec 2005 15:43:37 -0500 (EST) Received: from webmail2.silverbacksystems.com ([65.172.158.65] helo=silverbacksystems.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek6V5-0006sr-Ng for ips@ietf.org; Wed, 07 Dec 2005 16:06:59 -0500 Received: from [10.0.16.116] (account sgupta@silverbacksystems.com) by silverbacksystems.com (CommuniGate Pro IMAP 4.3.7) with XMIT id 530794 for ips@ietf.org; Wed, 07 Dec 2005 12:43:55 -0800 Subject: RE: [Ips] Fast multi-task abort model Date: Wed, 07 Dec 2005 12:43:54 -0800 Message-Id: <2ad37449fcea8441a349deeddd843927@mail2.silverbacksystems.com> In-Reply-To: <20051206231258.16013.qmail@web51915.mail.yahoo.com> MIME-Version: 1.0 Thread-Topic: [Ips] Fast multi-task abort model Priority: Normal Importance: normal X-MSMail-Priority: normal X-Priority: 3 Sensitivity: Normal Thread-Index: AcX7bvAMROhmDBJHQ0CNiBJcoKxd+Q== From: "Somesh Gupta" To: "IPS" X-MAPI-LastModified: Wed, 07 Dec 2005 12:43:54 -0800 X-Mailer: CommuniGate Pro MAPI Connector 1.1.21/1.1.25(local) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 23 Dec 2005 09:00:33 -0500 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The discussion prompted me to take a closer look at the fast multi-task abort model. In principal, I agree that the new async PDU helps the target and initiator reach a common understanding of which tasks have been cleared, and stop processing them. However, I think the language of the proposal puts too much knowledge in the target transport layer - the language implies that the target transport layer is managing the task set for a LUN - it is responsible for determining which initiators have active tasks on a specific LUN, and which tasks these are, what their disposition is - and for sending a TMF response (and which TMFs are supported and what the back-end impact of each is). It is not so simple since the values of the TAS, TST and Qerr bits really determine the actions. There is some unavoidable interaction/modification of the SCSI layer to handle this situation correctly - because only the SCSI layer knows whether for the cleared tasks a. the initiator is really not expecting anything (the nexus is the same as which received the tmf command) b. should be sent an explicit status of ABORTED BY ANOTHER INITIATOR c. No impact d. Needs to be cleaned up through the asynch notification mechanism (different nexus, TST=3D0:Qerr=3D01b;TAS=3D0) c. Whether the initiator is likely to be dead (LUN Reset with reserve/release model or equivalent behavior in persistent reservation model) In other words, the asynch PDU must be explicitly triggered by the SCSI layer on each impacted Nexus - if adding the asynch PDU becomes an issues, we can use a new response code which would be sent for every command. In any case, the statsn acknowledgement rule should help the initiator and target flush all impacted commands in the pipe, and have a common understanding of what is impacted. Bill makes a very valid point about the real world situation of clusters. Shouldn't the SCSI layer be able to send a response for the TMF when it has triggered the asynch PDU on each of the Nexuses (is it Nexi?). The acknowledgement or time-out is only for the purposes of recovering the buffers? >-----Original Message----- >From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On >Behalf Of Mallikarjun C. >Sent: Tuesday, December 06, 2005 3:13 PM >To: IPS >Subject: Re: [Ips] Fast multi-task abort model > > >>Mark >> the tcb as >> terminated, then wait for the TTs to complete. When >> they are done, >> throw the whole thing out. > >Reasonable, and this is in abstract what the new >proposal does. > >RFC 3720 does not explicitly say "wait for TTTs to >complete even after TMF is completed". The only >default interpretation of the 3720 text today would be >to invalidate the TTTs along with the buffer >associations when a task is "terminated" and the TMF >completion is generated. An invalid TTT/STag is in >fact a problem for at least two reasons - > >a) All Data-Out PDU (with the now invalid TTTs) are >protocol errors that should be Reject'ed. >b) Any DDP tagged data segment to an invalid STag >immediately takes the connection down (for >iSCSI/iSER). > >What I am suggesting in the new proposal is that there >be an explicit event to conclude the "waiting for TTTs >to complete" for a target at the iSCSI control >protocol level (not at the Datamover level). That new >event is the reception of the Nop-Out ack'ing the new >Async PDU. And that brings us to the new proposal. > >I think the 3720 text is self-consistent (although it >isn't the most efficient). Simply scratching the TTT >cross-nexus requirement off the current text, IMHO, is >not the right thing. We need to specify the new >initiator and target semantics in the absence of that >requirement, and that's what the fast multi-task abort >proposal attempts. > >Mallikarjun > > > > >--- William Studenmund >wrote: > >> On Dec 1, 2005, at 4:01 PM, Mallikarjun C. wrote: >> >> >> Why does it need to be cross-nexus, other than >> the >> >> fact that RFC 3720 >> >> says it should be? >> > >> > There's a good rationale behind RFC 3720 text: >> > >> > TMF cannot complete until all affected tasks are >> > terminated on the target per SAM. Receiving stale >> > data after tasks are terminated is a problem. >> Waiting >> > for all active TTTs of all affected tasks (same >> and/or >> > other nexus) to finish was thus the adopted >> approach >> > to avoid stale data for any affected task. >> >> Shouldn't we leave how the target avoids/copes with >> stale data to the >> target? >> >> I guess I don't see how receiving "stale" data after >> a task has been >> terminated is a problem. Specifically I don't see >> how it's a problem to >> receive data you knew was in-flight at the moment >> the termination >> happened. You have your tcb structure (however you >> have it laid out), >> and you know what TTs are associated with it. Mark >> the tcb as >> terminated, then wait for the TTs to complete. When >> they are done, >> throw the whole thing out. >> >> > What the new proposal does is to make receiving >> stale >> > data after task terminations a non-problem - via a >> > separate accounting scheme and new target >> semantics. >> >> And I think this is a good thing. However I still >> think we need to >> abandon the inter-nexus TT wait for the old scheme. >> >> Take care, >> >> Bill >> >> > > > > >__________________________________________ >Yahoo! DSL - Something to write home about. >Just $16.99/mo. or less. >dsl.yahoo.com > > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Dec 27 09:13:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErFaP-000053-9C; Tue, 27 Dec 2005 09:13:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErFaN-0008VX-8r for ips@megatron.ietf.org; Tue, 27 Dec 2005 09:13:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22635 for ; Tue, 27 Dec 2005 09:12:45 -0500 (EST) From: Black_David@emc.com Received: from [168.159.213.201] (helo=mailhub.lss.emc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErFds-0005kU-Fg for ips@ietf.org; Tue, 27 Dec 2005 09:17:54 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id jBRECb9u006060; Tue, 27 Dec 2005 09:12:48 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Dec 2005 09:12:35 -0500 Message-ID: To: pat.thaler@avagotech.com, ips@ietf.org Subject: RE: [Ips] mib document is "not found" Date: Tue, 27 Dec 2005 09:12:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.12.27.10 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Pat, Thanks for noticing this - it's been corrected, and the secretariat gets extra credit for reposting the document on Christmas Eve. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist 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 ---------------------------------------------------- > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of pat.thaler@avagotech.com > Sent: Wednesday, December 21, 2005 6:50 PM > To: ips@ietf.org > Subject: [Ips] mib document is "not found" > > I got the following announcement but when I go to download > the document, it the website says it is not found. I got the > same behavior when I used the link in the message and when I > went in through the internet-drafts data base interface entry. > Pat > > --------------------------------------------------------------------- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, December 21, 2005 12:50 PM > To: i-d-announce@ietf.org > Cc: ips@ietf.org > Subject: [Ips] I-D ACTION:draft-ietf-ips-scsi-mib-08.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the IP Storage Working Group of the IETF. > > Title : Definition of Managed Objects for > SCSI Entities > Author(s) : M. Hallak, et al. > Filename : draft-ietf-ips-scsi-mib-08.txt > Pages : 95 > Date : 2005-12-21 > > This memo defines a portion of the Management Information Base (MIB), > for use with network management protocols in the Internet > community. > In particular it describes managed objects for Small > Computer System > Interface (SCSI) entities, independently of the interconnect > subsystem layer. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-08.txt > > To remove yourself from the I-D Announcement list, send a > message to i-d-announce-request@ietf.org with the word > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips