From exim@www1.ietf.org Thu Jan 1 17:44:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24674 for ; Thu, 1 Jan 2004 17:44:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcBXr-0004bz-SK for ips-archive@odin.ietf.org; Thu, 01 Jan 2004 17:44:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i01MhxRp017723 for ips-archive@odin.ietf.org; Thu, 1 Jan 2004 17:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcBXr-0004bm-MH for ips-web-archive@optimus.ietf.org; Thu, 01 Jan 2004 17:43:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24647 for ; Thu, 1 Jan 2004 17:43:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcBXp-0007kd-00 for ips-web-archive@ietf.org; Thu, 01 Jan 2004 17:43:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcBVt-0007fY-00 for ips-web-archive@ietf.org; Thu, 01 Jan 2004 17:42:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcBUK-0007d4-00 for ips-web-archive@ietf.org; Thu, 01 Jan 2004 17:40:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcBU3-0004TB-UW; Thu, 01 Jan 2004 17:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcBTw-0004SM-Gz for ips@optimus.ietf.org; Thu, 01 Jan 2004 17:39:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24558 for ; Thu, 1 Jan 2004 17:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcBTu-0007bp-00 for ips@ietf.org; Thu, 01 Jan 2004 17:39:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcBS0-0007a3-00 for ips@ietf.org; Thu, 01 Jan 2004 17:37:59 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AcBQX-0007Xj-00 for ips@ietf.org; Thu, 01 Jan 2004 17:36:25 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (sccrmhc13) with SMTP id <200401012235550160097ipqe> (Authid: esquicksall); Thu, 1 Jan 2004 22:35:55 +0000 Message-ID: <001201c3d0b7$9f619170$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Cc: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> <003801c3c66b$81c53050$3d33b142@ivvt2dxrc11> <005401c3ca9b$842cb550$0303a8c0@ivvt2dxrc11> Subject: Re: [Ips] iSCSI: a Reject during text negotiations Date: Thu, 1 Jan 2004 17:35:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In the example below, are you saying the first task is still active and the initiator should send an empty text request with F=1 to allow the target to send F=1 and the MaxRecvDataSegmentLength given by the first task should be accepted by the target? I.e., the reset (as indicated by Reject in section 5.4) only effects the second task? Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Monday, December 29, 2003 1:26 PM Subject: Re: [Ips] iSCSI: a Reject during text negotiations > On Wed, 24 Dec 2003, Eddy Quicksall wrote: > > > I think this was cleared up by Julian on Dec 22 around 1AM (no subject). > > > > Yes, it makes sense and I don't think I ever said anything that debated > > that. > > > > My question is based on 10.10 saying: > > > > An initiator MUST have at most one outstanding Text Request on a > > connection at any given time. > > > > I think this means only one "task" can be outstanding and I think the "at a > > given time" means "until the target responds with the F bit set to 1". > > > > So, if that is the case, the ITT can't change until the target responds with > > the F bit set to 1. > > Eddie, you are talking about an invariant of a task, the ITT, changing. > Invariants don't change; that's the point of an invariant. :-) > > > My question further asked if a reject is given to an ITT that changed before > > F==1 (a second "outstanding Text Request") then is the original ITT reset? > > And the answer was [yes] because "reset is reset". > > > > So, in my original example given below, MaxRecvDataSegmentLength will not > > have changed at the target. > > Yes, but for a different reason. :-) > > It won't have changed because the first Text Negotiation task is still > active. > > While I agree the second PDU should get a reject, since it's a different > ITT, it's a different task. Since it's a different task, I don't see why > it getting killed for a reject should impact the first. > > > -- snip -- > > I->T MaxRecvDataSegmentLength=512, F=0 > > T->I F=0 > > I->T (changed the ITT) F=1 > > T->I Reject > > > > Finally, are you saying that more than one task can be outstanding at the > > target before the target sets F==1? If so, we may have something to debate. > > No, I'm saying that since the second PDU had a different had a different > ITT, the target should have started up a second text nego task. Said task > should have noticed that there already was a text nego task and thus > aborted itself. > > Take care, > > 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 exim@www1.ietf.org Fri Jan 2 14:23:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19313 for ; Fri, 2 Jan 2004 14:23:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUtP-0003sk-Qt for ips-archive@odin.ietf.org; Fri, 02 Jan 2004 14:23:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02JNV5r014916 for ips-archive@odin.ietf.org; Fri, 2 Jan 2004 14:23:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUtP-0003sV-L1 for ips-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 14:23:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19292 for ; Fri, 2 Jan 2004 14:23:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcUtI-00073Z-00 for ips-web-archive@ietf.org; Fri, 02 Jan 2004 14:23:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcUnO-0006o3-00 for ips-web-archive@ietf.org; Fri, 02 Jan 2004 14:17:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcUid-0006ad-00 for ips-web-archive@ietf.org; Fri, 02 Jan 2004 14:12:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUiG-0003Zf-Lw; Fri, 02 Jan 2004 14:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcUhO-0003VE-B2 for ips@optimus.ietf.org; Fri, 02 Jan 2004 14:11:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19074 for ; Fri, 2 Jan 2004 14:10:58 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcUhB-0006XK-00 for ips@ietf.org; Fri, 02 Jan 2004 14:10:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcUbj-0006J8-00 for ips@ietf.org; Fri, 02 Jan 2004 14:05:18 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AcUWL-000663-00 for ips@ietf.org; Fri, 02 Jan 2004 13:59:41 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 4DFA040135; Fri, 2 Jan 2004 13:59:40 -0500 (EST) Date: Fri, 2 Jan 2004 10:55:36 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations In-Reply-To: <001201c3d0b7$9f619170$0303a8c0@ivvt2dxrc11> Message-ID: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> <003801c3c66b$81c53050$3d33b142@ivvt2dxrc11> <005401c3ca9b$842cb550$0303a8c0@ivvt2dxrc11> <001201c3d0b7$9f619170$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , On Thu, 1 Jan 2004, Eddy Quicksall wrote: > In the example below, are you saying the first task is still active and the > initiator should send an empty text request with F=1 to allow the target to > send F=1 and the MaxRecvDataSegmentLength given by the first task should be > accepted by the target? > > I.e., the reset (as indicated by Reject in section 5.4) only effects the > second task? Yes. Different ITT == different task. As I understand Reject, there is no reason it should function on more than one ITT. So the reject shouldn't touch the first task (first ITT). Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 2 18:23:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29382 for ; Fri, 2 Jan 2004 18:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcYd8-0002cS-GA for ips-archive@odin.ietf.org; Fri, 02 Jan 2004 18:22:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02NMwf8010065 for ips-archive@odin.ietf.org; Fri, 2 Jan 2004 18:22:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcYd7-0002cG-Uu for ips-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 18:22:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29334 for ; Fri, 2 Jan 2004 18:22:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcYd4-00033c-00 for ips-web-archive@ietf.org; Fri, 02 Jan 2004 18:22:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcYbu-0002qk-00 for ips-web-archive@ietf.org; Fri, 02 Jan 2004 18:21:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcYXQ-0002f3-00 for ips-web-archive@ietf.org; Fri, 02 Jan 2004 18:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcYWQ-0002Ly-7p; Fri, 02 Jan 2004 18:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcYVQ-0002Ki-QL for ips@optimus.ietf.org; Fri, 02 Jan 2004 18:15:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28937 for ; Fri, 2 Jan 2004 18:14:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcYVD-0002YE-00 for ips@ietf.org; Fri, 02 Jan 2004 18:14:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcYRx-0002QI-00 for ips@ietf.org; Fri, 02 Jan 2004 18:11:26 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AcYPG-0002I3-00 for ips@ietf.org; Fri, 02 Jan 2004 18:08:38 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (sccrmhc13) with SMTP id <2004010223074301600elm5je> (Authid: esquicksall); Fri, 2 Jan 2004 23:07:44 +0000 Message-ID: <001001c3d185$3cdc1e20$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Julian Satran" Cc: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> <003801c3c66b$81c53050$3d33b142@ivvt2dxrc11> <005401c3ca9b$842cb550$0303a8c0@ivvt2dxrc11> <001201c3d0b7$9f619170$0303a8c0@ivvt2dxrc11> Subject: Re: [Ips] iSCSI: a Reject during text negotiations Date: Fri, 2 Jan 2004 18:07:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Julian, Could I have misunderstood you? This interpretation seems to make sense. Here is the example: I->T, ITT=x, TTT=FFFFFFFF, MaxRecvDataSegmentLength=512, F=0 T->I, ITT=x, TTT=00000001, F=0 I->T, ITT=y, TTT=FFFFFFFF, F=1 T->I Reject (MaxRecvDataSegmentLength not changed yet) I->T, ITT=x, TTT=00000001, F=1 T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512) Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Friday, January 02, 2004 1:55 PM Subject: Re: [Ips] iSCSI: a Reject during text negotiations > On Thu, 1 Jan 2004, Eddy Quicksall wrote: > > > In the example [above], are you saying the first task is still active and the > > initiator should send an empty text request with F=1 to allow the target to > > send F=1 and the MaxRecvDataSegmentLength given by the first task should be > > accepted by the target? > > > > I.e., the reset (as indicated by Reject in section 5.4) only effects the > > second task? > > Yes. > > Different ITT == different task. > > As I understand Reject, there is no reason it should function on more than > one ITT. So the reject shouldn't touch the first task (first ITT). > > Take care, > > 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 exim@www1.ietf.org Fri Jan 2 22:08:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04609 for ; Fri, 2 Jan 2004 22:08:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acc9A-0000Kd-GI for ips-archive@odin.ietf.org; Fri, 02 Jan 2004 22:08:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0338G8h001269 for ips-archive@odin.ietf.org; Fri, 2 Jan 2004 22:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acc9A-0000KO-AN for ips-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 22:08:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04601 for ; Fri, 2 Jan 2004 22:08:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acc92-0003h0-00 for ips-web-archive@ietf.org; Fri, 02 Jan 2004 22:08:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Acc5C-0003cP-00 for ips-web-archive@ietf.org; Fri, 02 Jan 2004 22:04:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Acc3S-0003Wf-00 for ips-web-archive@ietf.org; Fri, 02 Jan 2004 22:02:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acc37-0008IT-VZ; Fri, 02 Jan 2004 22:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acc2V-0008IC-R6 for ips@optimus.ietf.org; Fri, 02 Jan 2004 22:01:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04494 for ; Fri, 2 Jan 2004 22:01:17 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acc2L-0003WM-00 for ips@ietf.org; Fri, 02 Jan 2004 22:01:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcbzT-0003Sr-00 for ips@ietf.org; Fri, 02 Jan 2004 21:58:16 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Acbxu-0003Q6-00 for ips@ietf.org; Fri, 02 Jan 2004 21:56:38 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id D1EB440135; Fri, 2 Jan 2004 21:56:37 -0500 (EST) Date: Fri, 2 Jan 2004 18:52:31 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: Julian Satran , ips@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations In-Reply-To: <001001c3d185$3cdc1e20$0303a8c0@ivvt2dxrc11> Message-ID: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> <003801c3c66b$81c53050$3d33b142@ivvt2dxrc11> <005401c3ca9b$842cb550$0303a8c0@ivvt2dxrc11> <001201c3d0b7$9f619170$0303a8c0@ivvt2dxrc11> <001001c3d185$3cdc1e20$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Fri, 2 Jan 2004, Eddy Quicksall wrote: > Julian, > > Could I have misunderstood you? This interpretation seems to make sense. > > Here is the example: > > I->T, ITT=x, TTT=FFFFFFFF, MaxRecvDataSegmentLength=512, F=0 > T->I, ITT=x, TTT=00000001, F=0 > I->T, ITT=y, TTT=FFFFFFFF, F=1 > T->I Reject (MaxRecvDataSegmentLength not changed yet) > I->T, ITT=x, TTT=00000001, F=1 > T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512) I think what Julian meant was that while that analysis (above) is correct, that other targets may have the incorrect understanding we started the thread with. Thus that if an initiator gets such a reject, it should realize things are quite wrong and be defensive about it. Killing the other text task would be defensive. Of course, there shouldn't have been a second text task. So either the initiator is bad, or there has been some breakdown of communication between them. For the latter, I think session reinstatement would be the right thing to do. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Jan 4 05:19:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21860 for ; Sun, 4 Jan 2004 05:19:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ad5LM-0005bn-Jz for ips-archive@odin.ietf.org; Sun, 04 Jan 2004 05:18:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i04AImIS021560 for ips-archive@odin.ietf.org; Sun, 4 Jan 2004 05:18:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ad5LL-0005bf-1w for ips-web-archive@optimus.ietf.org; Sun, 04 Jan 2004 05:18:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21848 for ; Sun, 4 Jan 2004 05:18:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ad5LH-0003qT-00 for ips-web-archive@ietf.org; Sun, 04 Jan 2004 05:18:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ad5JQ-0003nZ-00 for ips-web-archive@ietf.org; Sun, 04 Jan 2004 05:16:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ad5Hs-0003kn-00 for ips-web-archive@ietf.org; Sun, 04 Jan 2004 05:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ad5Hi-0005Qc-Ub; Sun, 04 Jan 2004 05:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ad5HT-0005Q1-D1 for ips@optimus.ietf.org; Sun, 04 Jan 2004 05:14:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21766 for ; Sun, 4 Jan 2004 05:14:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ad5HP-0003jD-00 for ips@ietf.org; Sun, 04 Jan 2004 05:14:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ad5FU-0003ff-00 for ips@ietf.org; Sun, 04 Jan 2004 05:12:45 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1Ad5DH-0003ZX-00 for ips@ietf.org; Sun, 04 Jan 2004 05:10:27 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i04A8ejB090308; Sun, 4 Jan 2004 10:08:40 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i04A8ccn205436; Sun, 4 Jan 2004 11:08:39 +0100 In-Reply-To: <001001c3d185$3cdc1e20$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Sun, 4 Jan 2004 12:08:35 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 04/01/2004 12:08:38, Serialize complete at 04/01/2004 12:08:38 Content-Type: multipart/alternative; boundary="=_alternative 001FC5B4C2256E11_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 001FC5B4C2256E11_= Content-Type: text/plain; charset="US-ASCII" Eddy, The sequence is valid. On the other hand since the initiator missbehaves (has two outstanding text requests) the target may choose (and still be compliant) to completely reset the session etc. Julo "Eddy Quicksall" 03/01/2004 01:07 To Julian Satran/Haifa/IBM@IBMIL cc Subject Re: [Ips] iSCSI: a Reject during text negotiations Julian, Could I have misunderstood you? This interpretation seems to make sense. Here is the example: I->T, ITT=x, TTT=FFFFFFFF, MaxRecvDataSegmentLength=512, F=0 T->I, ITT=x, TTT=00000001, F=0 I->T, ITT=y, TTT=FFFFFFFF, F=1 T->I Reject (MaxRecvDataSegmentLength not changed yet) I->T, ITT=x, TTT=00000001, F=1 T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512) Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Friday, January 02, 2004 1:55 PM Subject: Re: [Ips] iSCSI: a Reject during text negotiations > On Thu, 1 Jan 2004, Eddy Quicksall wrote: > > > In the example [above], are you saying the first task is still active and the > > initiator should send an empty text request with F=1 to allow the target to > > send F=1 and the MaxRecvDataSegmentLength given by the first task should be > > accepted by the target? > > > > I.e., the reset (as indicated by Reject in section 5.4) only effects the > > second task? > > Yes. > > Different ITT == different task. > > As I understand Reject, there is no reason it should function on more than > one ITT. So the reject shouldn't touch the first task (first ITT). > > Take care, > > Bill > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 001FC5B4C2256E11_= Content-Type: text/html; charset="US-ASCII"
Eddy,

The sequence is valid.
On the other hand since the initiator missbehaves (has two outstanding text requests) the target may choose (and still be compliant) to completely reset the session etc.

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

03/01/2004 01:07

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
Re: [Ips] iSCSI: a Reject during text negotiations





Julian,

Could I have misunderstood you? This interpretation seems to make sense.

Here is the example:

I->T, ITT=x, TTT=FFFFFFFF, MaxRecvDataSegmentLength=512, F=0
T->I, ITT=x, TTT=00000001, F=0
I->T, ITT=y, TTT=FFFFFFFF, F=1
T->I Reject (MaxRecvDataSegmentLength not changed yet)
I->T, ITT=x, TTT=00000001, F=1
T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512)

Eddy

----- Original Message -----
From: <wrstuden@wasabisystems.com>
To: "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@Comcast.net>
Cc: <ips@ietf.org>
Sent: Friday, January 02, 2004 1:55 PM
Subject: Re: [Ips] iSCSI: a Reject during text negotiations


> On Thu, 1 Jan 2004, Eddy Quicksall wrote:
>
> > In the example [above], are you saying the first task is still active
and the
> > initiator should send an empty text request with F=1 to allow the target
to
> > send F=1 and the MaxRecvDataSegmentLength given by the first task should
be
> > accepted by the target?
> >
> > I.e., the reset (as indicated by Reject in section 5.4) only effects the
> > second task?
>
> Yes.
>
> Different ITT == different task.
>
> As I understand Reject, there is no reason it should function on more than
> one ITT. So the reject shouldn't touch the first task (first ITT).
>
> Take care,
>
> Bill
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 001FC5B4C2256E11_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Jan 5 15:48:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03221 for ; Mon, 5 Jan 2004 15:48:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbdV-0003v6-Kx for ips-archive@odin.ietf.org; Mon, 05 Jan 2004 15:47:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05Klfha015062 for ips-archive@odin.ietf.org; Mon, 5 Jan 2004 15:47:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbdV-0003ur-FX for ips-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 15:47:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03116 for ; Mon, 5 Jan 2004 15:47:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbdU-0004vb-00 for ips-web-archive@ietf.org; Mon, 05 Jan 2004 15:47:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbbO-0004la-00 for ips-web-archive@ietf.org; Mon, 05 Jan 2004 15:45:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adba3-0004gy-00 for ips-web-archive@ietf.org; Mon, 05 Jan 2004 15:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbZx-0003kb-J1; Mon, 05 Jan 2004 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbZH-0003k0-4v for ips@optimus.ietf.org; Mon, 05 Jan 2004 15:43:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02963 for ; Mon, 5 Jan 2004 15:43:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbZF-0004dz-00 for ips@ietf.org; Mon, 05 Jan 2004 15:43:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbXJ-0004X4-00 for ips@ietf.org; Mon, 05 Jan 2004 15:41:17 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1AdbVN-0004NF-00 for ips@ietf.org; Mon, 05 Jan 2004 15:39:17 -0500 Received: from rosemail.rose.hp.com (postal.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 53A731C019DD; Mon, 5 Jan 2004 15:39:17 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bdj233.rose.hp.com [15.23.139.233]) by rosemail.rose.hp.com (Postfix) with ESMTP id AB4687FFE; Mon, 5 Jan 2004 12:36:30 -0800 (PST) Message-ID: <3FF9CB6C.3020502@rose.hp.com> Date: Mon, 05 Jan 2004 12:39:08 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Satran Cc: Eddy Quicksall , ips@ietf.org Subject: Re: [Ips] iSCSI: connection reinstatement References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Julian Satran wrote: > > > ips-admin@ietf.org wrote on 13/12/2003 15:53:12: > > > If I have only one connection in a session and the logout is for only > > the connection, is 5.3.4 and 10.14 (9th paragraph) saying that the > > initiator can: > > > > 1) logout the connection only (on a single connection session) > > 2) later log in using the same ISID-TSIH-CID combination to re-instate > > the connection? > > > Yes - although if no tasks are outstanding ... > > If so, how long does the target need to keep the session information? > > > Time2Retain Technically, the required duration is (Time2Wait+Time2Retain) - eventhough both Time2Wait and Time2Retain can each be negotiated/specified to be zeroes. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Jan 5 19:46:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16171 for ; Mon, 5 Jan 2004 19:46:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfLi-0006zk-0U for ips-archive@odin.ietf.org; Mon, 05 Jan 2004 19:45:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i060jXRV026882 for ips-archive@odin.ietf.org; Mon, 5 Jan 2004 19:45:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfLh-0006zV-Rd for ips-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 19:45:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16139 for ; Mon, 5 Jan 2004 19:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdfLf-0006Qc-00 for ips-web-archive@ietf.org; Mon, 05 Jan 2004 19:45:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfJr-0006JV-00 for ips-web-archive@ietf.org; Mon, 05 Jan 2004 19:43:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdfIJ-0006BZ-00 for ips-web-archive@ietf.org; Mon, 05 Jan 2004 19:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfII-0006ll-Dd; Mon, 05 Jan 2004 19:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdfIC-0006kv-KU for ips@optimus.ietf.org; Mon, 05 Jan 2004 19:41:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15960 for ; Mon, 5 Jan 2004 19:41:53 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdfIA-0006AU-00 for ips@ietf.org; Mon, 05 Jan 2004 19:41:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfGO-00061a-00 for ips@ietf.org; Mon, 05 Jan 2004 19:40:05 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AdfF4-0005p5-00 for ips@ietf.org; Mon, 05 Jan 2004 19:38:42 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 6BA4640134; Mon, 5 Jan 2004 19:38:42 -0500 (EST) Date: Mon, 5 Jan 2004 16:34:36 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: ips@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ips] Open-source iSNS implementation Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Anyone know of an open source iSNS implementation that is at iSNS draft 21? I found the source-forge one, but it's stuck at draft 5. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 6 04:21:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11715 for ; Tue, 6 Jan 2004 04:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnOd-0001ac-Ii for ips-archive@odin.ietf.org; Tue, 06 Jan 2004 04:21:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i069L7RC006111 for ips-archive@odin.ietf.org; Tue, 6 Jan 2004 04:21:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnOc-0001aU-Sa for ips-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 04:21:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11709 for ; Tue, 6 Jan 2004 04:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdnOV-0002N8-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 04:20:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdnKY-0002Fp-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 04:16:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdnHK-000297-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 04:13:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnGn-0001BN-AB; Tue, 06 Jan 2004 04:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnGS-0001An-7v for ips@optimus.ietf.org; Tue, 06 Jan 2004 04:12:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11590 for ; Tue, 6 Jan 2004 04:12:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdnGI-00028A-00 for ips@ietf.org; Tue, 06 Jan 2004 04:12:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdnDb-00024j-00 for ips@ietf.org; Tue, 06 Jan 2004 04:09:43 -0500 Received: from web42005.mail.yahoo.com ([66.218.93.173]) by ietf-mx with smtp (Exim 4.12) id 1AdnBQ-00020M-00 for ips@ietf.org; Tue, 06 Jan 2004 04:07:28 -0500 Message-ID: <20040106090626.99712.qmail@web42005.mail.yahoo.com> Received: from [66.134.241.90] by web42005.mail.yahoo.com via HTTP; Tue, 06 Jan 2004 01:06:26 PST Date: Tue, 6 Jan 2004 01:06:26 -0800 (PST) From: Alberto Alesina To: ips@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1764836330-1073379986=:97698" Subject: [Ips] iSCSI PDU multiple TCP segments Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --0-1764836330-1073379986=:97698 Content-Type: text/plain; charset=us-ascii Hello all, I would appreciate if someone can answer my questions on iSCSI - Can a iSCSI PDU span over multiple TCP segments ? (part of the iSCSI PDU in one TCP segment, remaining part in other TCP segments) - If that is allowed, do the existent initiator implementations try to send an iSCSI PDU in the same TCP segement? Thanks a lot for your time. Regards, Alberto Alesina --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1764836330-1073379986=:97698 Content-Type: text/html; charset=us-ascii
Hello all,
 
I would appreciate if someone can answer my questions on iSCSI
 
- Can a iSCSI PDU span over multiple TCP segments ? (part of the iSCSI PDU in one TCP segment, remaining part in other TCP segments)
 
- If that is allowed, do the existent initiator implementations try to send an iSCSI PDU in the same TCP segement?
 
Thanks a lot for your time.
 
Regards,
Alberto Alesina

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1764836330-1073379986=:97698-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 6 06:27:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14722 for ; Tue, 6 Jan 2004 06:27:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdpMw-0005r1-AK for ips-archive@odin.ietf.org; Tue, 06 Jan 2004 06:27:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06BRUJh022499 for ips-archive@odin.ietf.org; Tue, 6 Jan 2004 06:27:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdpMw-0005qo-3V for ips-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 06:27:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14665 for ; Tue, 6 Jan 2004 06:27:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdpMs-0007DU-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 06:27:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdpHt-00074m-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 06:22:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdpF1-0006wf-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 06:19:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdpEj-0005b0-AS; Tue, 06 Jan 2004 06:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdpE8-0005ZY-8O for ips@optimus.ietf.org; Tue, 06 Jan 2004 06:18:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14539 for ; Tue, 6 Jan 2004 06:18:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdpDu-0006wA-00 for ips@ietf.org; Tue, 06 Jan 2004 06:18:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdpBK-0006rA-00 for ips@ietf.org; Tue, 06 Jan 2004 06:15:31 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1Adp7V-0006lV-00 for ips@ietf.org; Tue, 06 Jan 2004 06:11:33 -0500 Received: from [192.168.7.101] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1Adp5c-0002ub-00 for ips@ietf.org; Tue, 06 Jan 2004 11:09:36 +0000 From: "Ken Sandars" To: Subject: [Ips] iSCSI: Recovery R2T Usage Date: Tue, 6 Jan 2004 11:10:14 -0000 Message-ID: <001001c3d445$bdf75200$6507a8c0@winminx> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Happy New Year, one and all! Does a 'recovery R2T' count against the negotiated limit of MaxOutstandingR2T? For example, say MaxOutstandingR2T=1, and this sequence occurs: 1 I->T SCSI Command WRITE 128KB (no unsolicited data) 2 T->I R2T offset=0, len=128KB, R2TSN=0 3 I->T DATA-OUT offset=0 len=32KB DataSN=0 4 I->T DATA-OUT offset=32KB len=32KB DataSN=1 (a) T->T R2T offset=32KB len=32KB R2TSN=1 5 I->T DATA-OUT offset=64KB len=32KB DataSN=2 6 I->T DATA-OUT offset=96KB len=32KB DataSN=3 F=1 (b) T->T R2T offset=32KB len=32KB R2TSN=1 Can the target send a recovery R2T at the time it detects the DD failure, i.e. at point (a), or must it wait until the current outstanding R2T is serviced, i.e. until point (b)? Thanks, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 6 09:32:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19305 for ; Tue, 6 Jan 2004 09:32:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsFD-0003HJ-MY for ips-archive@odin.ietf.org; Tue, 06 Jan 2004 09:31:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06EVhY9012602 for ips-archive@odin.ietf.org; Tue, 6 Jan 2004 09:31:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsFD-0003H8-Db for ips-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 09:31:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19230 for ; Tue, 6 Jan 2004 09:31:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsFB-0007A0-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 09:31:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdsDI-00070o-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 09:29:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AdsBT-0006qP-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 09:27:52 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AdsBM-0002Ie-MG for ips-web-archive@ietf.org; Tue, 06 Jan 2004 09:27:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsAf-0002jc-Kd; Tue, 06 Jan 2004 09:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ads9w-0002jE-5a for ips@optimus.ietf.org; Tue, 06 Jan 2004 09:26:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18951 for ; Tue, 6 Jan 2004 09:26:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ads9k-0006lO-00 for ips@ietf.org; Tue, 06 Jan 2004 09:26:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ads4u-0006bP-00 for ips@ietf.org; Tue, 06 Jan 2004 09:21:05 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1AdrzV-0006NS-00; Tue, 06 Jan 2004 09:15:29 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i06EDXpS090264; Tue, 6 Jan 2004 14:13:33 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i06EDWQK182712; Tue, 6 Jan 2004 15:13:32 +0100 In-Reply-To: <001001c3d445$bdf75200$6507a8c0@winminx> To: "Ken Sandars" Cc: ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] iSCSI: Recovery R2T Usage MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 6 Jan 2004 16:13:31 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 06/01/2004 16:13:32, Serialize complete at 06/01/2004 16:13:32 Content-Type: multipart/alternative; boundary="=_alternative 004BF177C2256E13_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 004BF177C2256E13_= Content-Type: text/plain; charset="US-ASCII" Ken, The basic idea beyond the recovery R2T is that the initiator does not have to process it in any way special (except perhaps that it may get back in the sequence ordering). If the initiator stated that it can handle a single R2T the target MUST not send the recovery R2T until (b). Julo "Ken Sandars" Sent by: ips-admin@ietf.org 06/01/2004 13:10 To cc Subject [Ips] iSCSI: Recovery R2T Usage Happy New Year, one and all! Does a 'recovery R2T' count against the negotiated limit of MaxOutstandingR2T? For example, say MaxOutstandingR2T=1, and this sequence occurs: 1 I->T SCSI Command WRITE 128KB (no unsolicited data) 2 T->I R2T offset=0, len=128KB, R2TSN=0 3 I->T DATA-OUT offset=0 len=32KB DataSN=0 4 I->T DATA-OUT offset=32KB len=32KB DataSN=1 (a) T->T R2T offset=32KB len=32KB R2TSN=1 5 I->T DATA-OUT offset=64KB len=32KB DataSN=2 6 I->T DATA-OUT offset=96KB len=32KB DataSN=3 F=1 (b) T->T R2T offset=32KB len=32KB R2TSN=1 Can the target send a recovery R2T at the time it detects the DD failure, i.e. at point (a), or must it wait until the current outstanding R2T is serviced, i.e. until point (b)? Thanks, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 004BF177C2256E13_= Content-Type: text/html; charset="US-ASCII"
Ken,

The basic idea beyond the recovery R2T is that the initiator does not have to process it in any way special (except perhaps that it may get back in the sequence ordering).
If the initiator stated that it can handle a single R2T the target MUST not send the recovery R2T until (b).

Julo




"Ken Sandars" <ksandars@elipsan.com>
Sent by: ips-admin@ietf.org

06/01/2004 13:10

To
<ips@ietf.org>
cc
Subject
[Ips] iSCSI: Recovery R2T Usage





Happy New Year, one and all!

Does a 'recovery R2T' count against the negotiated limit of
MaxOutstandingR2T?

For example, say MaxOutstandingR2T=1, and this sequence occurs:

1 I->T SCSI Command WRITE 128KB (no unsolicited data)
2 T->I R2T offset=0, len=128KB, R2TSN=0
3 I->T DATA-OUT offset=0 len=32KB DataSN=0
4 I->T DATA-OUT offset=32KB len=32KB DataSN=1 <BAD data digest>

(a) T->T R2T offset=32KB len=32KB R2TSN=1

5 I->T DATA-OUT offset=64KB len=32KB DataSN=2
6 I->T DATA-OUT offset=96KB len=32KB DataSN=3 F=1

(b) T->T R2T offset=32KB len=32KB R2TSN=1


Can the target send a recovery R2T at the time it detects the DD
failure, i.e. at point (a), or must it wait until the current
outstanding R2T is serviced, i.e. until point (b)?



Thanks,
Ken Sandars
Elipsan UK



_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 004BF177C2256E13_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 6 09:34:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19425 for ; Tue, 6 Jan 2004 09:34:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsHH-0003Lk-5I for ips-archive@odin.ietf.org; Tue, 06 Jan 2004 09:33:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06EXpuP012870 for ips-archive@odin.ietf.org; Tue, 6 Jan 2004 09:33:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsHH-0003LV-04 for ips-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 09:33:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19386 for ; Tue, 6 Jan 2004 09:33:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsHF-0007Jm-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 09:33:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdsFb-0007Eh-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 09:32:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AdsEk-00077q-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 09:31:14 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AdsEd-0002dB-8H for ips-web-archive@ietf.org; Tue, 06 Jan 2004 09:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsEY-00039t-PM; Tue, 06 Jan 2004 09:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdsDd-00037B-Lm for ips@optimus.ietf.org; Tue, 06 Jan 2004 09:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19153 for ; Tue, 6 Jan 2004 09:30:02 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdsDb-000731-00 for ips@ietf.org; Tue, 06 Jan 2004 09:30:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdsBh-0006tX-00 for ips@ietf.org; Tue, 06 Jan 2004 09:28:06 -0500 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1Ads7l-0006g9-00 for ips@ietf.org; Tue, 06 Jan 2004 09:24:01 -0500 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jan 2004 09:23:05 -0500 Message-ID: To: aalesina@yahoo.com, ips@ietf.org Subject: RE: [Ips] iSCSI PDU multiple TCP segments Date: Tue, 6 Jan 2004 09:23:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 > I would appreciate if someone can answer my questions on iSCSI > > - Can a iSCSI PDU span over multiple TCP segments ? (part of the iSCSI > PDU in one TCP segment, remaining part in other TCP segments) Yes. Data transfers are a common case, as even the common 4k or 8k transfers are larger than the typical TCP segment size, and iSCSI is capable of supporting much larger transfers. > - If that is allowed, do the existent initiator implementations try > to send an iSCSI PDU in the same TCP segement? In general, I don't believe they make any special efforts over and above what TCP normally does. 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 exim@www1.ietf.org Tue Jan 6 10:56:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23047 for ; Tue, 6 Jan 2004 10:56:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdtYa-0006di-Mc for ips-archive@odin.ietf.org; Tue, 06 Jan 2004 10:55:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06Ftm2U025518 for ips-archive@odin.ietf.org; Tue, 6 Jan 2004 10:55:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdtYa-0006dV-Gb for ips-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 10:55:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23014 for ; Tue, 6 Jan 2004 10:55:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdtYY-0002oA-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 10:55:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdtWg-0002jx-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 10:53:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdtUx-0002ft-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 10:52:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdtUv-0006Tr-Ht; Tue, 06 Jan 2004 10:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdtUm-0006TS-1m for ips@optimus.ietf.org; Tue, 06 Jan 2004 10:51:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22927 for ; Tue, 6 Jan 2004 10:51:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdtUj-0002eF-00 for ips@ietf.org; Tue, 06 Jan 2004 10:51:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdtSr-0002aU-00 for ips@ietf.org; Tue, 06 Jan 2004 10:49:55 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AdtSJ-0002WO-00 for ips@ietf.org; Tue, 06 Jan 2004 10:49:19 -0500 Received: from [192.168.7.101] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1AdtQx-0005kW-00; Tue, 06 Jan 2004 15:47:55 +0000 From: "Ken Sandars" To: "'Julian Satran'" Cc: Subject: RE: [Ips] iSCSI: Recovery R2T Usage Date: Tue, 6 Jan 2004 15:48:34 -0000 Message-ID: <002801c3d46c$9f7ef540$6507a8c0@winminx> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C3D46C.9F7EF540" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C3D46C.9F7EF540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Julo, That sounds fair, but what happens when pdu 6 in the same example is lost due to header corruption instead? If the target is classy enough to run a receive sequence timer for the command, this will pop. But it cannot send a recovery R2T can it? In fact, generalising this, what can the target do when a command's receive sequence timer pops and no more R2T's can be sent? Any initiator developers out there got any thoughts on this? Thanks again, Ken -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: 06 January 2004 14:14 To: Ken Sandars Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] iSCSI: Recovery R2T Usage Ken, The basic idea beyond the recovery R2T is that the initiator does not have to process it in any way special (except perhaps that it may get back in the sequence ordering). If the initiator stated that it can handle a single R2T the target MUST not send the recovery R2T until (b). Julo "Ken Sandars" Sent by: ips-admin@ietf.org 06/01/2004 13:10 To cc Subject [Ips] iSCSI: Recovery R2T Usage Happy New Year, one and all! Does a 'recovery R2T' count against the negotiated limit of MaxOutstandingR2T? For example, say MaxOutstandingR2T=1, and this sequence occurs: 1 I->T SCSI Command WRITE 128KB (no unsolicited data) 2 T->I R2T offset=0, len=128KB, R2TSN=0 3 I->T DATA-OUT offset=0 len=32KB DataSN=0 4 I->T DATA-OUT offset=32KB len=32KB DataSN=1 (a) T->T R2T offset=32KB len=32KB R2TSN=1 5 I->T DATA-OUT offset=64KB len=32KB DataSN=2 6 I->T DATA-OUT offset=96KB len=32KB DataSN=3 F=1 (b) T->T R2T offset=32KB len=32KB R2TSN=1 Can the target send a recovery R2T at the time it detects the DD failure, i.e. at point (a), or must it wait until the current outstanding R2T is serviced, i.e. until point (b)? Thanks, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0029_01C3D46C.9F7EF540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Thanks=20 Julo,
 
That=20 sounds fair, but what happens when pdu 6 in the same example is lost due = to=20 header corruption instead?
 
If the=20 target is classy enough to run a receive sequence timer for the command, = this=20 will pop. But it cannot send a recovery R2T can it? In fact, = generalising this,=20 what can the target do when a command's receive sequence timer = pops=20 and no more R2T's can be sent?
 
Any=20 initiator developers out there got any thoughts on = this?
 
 
Thanks=20 again,
Ken
 
-----Original Message-----
From: = Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: 06 January 2004=20 14:14
To: Ken Sandars
Cc: ips@ietf.org;=20 ips-admin@ietf.org
Subject: Re: [Ips] iSCSI: Recovery R2T=20 Usage


Ken,=20

The basic idea beyond the = recovery R2T is=20 that the initiator does not have to process it in any way special = (except=20 perhaps that it may get back in the sequence ordering). =
If the initiator stated that it can handle = a single R2T=20 the target MUST not send the recovery R2T until (b). =

Julo




"Ken = Sandars"=20 <ksandars@elipsan.com>
Sent by: ips-admin@ietf.org=20

06/01/2004 13:10

To
<ips@ietf.org>=20
cc
Subject
[Ips] = iSCSI: Recovery=20 R2T Usage

=




Happy New Year, one and all!

Does a 'recovery R2T' = count=20 against the negotiated limit of
MaxOutstandingR2T?

For = example, say=20 MaxOutstandingR2T=3D1, and this sequence occurs:

1 I->T SCSI = Command=20 WRITE 128KB (no unsolicited data)
2 T->I R2T offset=3D0, = len=3D128KB,=20 R2TSN=3D0
3 I->T DATA-OUT offset=3D0 len=3D32KB DataSN=3D0
4 = I->T DATA-OUT=20 offset=3D32KB len=3D32KB DataSN=3D1 <BAD data digest>

(a) = T->T R2T=20 offset=3D32KB len=3D32KB R2TSN=3D1

5 I->T DATA-OUT = offset=3D64KB len=3D32KB=20 DataSN=3D2
6 I->T DATA-OUT offset=3D96KB len=3D32KB DataSN=3D3 = F=3D1

(b)=20 T->T R2T offset=3D32KB len=3D32KB R2TSN=3D1


Can the = target send a=20 recovery R2T at the time it detects the DD
failure, i.e. at point = (a), or=20 must it wait until the current
outstanding R2T is serviced, i.e. = until=20 point (b)?



Thanks,
Ken Sandars
Elipsan=20 = UK



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

------=_NextPart_000_0029_01C3D46C.9F7EF540-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 6 11:44:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24540 for ; Tue, 6 Jan 2004 11:44:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduJ2-0008K3-2l for ips-archive@odin.ietf.org; Tue, 06 Jan 2004 11:43:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06GhmqE031985 for ips-archive@odin.ietf.org; Tue, 6 Jan 2004 11:43:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduJ1-0008Jm-SE for ips-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 11:43:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24503 for ; Tue, 6 Jan 2004 11:43:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AduJ0-0004Ts-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 11:43:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AduH9-0004PX-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 11:41:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AduFV-0004LB-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 11:40:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduFQ-000882-UG; Tue, 06 Jan 2004 11:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AduF6-00086d-PC for ips@optimus.ietf.org; Tue, 06 Jan 2004 11:39:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24414 for ; Tue, 6 Jan 2004 11:39:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AduF5-0004J5-00 for ips@ietf.org; Tue, 06 Jan 2004 11:39:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AduDG-0004FY-00 for ips@ietf.org; Tue, 06 Jan 2004 11:37:51 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1AduBZ-00047b-00 for ips@ietf.org; Tue, 06 Jan 2004 11:36:05 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i06GZSHK022754; Tue, 6 Jan 2004 16:35:28 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i06GZQrq256758; Tue, 6 Jan 2004 17:35:28 +0100 In-Reply-To: <002801c3d46c$9f7ef540$6507a8c0@winminx> To: "Ken Sandars" Cc: ips@ietf.org Subject: RE: [Ips] iSCSI: Recovery R2T Usage MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 6 Jan 2004 18:35:24 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 06/01/2004 18:35:28, Serialize complete at 06/01/2004 18:35:28 Content-Type: multipart/alternative; boundary="=_alternative 005AC9C2C2256E13_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 005AC9C2C2256E13_= Content-Type: text/plain; charset="US-ASCII" Timer should do it. The target doesn't have any other choice than either pop-up the error at the SCSI level or send an R2T (that may be discarded by the initiator if the R2T is still pending). Julo "Ken Sandars" 06/01/2004 17:48 To Julian Satran/Haifa/IBM@IBMIL cc Subject RE: [Ips] iSCSI: Recovery R2T Usage Thanks Julo, That sounds fair, but what happens when pdu 6 in the same example is lost due to header corruption instead? If the target is classy enough to run a receive sequence timer for the command, this will pop. But it cannot send a recovery R2T can it? In fact, generalising this, what can the target do when a command's receive sequence timer pops and no more R2T's can be sent? Any initiator developers out there got any thoughts on this? Thanks again, Ken -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: 06 January 2004 14:14 To: Ken Sandars Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] iSCSI: Recovery R2T Usage Ken, The basic idea beyond the recovery R2T is that the initiator does not have to process it in any way special (except perhaps that it may get back in the sequence ordering). If the initiator stated that it can handle a single R2T the target MUST not send the recovery R2T until (b). Julo "Ken Sandars" Sent by: ips-admin@ietf.org 06/01/2004 13:10 To cc Subject [Ips] iSCSI: Recovery R2T Usage Happy New Year, one and all! Does a 'recovery R2T' count against the negotiated limit of MaxOutstandingR2T? For example, say MaxOutstandingR2T=1, and this sequence occurs: 1 I->T SCSI Command WRITE 128KB (no unsolicited data) 2 T->I R2T offset=0, len=128KB, R2TSN=0 3 I->T DATA-OUT offset=0 len=32KB DataSN=0 4 I->T DATA-OUT offset=32KB len=32KB DataSN=1 (a) T->T R2T offset=32KB len=32KB R2TSN=1 5 I->T DATA-OUT offset=64KB len=32KB DataSN=2 6 I->T DATA-OUT offset=96KB len=32KB DataSN=3 F=1 (b) T->T R2T offset=32KB len=32KB R2TSN=1 Can the target send a recovery R2T at the time it detects the DD failure, i.e. at point (a), or must it wait until the current outstanding R2T is serviced, i.e. until point (b)? Thanks, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005AC9C2C2256E13_= Content-Type: text/html; charset="US-ASCII"
Timer should do it. The target doesn't have any other choice than either pop-up the error at the SCSI level or send an R2T (that may be discarded by the initiator if the R2T is still pending).

Julo


"Ken Sandars" <ksandars@elipsan.com>

06/01/2004 17:48

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
RE: [Ips] iSCSI: Recovery R2T Usage





Thanks Julo,
 
That sounds fair, but what happens when pdu 6 in the same example is lost due to header corruption instead?
 
If the target is classy enough to run a receive sequence timer for the command, this will pop. But it cannot send a recovery R2T can it? In fact, generalising this, what can the target do when a command's receive sequence timer pops and no more R2T's can be sent?
 
Any initiator developers out there got any thoughts on this?
 
 
Thanks again,
Ken
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: 06 January 2004 14:14
To: Ken Sandars
Cc: ips@ietf.org; ips-admin@ietf.org
Subject: Re: [Ips] iSCSI: Recovery R2T Usage

Ken,

The basic idea beyond the recovery R2T is that the initiator does not have to process it in any way special (except perhaps that it may get back in the sequence ordering).
If the initiator stated that it can handle a single R2T the target MUST not send the recovery R2T until (b).

Julo



"Ken Sandars" <ksandars@elipsan.com>
Sent by: ips-admin@ietf.org

06/01/2004 13:10


To
<ips@ietf.org>
cc
Subject
[Ips] iSCSI: Recovery R2T Usage







Happy New Year, one and all!

Does a 'recovery R2T' count against the negotiated limit of
MaxOutstandingR2T?

For example, say MaxOutstandingR2T=1, and this sequence occurs:

1 I->T SCSI Command WRITE 128KB (no unsolicited data)
2 T->I R2T offset=0, len=128KB, R2TSN=0
3 I->T DATA-OUT offset=0 len=32KB DataSN=0
4 I->T DATA-OUT offset=32KB len=32KB DataSN=1 <BAD data digest>

(a) T->T R2T offset=32KB len=32KB R2TSN=1

5 I->T DATA-OUT offset=64KB len=32KB DataSN=2
6 I->T DATA-OUT offset=96KB len=32KB DataSN=3 F=1

(b) T->T R2T offset=32KB len=32KB R2TSN=1


Can the target send a recovery R2T at the time it detects the DD
failure, i.e. at point (a), or must it wait until the current
outstanding R2T is serviced, i.e. until point (b)?



Thanks,
Ken Sandars
Elipsan UK



_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 005AC9C2C2256E13_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 6 16:28:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04749 for ; Tue, 6 Jan 2004 16:28:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adyju-0002Qt-7A for ips-archive@odin.ietf.org; Tue, 06 Jan 2004 16:27:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06LRoxr009351 for ips-archive@odin.ietf.org; Tue, 6 Jan 2004 16:27:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adyju-0002Qk-2x for ips-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 16:27:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04744 for ; Tue, 6 Jan 2004 16:27:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adyjs-0001Uv-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 16:27:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adyi7-0001Rn-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 16:26:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdyhJ-0001Nc-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 16:25:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyhC-0002Gg-0m; Tue, 06 Jan 2004 16:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyUV-0001eC-Pp for ips@optimus.ietf.org; Tue, 06 Jan 2004 16:11:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03900 for ; Tue, 6 Jan 2004 16:11:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyUO-0000aV-00 for ips@ietf.org; Tue, 06 Jan 2004 16:11:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdyPI-0000RA-00 for ips@ietf.org; Tue, 06 Jan 2004 16:06:35 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1AdyLl-0000IZ-00 for ips@ietf.org; Tue, 06 Jan 2004 16:02:53 -0500 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i06L1sKw005873 for ; Tue, 6 Jan 2004 13:01:58 -0800 (PST) Received: from svlexc02.hq.netapp.com (svlexc02.corp.netapp.com [10.57.157.136]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i06L1kST017080 for ; Tue, 6 Jan 2004 13:01:54 -0800 (PST) Received: from rtpexc03.hq.netapp.com ([10.60.4.50]) by svlexc02.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 Jan 2004 13:01:50 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D498.4D026168" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 6 Jan 2004 16:01:48 -0500 Message-ID: <3A62517F5A8AFE4098ADDBD25B5D4D5C015B50@rtpexc03.hq.netapp.com> Thread-Topic: iSCSI: When does a connection become part of a session? Thread-Index: AcPUmEsjy2TINHlVROqKXun0ZMGGpg== From: "Pittman, Joseph" To: X-OriginalArrivalTime: 06 Jan 2004 21:01:50.0124 (UTC) FILETIME=[4DC2DEC0:01C3D498] Subject: [Ips] iSCSI: When does a connection become part of a session? Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3D498.4D026168 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm working on adding support for multi-connection sessions to an iSCSI target implementation, and I have some questions about when a new connection is considered to be part of a session. =20 Consider this set of login request/response exchanges. Assume that there already exists a session with ISID=3D1/TSIH=3D2 on the target, so the initiator is trying to add a connection to an existing session. The session is operating at ErrorRecoveryLevel=3D2, and there already exists a connection with CID=3D3 within that session, so connection reinstatement is required. =20 Initiator sends Target responds ------------------------- -------------------------- Exchange 0 LOGIN_REQ LOGIN_RESP ISID=3D1, TSIH=3D2, CID=3D3 ISID=3D1, = TSIH=3D2, CID=3D3 CSG=3D0, T=3D0 CSG=3D0, T=3D0 AuthMethod=3DCHAP AuthMethod=3DCHAP =20 ** Connection now in SecurityNegotiation phase =20 Exchange 1 LOGIN_REQ LOGIN_RESP ISID=3D1, TSIH=3D2, CID=3D3 ISID=3D1, = TSIH=3D2, CID=3D3 CSG=3D0, T=3D0 CSG=3D0, T=3D0 CHAP_A=3D5 CHAP_A=3D5 CHAP_I=3Dx CHAP_C=3Dx =20 Exchange 2 LOGIN_REQ LOGIN_RESP ISID=3D1, TSIH=3D2, CID=3D3 ISID=3D1, = TSIH=3D2, CID=3D3 CSG=3D0, T=3D1, NSG=3D1 CSG=3D0, = T=3D1, NSG=3D1 CHAP_R=3Dx CHAP_N=3Dx =20 ** Connection now in LoginOperationalNegotiation phase =20 Exchange 3 LOGIN_REQ ISID=3D1, TSIH=3D2, CID=3D3 ISID=3D1, = TSIH=3D2, CID=3D3 CSG=3D1, T=3D1, NSG=3D3 CSG=3D1, = T=3D1, NSG=3D3 MaxRecvDSegLen=3Dxxx = MaxRecvDSegLen=3Dxxx =20 ** Connection now in FullFeaturePhase phase ** Connection has been added to the session ISID=3D1/TSIH=3D2 ** Previous connection ISID=3D1/TSIH=3D2/CID=3D3 has been logged out = for recovery =20 =20 Given this example, here are a few questions: =20 1) When is the target supposed to consider the connection as part of the session, for the purposes of the response ExpCmdSN and MaxCmdSN fields? =20 In general, the ExpCmdSN and MaxCmdSN fields contain information about the current command window for a session. But when does the target consider the connection to be part the session: =20 - Before security negotiation is complete? If true, then this tells a spoofing initiator (who will eventually fail authentication) about the presence of a connection by the initiator being spoofed =20 - After security negotiation is complete? =20 - Only in the last login response/transition to FFP? =20 My inclination is to only consider the connection to be part of the connection when it has successfully completed the entire login sequence, and thus to return the joined session's ExpCmdSN and MaxCmdSN only in the last login response. =20 2) When is the target supposed to perform the connection reinstatement algorithm, including the implicit logout for recovery of the existing ISID=3D1/TSIH=3D2/CID=3D3 connection? =20 - Before security negotiation is complete? Surely not, because this allows a denial of service attack. =20 - After security negotiation is complete? =20 - Just before sending the last login response/transition to FFP? =20 My inclination is to only consider the connection to be part of the connection when it has successfully completed the entire login sequence, and thus do connection reinstatement just prior to sending the last login response. =20 3) Here's a more esoteric question: if the login sequence for one connection ISID=3D1/TSIH=3D2/CID=3D3 is still in LoginOpNegotiation = stage, and the initiator starts another connection with the same ISID/TSIH/CID, what is the target supposed to do? Does 'connection reinstatement' apply also to a connection which is not yet in FFP? =20 My inclination is for the target to consider the second login request as spurious, and to return NotEnoughResources (since I am unwilling to dedicate two 'new connection' slots to the same ISID/TSIH/CID combination). =20 I cannot find any text in the iSCSI spec that unambiguously addresses these issues. Am I missing anything? If not, would any of the authors care to give guidance? =20 Thanks in advance for any help. -- Joe Pittman jpittman@netapp.com =20 =20 ------_=_NextPart_001_01C3D498.4D026168 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I'm working on adding support = for=20 multi-connection sessions to an
iSCSI target implementation, and I = have some=20 questions about when
a new connection is considered to be part of=20 a session.
 
Consider this set of login = request/response=20 exchanges.  Assume
that there already exists a session with=20 ISID=3D1/TSIH=3D2 on the
target, so the initiator is trying to add a = connection=20 to an
existing session.  The session is operating at=20 ErrorRecoveryLevel=3D2,
and there already exists a connection with = CID=3D3 within=20 that
session, so connection reinstatement is required.
 
          &nbs= p;      =20 Initiator=20 sends           &n= bsp;      =20 Target=20 responds
          &= nbsp;      =20 -------------------------        = =20 --------------------------
Exchange=20 0       =20 LOGIN_REQ          &nbs= p;            = ; =20 LOGIN_RESP
          = ;       =20 ISID=3D1, TSIH=3D2,=20 CID=3D3           =  =20 ISID=3D1, TSIH=3D2,=20 CID=3D3
          &n= bsp;      =20 CSG=3D0,=20 T=3D0           &n= bsp;           =20 CSG=3D0,=20 T=3D0
          &nbs= p;      =20 AuthMethod=3DCHAP         &n= bsp;        =20 AuthMethod=3DCHAP
 
  ** Connection now in=20 SecurityNegotiation phase
 
Exchange=20 1       =20 LOGIN_REQ          &nbs= p;            = ; =20 LOGIN_RESP
          = ;       =20 ISID=3D1, TSIH=3D2,=20 CID=3D3           =  =20 ISID=3D1, TSIH=3D2,=20 CID=3D3
          &n= bsp;      =20 CSG=3D0,=20 T=3D0           &n= bsp;           =20 CSG=3D0,=20 T=3D0
          &nbs= p;      =20 CHAP_A=3D5          &nb= sp;           &nbs= p;  =20 CHAP_A=3D5
          = ;            =             &= nbsp;           &n= bsp;    =20 CHAP_I=3Dx
          = ;            =             &= nbsp;           &n= bsp;    =20 CHAP_C=3Dx
 
Exchange=20 2       =20 LOGIN_REQ          &nbs= p;            = ; =20 LOGIN_RESP
          = ;       =20 ISID=3D1, TSIH=3D2,=20 CID=3D3           =  =20 ISID=3D1, TSIH=3D2,=20 CID=3D3
          &n= bsp;      =20 CSG=3D0, T=3D1,=20 NSG=3D1           =      =20 CSG=3D0, T=3D1,=20 NSG=3D1
          &n= bsp;      =20 CHAP_R=3Dx
          = ;       =20 CHAP_N=3Dx
 
  ** Connection now in=20 LoginOperationalNegotiation phase
 

Exchange=20 3       =20 LOGIN_REQ
          =        =20 ISID=3D1, TSIH=3D2,=20 CID=3D3           =  =20 ISID=3D1, TSIH=3D2,=20 CID=3D3
          &n= bsp;      =20 CSG=3D1, T=3D1,=20 NSG=3D3           =      =20 CSG=3D1, T=3D1,=20 NSG=3D3
          &n= bsp;      =20 MaxRecvDSegLen=3Dxxx         = ;      =20 MaxRecvDSegLen=3Dxxx
 
  ** Connection now in=20 FullFeaturePhase phase
  ** Connection has been added to the = session=20 ISID=3D1/TSIH=3D2
  ** Previous connection = ISID=3D1/TSIH=3D2/CID=3D3 has been=20 logged out for
     recovery
 
 
Given this example, here are a = few=20 questions:
 
1) When is the target supposed = to consider=20 the connection as part of
   the session, for the purposes = of the=20 response ExpCmdSN and MaxCmdSN
   fields?
 
   In general, the = ExpCmdSN and=20 MaxCmdSN fields contain information
   about the current = command=20 window for a session.  But when does the
   target = consider=20 the connection to be part the session:
 
   - Before security = negotiation=20 is complete?  If true, then this
     tells = a=20 spoofing initiator (who will eventually fail=20 authentication)
     about the presence of a = connection=20 by the initiator being spoofed
 
   - After security = negotiation=20 is complete?
 
   - Only in the last = login=20 response/transition to FFP?
 
   My inclination is = to only=20 consider the connection to be part of the
   connection = when it has=20 successfully completed the entire login
   sequence, and = thus to=20 return the joined session's ExpCmdSN and
   = MaxCmdSN only in the last login = response.
 

2) When is the target = supposed to=20 perform the connection reinstatement
   algorithm, = including the=20 implicit logout for recovery of the
   existing = ISID=3D1/TSIH=3D2/CID=3D3=20 connection?
 
   - Before security = negotiation=20 is complete?  Surely not, because
     this = allows a=20 denial of service attack.
 
   - After security = negotiation=20 is complete?
 
   - Just before = sending the last=20 login response/transition to FFP?
 
   My inclination is = to only=20 consider the connection to be part of the
   connection = when it has=20 successfully completed the entire login
   sequence, and = thus do=20 connection reinstatement just prior to sending
   the last = login=20 response.
 
3) Here's a more esoteric = question: if the=20 login sequence for one
   connection = ISID=3D1/TSIH=3D2/CID=3D3 is still=20 in LoginOpNegotiation stage,
   and the initiator starts = another=20 connection with the same
   ISID/TSIH/CID, what is the = target=20 supposed to do?  Does 'connection
   reinstatement' = apply also=20 to a connection which is not yet in FFP?
 
   My inclination is = for the=20 target to consider the second login
   request as spurious, = and to=20 return NotEnoughResources (since I
   am unwilling to = dedicate two=20 'new connection' slots to the same
   ISID/TSIH/CID=20 combination).
 

I cannot find any text in = the iSCSI=20 spec that unambiguously addresses
these issues.  Am I missing=20 anything?  If not, would any of the
authors care to give = guidance?
 
Thanks in advance for any=20 help.
--
Joe Pittman
jpittman@netapp.com
 
=00 ------_=_NextPart_001_01C3D498.4D026168-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 6 18:58:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10807 for ; Tue, 6 Jan 2004 18:58:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae154-000074-Cq for ips-archive@odin.ietf.org; Tue, 06 Jan 2004 18:57:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06Nvo4b000434 for ips-archive@odin.ietf.org; Tue, 6 Jan 2004 18:57:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae154-00006v-4E for ips-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 18:57:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10776 for ; Tue, 6 Jan 2004 18:57:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae150-0007PB-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 18:57:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae13C-0007LY-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 18:55:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ae11T-0007Hb-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 18:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae11O-0008NY-78; Tue, 06 Jan 2004 18:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae11L-0008Mx-0C for ips@optimus.ietf.org; Tue, 06 Jan 2004 18:53:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10586 for ; Tue, 6 Jan 2004 18:53:53 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae11H-0007G2-00 for ips@ietf.org; Tue, 06 Jan 2004 18:53:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae0zS-0007C2-00 for ips@ietf.org; Tue, 06 Jan 2004 18:52:05 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ae0y7-000779-00 for ips@ietf.org; Tue, 06 Jan 2004 18:50:39 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id BAE976D80; Tue, 6 Jan 2004 16:50:33 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 8938733C; Tue, 6 Jan 2004 16:50:33 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2004 16:50:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D4AF.DF4A73AF" Subject: RE: [Ips] iSCSI: When does a connection become part of a session? Date: Tue, 6 Jan 2004 16:50:32 -0700 Message-ID: Thread-Topic: iSCSI: When does a connection become part of a session? Thread-Index: AcPUmEsjy2TINHlVROqKXun0ZMGGpgADDWxw To: , X-OriginalArrivalTime: 06 Jan 2004 23:50:33.0372 (UTC) FILETIME=[DFAFEDC0:01C3D4AF] Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3D4AF.DF4A73AF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe, =20 You raise interesting questions. For the first two items, I think I = agree that your inclinations are sensible though not necessarily = supported in the iSCSI draft. On the third one, I'm not sure.=20 =20 On 1 - treatment of MaxCmdSN and ExpCmdSN during login, it would make = sense to withhold valid values for these fields at least until the = security phase of Login has completed and there doesn't seem to be any = reason to provide them before the last login. However, I don't find = anything in the spec that supports doing this. Under the description of = status class for Login Response, it says=20 The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if = Status-Class is 0. which implies that the fields are valid when Status-Class is 0 including = during the security phase. On 2 - at what point in a connection reinstatement login does the old = connection get closed, 5.3.4 The Login request performs the logout function of the old connection if = an explicit logout was not performed earlier. which appears to indicate that it is the reception of the initial Login = Request PDU that causes the logout. As you suggest, actually operating = this way would leave one vulnerable to denial of service type attacks. = It makes more sense to wait until at least security phase has completed = to do the logout. It may make sense to wait to do close the old = connection until ready to send the final login response as you suggest = because this login may not succeed. However for resource constrained = implementations the reinstated connection may need resources allocated = to the existing connection. The state machine description might be hoped to provide more detail, but = they don't seem to be entirely consistant. The definition in 7.1.2 for = T8, (T13 and T18 have similar text) -target: An internal event of sending a Logout response (success) on = another connection for a "close the session" Logout request was = received, or an internal event of a successful connection/session = reinstatement is received, thus prompting the target to close this = connection cleanly. "Successful connection/session reinstatement" might be read to mean that = the login for the new session successfully completed rather than just a = login request was received. However note that a failed connection = reinstatement causes T15 which moves the session from LOGGED_IN to = CLEANUP_WAIT so a failed attempt would still disrupt an active = connection. There doesn't seem to be any definition provided for = successful and failed connection reinstatement. In the description of = connection cleanup state transitions (7.2.2, M4) successful implicit = logout appears to be defined as having reached the state LOGGED_IN on = the new connection. On 3, I think connection reinstatement only applies to a connection = that has completed login. The state transitions for the target = connection state machine only allow for implicit logout in the LOGGED_IN = state and in the states that follow it. The transition from IN_LOGIN to = FREE, T4, doesn't make any mention of implicit logout or connection = reinstatement. Time out or the transport going away are the things that = get you from IN_LOGIN to FREE. One might get a second login attempt if = there was a problem on the initial connection such as the network going = down but it is probably okay to not accept it until the original attempt = has disappeared due to time out or closure of the transport connection. = Lack of resources would be a reasonable response. If one does have the = resources, I'm not sure it is a necessary response.=20 Regards, Pat -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of = Pittman, Joseph Sent: Tuesday, January 06, 2004 1:02 PM To: ips@ietf.org Subject: [Ips] iSCSI: When does a connection become part of a session? I'm working on adding support for multi-connection sessions to an iSCSI target implementation, and I have some questions about when a new connection is considered to be part of a session. =20 Consider this set of login request/response exchanges. Assume that there already exists a session with ISID=3D1/TSIH=3D2 on the target, so the initiator is trying to add a connection to an existing session. The session is operating at ErrorRecoveryLevel=3D2, and there already exists a connection with CID=3D3 within that session, so connection reinstatement is required. =20 Initiator sends Target responds ------------------------- = -------------------------- Exchange 0 LOGIN_REQ LOGIN_RESP ISID=3D1, TSIH=3D2, CID=3D3 ISID=3D1, = TSIH=3D2, CID=3D3 CSG=3D0, T=3D0 CSG=3D0, T=3D0 AuthMethod=3DCHAP AuthMethod=3DCHAP =20 ** Connection now in SecurityNegotiation phase =20 Exchange 1 LOGIN_REQ LOGIN_RESP ISID=3D1, TSIH=3D2, CID=3D3 ISID=3D1, = TSIH=3D2, CID=3D3 CSG=3D0, T=3D0 CSG=3D0, T=3D0 CHAP_A=3D5 CHAP_A=3D5 CHAP_I=3Dx CHAP_C=3Dx =20 Exchange 2 LOGIN_REQ LOGIN_RESP ISID=3D1, TSIH=3D2, CID=3D3 ISID=3D1, = TSIH=3D2, CID=3D3 CSG=3D0, T=3D1, NSG=3D1 CSG=3D0, = T=3D1, NSG=3D1 CHAP_R=3Dx CHAP_N=3Dx =20 ** Connection now in LoginOperationalNegotiation phase =20 Exchange 3 LOGIN_REQ ISID=3D1, TSIH=3D2, CID=3D3 ISID=3D1, = TSIH=3D2, CID=3D3 CSG=3D1, T=3D1, NSG=3D3 CSG=3D1, = T=3D1, NSG=3D3 MaxRecvDSegLen=3Dxxx = MaxRecvDSegLen=3Dxxx =20 ** Connection now in FullFeaturePhase phase ** Connection has been added to the session ISID=3D1/TSIH=3D2 ** Previous connection ISID=3D1/TSIH=3D2/CID=3D3 has been logged out = for recovery =20 =20 Given this example, here are a few questions: =20 1) When is the target supposed to consider the connection as part of the session, for the purposes of the response ExpCmdSN and MaxCmdSN fields? =20 In general, the ExpCmdSN and MaxCmdSN fields contain information about the current command window for a session. But when does the target consider the connection to be part the session: =20 - Before security negotiation is complete? If true, then this tells a spoofing initiator (who will eventually fail = authentication) about the presence of a connection by the initiator being spoofed =20 - After security negotiation is complete? =20 - Only in the last login response/transition to FFP? =20 My inclination is to only consider the connection to be part of the connection when it has successfully completed the entire login sequence, and thus to return the joined session's ExpCmdSN and MaxCmdSN only in the last login response. =20 2) When is the target supposed to perform the connection reinstatement algorithm, including the implicit logout for recovery of the existing ISID=3D1/TSIH=3D2/CID=3D3 connection? =20 - Before security negotiation is complete? Surely not, because this allows a denial of service attack. =20 - After security negotiation is complete? =20 - Just before sending the last login response/transition to FFP? =20 My inclination is to only consider the connection to be part of the connection when it has successfully completed the entire login sequence, and thus do connection reinstatement just prior to sending the last login response. =20 3) Here's a more esoteric question: if the login sequence for one connection ISID=3D1/TSIH=3D2/CID=3D3 is still in LoginOpNegotiation = stage, and the initiator starts another connection with the same ISID/TSIH/CID, what is the target supposed to do? Does 'connection reinstatement' apply also to a connection which is not yet in FFP? =20 My inclination is for the target to consider the second login request as spurious, and to return NotEnoughResources (since I am unwilling to dedicate two 'new connection' slots to the same ISID/TSIH/CID combination). =20 I cannot find any text in the iSCSI spec that unambiguously addresses these issues. Am I missing anything? If not, would any of the authors care to give guidance? =20 Thanks in advance for any help. -- Joe Pittman jpittman@netapp.com =20 ------_=_NextPart_001_01C3D4AF.DF4A73AF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Joe,
 
You = raise=20 interesting questions. For the first two items, I think I agree that = your=20 inclinations are sensible though not necessarily supported in the iSCSI = draft.=20 On the third one, I'm not sure.
 
On 1 - = treatment of=20 MaxCmdSN and ExpCmdSN during login, it would make sense to withhold = valid values=20 for these fields at least until the security phase of Login has = completed and=20 there doesn't seem to be any reason to provide them before the last = login.=20 However, I don't find anything in the spec that supports doing = this.  Under=20 the description of status class for Login Response, it says

The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) = are only=20 valid if Status-Class is 0.

which=20 implies that the fields are valid when Status-Class is 0 including = during the=20 security phase.

On 2 - at=20 what point in a connection reinstatement login does the old = connection get=20 closed,  5.3.4

The Login request = performs the logout function of the old connection=20 if an explicit logout was not performed = earlier.

which=20 appears to indicate that it is the reception of the initial Login = Request PDU=20 that causes the logout. As you suggest, actually operating this way = would leave=20 one vulnerable to denial of service type attacks. It makes more sense to = wait=20 until at least security phase has completed to do the logout. It may = make sense=20 to wait to do close the old connection until ready to send the final = login=20 response as you suggest because this login may not succeed. However for = resource=20 constrained implementations the reinstated connection may need resources = allocated to the existing connection.

The state=20 machine description might be hoped to provide more detail, but they = don't seem=20 to be entirely consistant. The definition in 7.1.2 for T8, (T13 and = T18=20 have similar text)

-target: An internal event = of sending a=20 Logout response (success) on = another=20 connection for a "close the session"=20 Logout request was received, or an internal event of a successful connection/session = reinstatement is=20 received, thus prompting the = target to=20 close this connection cleanly.

"Successful=20 connection/session reinstatement" might be read to mean that the login = for the=20 new session successfully completed rather than just a login request was=20 received. However note that a failed connection reinstatement causes T15 = which=20 moves the session from LOGGED_IN to CLEANUP_WAIT so a failed attempt = would still=20 disrupt an active connection. There doesn't seem to be any definition = provided=20 for successful and failed connection reinstatement. In the description = of=20 connection cleanup state transitions (7.2.2, M4) successful implicit = logout=20 appears to be defined as having reached the state LOGGED_IN on the new=20 connection.

 On 3, I think connection reinstatement only applies = to a=20 connection that has completed login. The state transitions for the = target=20 connection state machine only allow for implicit logout in the LOGGED_IN = state=20 and in the states that follow it. The transition from IN_LOGIN to FREE,=20 T4, doesn't make any mention of implicit logout or connection=20 reinstatement. Time out or the transport going away are the things that = get you=20 from IN_LOGIN to FREE. One might get a second login attempt if there was = a=20 problem on the initial connection such as the network=20 going down but it is probably okay to not accept it until the = original=20 attempt has disappeared due to time out or closure of the transport = connection.=20 Lack of resources would be a reasonable response. If one does have the=20 resources, I'm not sure it is a necessary response.=20

Regards,

Pat

 -----Original = Message-----
From:=20 ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of = Pittman,=20 Joseph
Sent: Tuesday, January 06, 2004 1:02 PM
To:=20 ips@ietf.org
Subject: [Ips] iSCSI: When does a connection = become part=20 of a session?

I'm working on adding support = for=20 multi-connection sessions to an
iSCSI target implementation, and I = have=20 some questions about when
a new connection is considered to be part = of=20 a session.
 
Consider this set of login=20 request/response exchanges.  Assume
that there already exists = a=20 session with ISID=3D1/TSIH=3D2 on the
target, so the initiator is = trying to add=20 a connection to an
existing session.  The session is operating = at=20 ErrorRecoveryLevel=3D2,
and there already exists a connection with = CID=3D3=20 within that
session, so connection reinstatement is = required.
 
          &nbs= p;      =20 Initiator=20 = sends           &n= bsp;      =20 Target=20 = responds
          &= nbsp;      =20 = -------------------------        = =20 --------------------------
Exchange=20 0       =20 = LOGIN_REQ          &nbs= p;            = ; =20 = LOGIN_RESP
          = ;       =20 ISID=3D1, TSIH=3D2,=20 = CID=3D3           =  =20 ISID=3D1, TSIH=3D2,=20 = CID=3D3
          &n= bsp;      =20 CSG=3D0,=20 = T=3D0           &n= bsp;           =20 CSG=3D0,=20 = T=3D0
          &nbs= p;      =20 = AuthMethod=3DCHAP         &n= bsp;        =20 AuthMethod=3DCHAP
 
  ** Connection now in=20 SecurityNegotiation phase
 
Exchange=20 1       =20 = LOGIN_REQ          &nbs= p;            = ; =20 = LOGIN_RESP
          = ;       =20 ISID=3D1, TSIH=3D2,=20 = CID=3D3           =  =20 ISID=3D1, TSIH=3D2,=20 = CID=3D3
          &n= bsp;      =20 CSG=3D0,=20 = T=3D0           &n= bsp;           =20 CSG=3D0,=20 = T=3D0
          &nbs= p;      =20 = CHAP_A=3D5          &nb= sp;           &nbs= p;  =20 = CHAP_A=3D5
          = ;            =             &= nbsp;           &n= bsp;    =20 = CHAP_I=3Dx
          = ;            =             &= nbsp;           &n= bsp;    =20 CHAP_C=3Dx
 
Exchange=20 2       =20 = LOGIN_REQ          &nbs= p;            = ; =20 = LOGIN_RESP
          = ;       =20 ISID=3D1, TSIH=3D2,=20 = CID=3D3           =  =20 ISID=3D1, TSIH=3D2,=20 = CID=3D3
          &n= bsp;      =20 CSG=3D0, T=3D1,=20 = NSG=3D1           =      =20 CSG=3D0, T=3D1,=20 = NSG=3D1
          &n= bsp;      =20 = CHAP_R=3Dx
          = ;       =20 CHAP_N=3Dx
 
  ** Connection now in=20 LoginOperationalNegotiation phase
 

Exchange=20 3       =20 = LOGIN_REQ
          =        =20 ISID=3D1, TSIH=3D2,=20 = CID=3D3           =  =20 ISID=3D1, TSIH=3D2,=20 = CID=3D3
          &n= bsp;      =20 CSG=3D1, T=3D1,=20 = NSG=3D3           =      =20 CSG=3D1, T=3D1,=20 = NSG=3D3
          &n= bsp;      =20 = MaxRecvDSegLen=3Dxxx         = ;      =20 MaxRecvDSegLen=3Dxxx
 
  ** Connection now in=20 FullFeaturePhase phase
  ** Connection has been added to the = session=20 ISID=3D1/TSIH=3D2
  ** Previous connection = ISID=3D1/TSIH=3D2/CID=3D3 has been=20 logged out for
     recovery
 
 
Given this example, here are = a few=20 questions:
 
1) When is the target = supposed to=20 consider the connection as part of
   the session, for = the=20 purposes of the response ExpCmdSN and MaxCmdSN
  =20 fields?
 
   In general, the = ExpCmdSN and=20 MaxCmdSN fields contain information
   about the current = command=20 window for a session.  But when does the
   target = consider=20 the connection to be part the session:
 
   - Before = security=20 negotiation is complete?  If true, then = this
    =20 tells a spoofing initiator (who will eventually fail=20 authentication)
     about the presence of a = connection=20 by the initiator being spoofed
 
   - After security = negotiation=20 is complete?
 
   - Only in the = last login=20 response/transition to FFP?
 
   My inclination = is to only=20 consider the connection to be part of the
   connection = when it=20 has successfully completed the entire login
   sequence, = and thus=20 to return the joined session's ExpCmdSN and
  =20 MaxCmdSN only in the last = login=20 response.
 

2) When is the target = supposed to=20 perform the connection reinstatement
   algorithm, = including the=20 implicit logout for recovery of the
   existing=20 ISID=3D1/TSIH=3D2/CID=3D3 connection?
 
   - Before = security=20 negotiation is complete?  Surely not, = because
    =20 this allows a denial of service attack.
 
   - After security = negotiation=20 is complete?
 
   - Just before = sending the=20 last login response/transition to FFP?
 
   My inclination = is to only=20 consider the connection to be part of the
   connection = when it=20 has successfully completed the entire login
   sequence, = and thus=20 do connection reinstatement just prior to sending
   the = last=20 login response.
 
3) Here's a more esoteric = question: if=20 the login sequence for one
   connection = ISID=3D1/TSIH=3D2/CID=3D3 is=20 still in LoginOpNegotiation stage,
   and the initiator = starts=20 another connection with the same
   ISID/TSIH/CID, what = is the=20 target supposed to do?  Does 'connection
   = reinstatement'=20 apply also to a connection which is not yet in FFP?
 
   My inclination = is for the=20 target to consider the second login
   request as = spurious, and=20 to return NotEnoughResources (since I
   am unwilling to = dedicate=20 two 'new connection' slots to the same
   ISID/TSIH/CID=20 combination).
 

I cannot find any text in = the iSCSI=20 spec that unambiguously addresses
these issues.  Am I missing=20 anything?  If not, would any of the
authors care to give=20 guidance?
 
Thanks in advance for any=20 help.
--
Joe Pittman
jpittman@netapp.com
 
------_=_NextPart_001_01C3D4AF.DF4A73AF-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 6 21:14:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16421 for ; Tue, 6 Jan 2004 21:14:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae3Cj-000612-As for ips-archive@odin.ietf.org; Tue, 06 Jan 2004 21:13:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i072DrQr023118 for ips-archive@odin.ietf.org; Tue, 6 Jan 2004 21:13:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae3Cj-00060n-57 for ips-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 21:13:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16399 for ; Tue, 6 Jan 2004 21:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae3Cg-0006Zd-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 21:13:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae3Al-0006WF-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 21:11:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ae393-0006TP-00 for ips-web-archive@ietf.org; Tue, 06 Jan 2004 21:10:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae391-0005su-5a; Tue, 06 Jan 2004 21:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae38o-0005s0-Nh for ips@optimus.ietf.org; Tue, 06 Jan 2004 21:09:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16363 for ; Tue, 6 Jan 2004 21:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae38l-0006SR-00 for ips@ietf.org; Tue, 06 Jan 2004 21:09:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae36v-0006Qi-00 for ips@ietf.org; Tue, 06 Jan 2004 21:07:54 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1Ae35t-0006Ok-00 for ips@ietf.org; Tue, 06 Jan 2004 21:06:49 -0500 Received: from rosemail.rose.hp.com (postal.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id 1A2321C01B79; Tue, 6 Jan 2004 18:06:45 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj233.rose.hp.com [15.23.139.233]) by rosemail.rose.hp.com (Postfix) with ESMTP id 897767FFC; Tue, 6 Jan 2004 18:03:53 -0800 (PST) Message-ID: <3FFB69AB.4090302@rose.hp.com> Date: Tue, 06 Jan 2004 18:06:35 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pat_thaler@agilent.com Cc: Joseph.Pittman@netapp.com, ips@ietf.org Subject: Re: [Ips] iSCSI: When does a connection become part of a session? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Let me attempt to answer Joe's questions and clarify a couple of Pat's points. On Joe's #1, I agree with Pat's comments - there is no need to return valid values of sequence numbers before the final successful login reponse. On Joe's #2, Joe said: "My inclination is to only consider the connection to be part of the connection when it has successfully completed the entire login sequence, and thus do connection reinstatement just prior to sending the last login response." This is indeed the intent. Connection reinstatement should be performed only when the target is ready to signal the final approval for the login attempt on the connection in question. A target cannot perform the reinstatement for an old CID instance unless it arrived at a new FFP connection with the same CID (clearly, I think, stated in 5.3.4), i.e. unless login process is successfully complete for the new instance. On Joe's #3, the general approach should be to allow new login attempts to proceed as long as the total number of connections is < MaxConnections. At the time the target moves a connection to FFP, it should consider any earlier instance of the same CID to have been reinstated and drop the old instance (10.12.7). I thus would not recommend the approach you're leaning towards. Note however that the 10.12.7 text assumes that the initiator is well-behaved - if the initiator is in fact launching multiple login requests at the same time for the same CID, then it's violating the MUST requirement in 10.12.7 - "The initiator connection state MUST be CLEANUP_WAIT (section 7.1.3) when the initiator attempts a connection reinstatement." On Pat's points - > "Successful connection/session reinstatement" might be > read to mean that the login for the new session successfully > completed rather than just a login request was received. Yes, as clarified above. >However note that a failed connection > reinstatement causes T15 which moves the session from LOGGED_IN to > CLEANUP_WAIT so a failed attempt would still disrupt an active > connection. True, that was intended. However, there are two state machines here (CSM-C and CSM-I, borrowing 7.2 terminology), and note that Pat's clarification applies to CSM-C (i.e. the state machine representing the old instance). The CSM-I, the new state machine the login is happening on, OTOH, takes the T7 transition from IN_LOGIN to FREE. A "failed connection reinstatement", however, should have been defined in the spec (as Pat says). For a connection reinstatement effort to be considered "failed" and thus cause a state change to CSM-C on the target end, the effort should have progressed (and failed) beyond the SecurityNegotiation stage. Ditto for session reinstatement. Hope that helps. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com pat_thaler@agilent.com wrote: > Joe, > > You raise interesting questions. For the first two items, I think I > agree that your inclinations are sensible though not necessarily > supported in the iSCSI draft. On the third one, I'm not sure. > > On 1 - treatment of MaxCmdSN and ExpCmdSN during login, it would make > sense to withhold valid values for these fields at least until the > security phase of Login has completed and there doesn't seem to be any > reason to provide them before the last login. However, I don't find > anything in the spec that supports doing this. Under the description of > status class for Login Response, it says > > The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if > Status-Class is 0. > > which implies that the fields are valid when Status-Class is 0 including > during the security phase. > > On 2 - at what point in a connection reinstatement login does the old > connection get closed, 5.3.4 > > The Login request performs the logout function of the old connection if > an explicit logout was not performed earlier. > > which appears to indicate that it is the reception of the initial Login > Request PDU that causes the logout. As you suggest, actually operating > this way would leave one vulnerable to denial of service type attacks. > It makes more sense to wait until at least security phase has completed > to do the logout. It may make sense to wait to do close the old > connection until ready to send the final login response as you suggest > because this login may not succeed. However for resource constrained > implementations the reinstated connection may need resources allocated > to the existing connection. > > The state machine description might be hoped to provide more detail, but > they don't seem to be entirely consistant. The definition in 7.1.2 for > T8, (T13 and T18 have similar text) > > -target: An internal event of sending a Logout response (success) on > another connection for a "close the session" Logout request was > received, or an internal event of a successful connection/session > reinstatement is received, thus prompting the target to close this > connection cleanly. > > "Successful connection/session reinstatement" might be read to mean that > the login for the new session successfully completed rather than just a > login request was received. However note that a failed connection > reinstatement causes T15 which moves the session from LOGGED_IN to > CLEANUP_WAIT so a failed attempt would still disrupt an active > connection. There doesn't seem to be any definition provided for > successful and failed connection reinstatement. In the description of > connection cleanup state transitions (7.2.2, M4) successful implicit > logout appears to be defined as having reached the state LOGGED_IN on > the new connection. > > On 3, I think connection reinstatement only applies to a connection > that has completed login. The state transitions for the target > connection state machine only allow for implicit logout in the LOGGED_IN > state and in the states that follow it. The transition from IN_LOGIN to > FREE, T4, doesn't make any mention of implicit logout or connection > reinstatement. Time out or the transport going away are the things that > get you from IN_LOGIN to FREE. One might get a second login attempt if > there was a problem on the initial connection such as the network > going down but it is probably okay to not accept it until the original > attempt has disappeared due to time out or closure of the transport > connection. Lack of resources would be a reasonable response. If one > does have the resources, I'm not sure it is a necessary response. > > Regards, > > Pat > > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of > Pittman, Joseph > Sent: Tuesday, January 06, 2004 1:02 PM > To: ips@ietf.org > Subject: [Ips] iSCSI: When does a connection become part of a session? > > I'm working on adding support for multi-connection sessions to an > iSCSI target implementation, and I have some questions about when > a new connection is considered to be part of a session. > > Consider this set of login request/response exchanges. Assume > that there already exists a session with ISID=1/TSIH=2 on the > target, so the initiator is trying to add a connection to an > existing session. The session is operating at ErrorRecoveryLevel=2, > and there already exists a connection with CID=3 within that > session, so connection reinstatement is required. > > Initiator sends Target responds > ------------------------- > -------------------------- > Exchange 0 LOGIN_REQ LOGIN_RESP > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > CID=3 > CSG=0, T=0 CSG=0, T=0 > AuthMethod=CHAP AuthMethod=CHAP > > ** Connection now in SecurityNegotiation phase > > Exchange 1 LOGIN_REQ LOGIN_RESP > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > CID=3 > CSG=0, T=0 CSG=0, T=0 > CHAP_A=5 CHAP_A=5 > CHAP_I=x > CHAP_C=x > > Exchange 2 LOGIN_REQ LOGIN_RESP > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > CID=3 > CSG=0, T=1, NSG=1 CSG=0, T=1, NSG=1 > CHAP_R=x > CHAP_N=x > > ** Connection now in LoginOperationalNegotiation phase > > > Exchange 3 LOGIN_REQ > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > CID=3 > CSG=1, T=1, NSG=3 CSG=1, T=1, NSG=3 > MaxRecvDSegLen=xxx MaxRecvDSegLen=xxx > > ** Connection now in FullFeaturePhase phase > ** Connection has been added to the session ISID=1/TSIH=2 > ** Previous connection ISID=1/TSIH=2/CID=3 has been logged out for > recovery > > > Given this example, here are a few questions: > > 1) When is the target supposed to consider the connection as part of > the session, for the purposes of the response ExpCmdSN and MaxCmdSN > fields? > > In general, the ExpCmdSN and MaxCmdSN fields contain information > about the current command window for a session. But when does the > target consider the connection to be part the session: > > - Before security negotiation is complete? If true, then this > tells a spoofing initiator (who will eventually fail > authentication) > about the presence of a connection by the initiator being spoofed > > - After security negotiation is complete? > > - Only in the last login response/transition to FFP? > > My inclination is to only consider the connection to be part of the > connection when it has successfully completed the entire login > sequence, and thus to return the joined session's ExpCmdSN and > MaxCmdSN only in the last login response. > > > 2) When is the target supposed to perform the connection reinstatement > algorithm, including the implicit logout for recovery of the > existing ISID=1/TSIH=2/CID=3 connection? > > - Before security negotiation is complete? Surely not, because > this allows a denial of service attack. > > - After security negotiation is complete? > > - Just before sending the last login response/transition to FFP? > > My inclination is to only consider the connection to be part of the > connection when it has successfully completed the entire login > sequence, and thus do connection reinstatement just prior to sending > the last login response. > > 3) Here's a more esoteric question: if the login sequence for one > connection ISID=1/TSIH=2/CID=3 is still in LoginOpNegotiation stage, > and the initiator starts another connection with the same > ISID/TSIH/CID, what is the target supposed to do? Does 'connection > reinstatement' apply also to a connection which is not yet in FFP? > > My inclination is for the target to consider the second login > request as spurious, and to return NotEnoughResources (since I > am unwilling to dedicate two 'new connection' slots to the same > ISID/TSIH/CID combination). > > > I cannot find any text in the iSCSI spec that unambiguously addresses > these issues. Am I missing anything? If not, would any of the > authors care to give guidance? > > Thanks in advance for any help. > -- > Joe Pittman > jpittman@netapp.com > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 7 11:06:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16607 for ; Wed, 7 Jan 2004 11:06:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGCB-0001nD-Ro for ips-archive@odin.ietf.org; Wed, 07 Jan 2004 11:06:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07G6BjH006887 for ips-archive@odin.ietf.org; Wed, 7 Jan 2004 11:06:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGCB-0001n0-ON for ips-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 11:06:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16578 for ; Wed, 7 Jan 2004 11:06:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeGC9-0002jN-00 for ips-web-archive@ietf.org; Wed, 07 Jan 2004 11:06:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeGAO-0002eO-00 for ips-web-archive@ietf.org; Wed, 07 Jan 2004 11:04:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeG99-0002Yz-00 for ips-web-archive@ietf.org; Wed, 07 Jan 2004 11:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeG97-0001co-Je; Wed, 07 Jan 2004 11:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeG8U-0001be-4O for ips@optimus.ietf.org; Wed, 07 Jan 2004 11:02:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16451 for ; Wed, 7 Jan 2004 11:02:18 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeG8R-0002X6-00 for ips@ietf.org; Wed, 07 Jan 2004 11:02:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeG6d-0002Rh-00 for ips@ietf.org; Wed, 07 Jan 2004 11:00:28 -0500 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AeG66-0002LR-00 for ips@ietf.org; Wed, 07 Jan 2004 10:59:54 -0500 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Jan 2004 10:59:24 -0500 Message-ID: To: ips@ietf.org Date: Wed, 7 Jan 2004 10:59:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] IPS Security draft change to SLP text Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Everyone, In working through the security issues that were holding up the SLP drafts for iSCSI and FCIP, we ran across an oversight in the main IPS security draft (draft-ietf-ips-security-19.txt), where a "MUST implement" requirement was applied to IPsec for SLP by mistake. The correct requirement level is "SHOULD implement". The RFC Editor will be asked to make the two text changes shown below (our Area Director has approved these changes). These are *not* technical change - they bring the IPS security draft into line with what the WG approved as the security requirements (which are correctly reflected in the two SLP drafts). FYI and sorry for missing this earlier, --David In Section 2.5.1 change: "In order to provide the required security functionality, iSCSI and FCIP security implementations SHOULD protect SLPv2 messages sent via unicast using IPsec ESP with a non-null transform. " To: "In order to provide the required security functionality, iSCSI and FCIP implementations supporting SLPv2 security SHOULD protect SLPv2 messages sent via unicast using IPsec ESP with a non-null transform." In Section 2.5.2, change: "iSCSI and FCIP security implementations MUST support confidentiality as well as authentication of unicast SLPv2 messages." To: "iSCSI and FCIP security implementations supporting SLPv2 security SHOULD encrypt as well as authenticate and integrity-protect unicast SLPv2 messages." _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 7 17:40:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10551 for ; Wed, 7 Jan 2004 17:40:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMLW-0006a1-10 for ips-archive@odin.ietf.org; Wed, 07 Jan 2004 17:40:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07MeDfs025287 for ips-archive@odin.ietf.org; Wed, 7 Jan 2004 17:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMLR-0006Zh-SC for ips-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 17:40:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10419 for ; Wed, 7 Jan 2004 17:40:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMLP-0005Zl-00 for ips-web-archive@ietf.org; Wed, 07 Jan 2004 17:40:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMJV-0005QE-00 for ips-web-archive@ietf.org; Wed, 07 Jan 2004 17:38:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeMHZ-0005Gc-00 for ips-web-archive@ietf.org; Wed, 07 Jan 2004 17:36:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMHT-0005xu-RD; Wed, 07 Jan 2004 17:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMH5-0005vF-6v for ips@optimus.ietf.org; Wed, 07 Jan 2004 17:35:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10076 for ; Wed, 7 Jan 2004 17:35:35 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMH2-00059M-00 for ips@ietf.org; Wed, 07 Jan 2004 17:35:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMCa-0004vC-00 for ips@ietf.org; Wed, 07 Jan 2004 17:31:01 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AeM9o-0004er-00 for ips@ietf.org; Wed, 07 Jan 2004 17:28:08 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 4EDA140134; Wed, 7 Jan 2004 17:27:43 -0500 (EST) Date: Wed, 7 Jan 2004 14:23:36 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Mallikarjun C." Cc: pat_thaler@agilent.com, Joseph.Pittman@netapp.com, ips@ietf.org Subject: Re: [Ips] iSCSI: When does a connection become part of a session? In-Reply-To: <3FFB69AB.4090302@rose.hp.com> Message-ID: References: <3FFB69AB.4090302@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 6 Jan 2004, Mallikarjun C. wrote: > Let me attempt to answer Joe's questions and clarify > a couple of Pat's points. And I'll comment on your comments. :-) > On Joe's #1, I agree with Pat's comments - there is no > need to return valid values of sequence numbers before > the final successful login reponse. Note: Joe was talking about MaxCmdSN and ExpCmdSN, and I agree there is some question about them. However you mentioned "sequence numbers", which can be taken to include StatSN too. As best I can tell, StatSN needs to be present and respected at all times. Also, our target expects StatSN (and ExpStatSN) to be handled correctly even in login. As StatSN is connection-specific, I see no session nor security problems with this. :-) I think perhaps we should split this question into two questions. 1) what should the target put into MaxCmdSN and ExpCmdSN (and the initiator into CmdSN), and 2) what should the target (or initiator) do with the CmdSN (MaxCmdSN and ExpCmdSN) value(s) it gets. I think (2) is the more important. I think both the initiator and target should ignore CmdSN, MaxCmdSN, and ExpCmdSN on PDUs other than the last one. For the initial login and for session reinstatement, I think the CmdSN on the last Login Request (the one that triggers the transition to FFP) should seed the target's idea of ExpCmdSN (and thus MaxCmdSN). Other than that, I think it should be ignored. As login commands are immediate, that makes sense. As for (1), I think you're supposed to be shoving good values into the response. Our target does. However with (2) in place, it wouldn't hurt if the target just returned zero. Does anyone see a security implication of the target leaking MaxCmdSN and ExpCmdSN? > On Joe's #2, Joe said: > "My inclination is to only consider the connection to be part of the > connection when it has successfully completed the entire login > sequence, and thus do connection reinstatement just prior to sending > the last login response." > > This is indeed the intent. Connection reinstatement > should be performed only when the target is ready to > signal the final approval for the login attempt on the > connection in question. A target cannot perform the > reinstatement for an old CID instance unless it arrived > at a new FFP connection with the same CID (clearly, I > think, stated in 5.3.4), i.e. unless login process is > successfully complete for the new instance. Agreed. Actually, we have two levels of session membership. One is "full" which a connection gets when it goes to FFP. This is what everyone thinks of for connections being in a session. The other is a tentative membership, which we give new connections that are members of an existing session. This isn't really covered in the spec. We do this mainly so that we can limit the number of connections tied to a session, and protect ourselves from DoS attacks. A connection in this state can see what's happening in the session (it reports MaxCmdSN and ExpCmdSN), but it can't impact the session. This is how we send back valid MaxCmdSN and ExpCmdSN. You can only have MaxConnections connections in FFP, and MaxConnections + a fudge factor (currently 2) connections in FFP and in login. > On Joe's #3, the general approach should be to allow > new login attempts to proceed as long as the total > number of connections is < MaxConnections. At the > time the target moves a connection to FFP, it should > consider any earlier instance of the same CID to have > been reinstated and drop the old instance (10.12.7). > I thus would not recommend the approach you're leaning > towards. Note however that the 10.12.7 text assumes > that the initiator is well-behaved - if the initiator > is in fact launching multiple login requests at the > same time for the same CID, then it's violating the MUST > requirement in 10.12.7 - "The initiator connection > state MUST be CLEANUP_WAIT (section 7.1.3) when the > initiator attempts a connection reinstatement." We take a third approach. If we don't already have MaxConnections + 2 connections in FFP and in login, we let a new login proceed. If we didn't do something like this, then if you had a session with MaxConnections connections, you could not do any ERL 2 recovery. We let the second (connection reinstatement) login attempt proceed as well. When ever either of them reaches FFP, both the original connection and the login that hasn't completed login get killed. Yes, this is a violation in that the initiator appears to be violating 10.12.7. However if something went wrong with one reinstatement attempt, we might get to this situation. > On Pat's points - > > > "Successful connection/session reinstatement" might be > > read to mean that the login for the new session successfully > > completed rather than just a login request was received. > > Yes, as clarified above. Agreed. It all happens at the end of login processing, just before the PDU is sent indicating we're going to FFP. > >However note that a failed connection > > reinstatement causes T15 which moves the session from LOGGED_IN to > > CLEANUP_WAIT so a failed attempt would still disrupt an active > > connection. > > True, that was intended. However, there are two state > machines here (CSM-C and CSM-I, borrowing 7.2 terminology), > and note that Pat's clarification applies to CSM-C (i.e. > the state machine representing the old instance). The CSM-I, > the new state machine the login is happening on, OTOH, > takes the T7 transition from IN_LOGIN to FREE. > > A "failed connection reinstatement", however, should have > been defined in the spec (as Pat says). For a connection > reinstatement effort to be considered "failed" and thus > cause a state change to CSM-C on the target end, the effort > should have progressed (and failed) beyond the SecurityNegotiation > stage. Ditto for session reinstatement. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 7 17:58:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11213 for ; Wed, 7 Jan 2004 17:58:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMd3-0007Gm-IM for ips-archive@odin.ietf.org; Wed, 07 Jan 2004 17:58:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07MwLFq027938 for ips-archive@odin.ietf.org; Wed, 7 Jan 2004 17:58:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMd3-0007GX-D8 for ips-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 17:58:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11172 for ; Wed, 7 Jan 2004 17:58:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMd0-0006Yv-00 for ips-web-archive@ietf.org; Wed, 07 Jan 2004 17:58:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMb8-0006Tt-00 for ips-web-archive@ietf.org; Wed, 07 Jan 2004 17:56:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeMZp-0006Pl-00 for ips-web-archive@ietf.org; Wed, 07 Jan 2004 17:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMZq-00077F-S2; Wed, 07 Jan 2004 17:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMZI-000768-K6 for ips@optimus.ietf.org; Wed, 07 Jan 2004 17:54:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11070 for ; Wed, 7 Jan 2004 17:54:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMZF-0006Oc-00 for ips@ietf.org; Wed, 07 Jan 2004 17:54:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMXa-0006J4-00 for ips@ietf.org; Wed, 07 Jan 2004 17:52:43 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AeMWD-0006BF-00 for ips@ietf.org; Wed, 07 Jan 2004 17:51:17 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (sccrmhc11) with SMTP id <2004010722504601100l895le> (Authid: esquicksall); Wed, 7 Jan 2004 22:50:46 +0000 Message-ID: <000801c3d570$b00aff30$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Mallikarjun C." , Cc: , References: <3FFB69AB.4090302@rose.hp.com> Subject: Re: [Ips] iSCSI: When does a connection become part of a session? Date: Wed, 7 Jan 2004 17:50:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mallikarjun, For case #1, that seems like a good idea but I don't think the spec says this. If an initiator is using MaxCmdSN and ExpCmdSN to update internal registers, then suddenly forcing them to 0 may cause problems in current implementations. Eddy ----- Original Message ----- From: "Mallikarjun C." To: Cc: ; Sent: Tuesday, January 06, 2004 9:06 PM Subject: Re: [Ips] iSCSI: When does a connection become part of a session? > Let me attempt to answer Joe's questions and clarify > a couple of Pat's points. > > On Joe's #1, I agree with Pat's comments - there is no > need to return valid values of sequence numbers before > the final successful login reponse. > > On Joe's #2, Joe said: > "My inclination is to only consider the connection to be part of the > connection when it has successfully completed the entire login > sequence, and thus do connection reinstatement just prior to sending > the last login response." > > This is indeed the intent. Connection reinstatement > should be performed only when the target is ready to > signal the final approval for the login attempt on the > connection in question. A target cannot perform the > reinstatement for an old CID instance unless it arrived > at a new FFP connection with the same CID (clearly, I > think, stated in 5.3.4), i.e. unless login process is > successfully complete for the new instance. > > On Joe's #3, the general approach should be to allow > new login attempts to proceed as long as the total > number of connections is < MaxConnections. At the > time the target moves a connection to FFP, it should > consider any earlier instance of the same CID to have > been reinstated and drop the old instance (10.12.7). > I thus would not recommend the approach you're leaning > towards. Note however that the 10.12.7 text assumes > that the initiator is well-behaved - if the initiator > is in fact launching multiple login requests at the > same time for the same CID, then it's violating the MUST > requirement in 10.12.7 - "The initiator connection > state MUST be CLEANUP_WAIT (section 7.1.3) when the > initiator attempts a connection reinstatement." > > On Pat's points - > > > "Successful connection/session reinstatement" might be > > read to mean that the login for the new session successfully > > completed rather than just a login request was received. > > Yes, as clarified above. > > >However note that a failed connection > > reinstatement causes T15 which moves the session from LOGGED_IN to > > CLEANUP_WAIT so a failed attempt would still disrupt an active > > connection. > > True, that was intended. However, there are two state > machines here (CSM-C and CSM-I, borrowing 7.2 terminology), > and note that Pat's clarification applies to CSM-C (i.e. > the state machine representing the old instance). The CSM-I, > the new state machine the login is happening on, OTOH, > takes the T7 transition from IN_LOGIN to FREE. > > A "failed connection reinstatement", however, should have > been defined in the spec (as Pat says). For a connection > reinstatement effort to be considered "failed" and thus > cause a state change to CSM-C on the target end, the effort > should have progressed (and failed) beyond the SecurityNegotiation > stage. Ditto for session reinstatement. > > Hope that helps. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > > > > pat_thaler@agilent.com wrote: > > > Joe, > > > > You raise interesting questions. For the first two items, I think I > > agree that your inclinations are sensible though not necessarily > > supported in the iSCSI draft. On the third one, I'm not sure. > > > > On 1 - treatment of MaxCmdSN and ExpCmdSN during login, it would make > > sense to withhold valid values for these fields at least until the > > security phase of Login has completed and there doesn't seem to be any > > reason to provide them before the last login. However, I don't find > > anything in the spec that supports doing this. Under the description of > > status class for Login Response, it says > > > > The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if > > Status-Class is 0. > > > > which implies that the fields are valid when Status-Class is 0 including > > during the security phase. > > > > On 2 - at what point in a connection reinstatement login does the old > > connection get closed, 5.3.4 > > > > The Login request performs the logout function of the old connection if > > an explicit logout was not performed earlier. > > > > which appears to indicate that it is the reception of the initial Login > > Request PDU that causes the logout. As you suggest, actually operating > > this way would leave one vulnerable to denial of service type attacks. > > It makes more sense to wait until at least security phase has completed > > to do the logout. It may make sense to wait to do close the old > > connection until ready to send the final login response as you suggest > > because this login may not succeed. However for resource constrained > > implementations the reinstated connection may need resources allocated > > to the existing connection. > > > > The state machine description might be hoped to provide more detail, but > > they don't seem to be entirely consistant. The definition in 7.1.2 for > > T8, (T13 and T18 have similar text) > > > > -target: An internal event of sending a Logout response (success) on > > another connection for a "close the session" Logout request was > > received, or an internal event of a successful connection/session > > reinstatement is received, thus prompting the target to close this > > connection cleanly. > > > > "Successful connection/session reinstatement" might be read to mean that > > the login for the new session successfully completed rather than just a > > login request was received. However note that a failed connection > > reinstatement causes T15 which moves the session from LOGGED_IN to > > CLEANUP_WAIT so a failed attempt would still disrupt an active > > connection. There doesn't seem to be any definition provided for > > successful and failed connection reinstatement. In the description of > > connection cleanup state transitions (7.2.2, M4) successful implicit > > logout appears to be defined as having reached the state LOGGED_IN on > > the new connection. > > > > On 3, I think connection reinstatement only applies to a connection > > that has completed login. The state transitions for the target > > connection state machine only allow for implicit logout in the LOGGED_IN > > state and in the states that follow it. The transition from IN_LOGIN to > > FREE, T4, doesn't make any mention of implicit logout or connection > > reinstatement. Time out or the transport going away are the things that > > get you from IN_LOGIN to FREE. One might get a second login attempt if > > there was a problem on the initial connection such as the network > > going down but it is probably okay to not accept it until the original > > attempt has disappeared due to time out or closure of the transport > > connection. Lack of resources would be a reasonable response. If one > > does have the resources, I'm not sure it is a necessary response. > > > > Regards, > > > > Pat > > > > -----Original Message----- > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of > > Pittman, Joseph > > Sent: Tuesday, January 06, 2004 1:02 PM > > To: ips@ietf.org > > Subject: [Ips] iSCSI: When does a connection become part of a session? > > > > I'm working on adding support for multi-connection sessions to an > > iSCSI target implementation, and I have some questions about when > > a new connection is considered to be part of a session. > > > > Consider this set of login request/response exchanges. Assume > > that there already exists a session with ISID=1/TSIH=2 on the > > target, so the initiator is trying to add a connection to an > > existing session. The session is operating at ErrorRecoveryLevel=2, > > and there already exists a connection with CID=3 within that > > session, so connection reinstatement is required. > > > > Initiator sends Target responds > > ------------------------- > > -------------------------- > > Exchange 0 LOGIN_REQ LOGIN_RESP > > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > > CID=3 > > CSG=0, T=0 CSG=0, T=0 > > AuthMethod=CHAP AuthMethod=CHAP > > > > ** Connection now in SecurityNegotiation phase > > > > Exchange 1 LOGIN_REQ LOGIN_RESP > > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > > CID=3 > > CSG=0, T=0 CSG=0, T=0 > > CHAP_A=5 CHAP_A=5 > > CHAP_I=x > > CHAP_C=x > > > > Exchange 2 LOGIN_REQ LOGIN_RESP > > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > > CID=3 > > CSG=0, T=1, NSG=1 CSG=0, T=1, NSG=1 > > CHAP_R=x > > CHAP_N=x > > > > ** Connection now in LoginOperationalNegotiation phase > > > > > > Exchange 3 LOGIN_REQ > > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > > CID=3 > > CSG=1, T=1, NSG=3 CSG=1, T=1, NSG=3 > > MaxRecvDSegLen=xxx MaxRecvDSegLen=xxx > > > > ** Connection now in FullFeaturePhase phase > > ** Connection has been added to the session ISID=1/TSIH=2 > > ** Previous connection ISID=1/TSIH=2/CID=3 has been logged out for > > recovery > > > > > > Given this example, here are a few questions: > > > > 1) When is the target supposed to consider the connection as part of > > the session, for the purposes of the response ExpCmdSN and MaxCmdSN > > fields? > > > > In general, the ExpCmdSN and MaxCmdSN fields contain information > > about the current command window for a session. But when does the > > target consider the connection to be part the session: > > > > - Before security negotiation is complete? If true, then this > > tells a spoofing initiator (who will eventually fail > > authentication) > > about the presence of a connection by the initiator being spoofed > > > > - After security negotiation is complete? > > > > - Only in the last login response/transition to FFP? > > > > My inclination is to only consider the connection to be part of the > > connection when it has successfully completed the entire login > > sequence, and thus to return the joined session's ExpCmdSN and > > MaxCmdSN only in the last login response. > > > > > > 2) When is the target supposed to perform the connection reinstatement > > algorithm, including the implicit logout for recovery of the > > existing ISID=1/TSIH=2/CID=3 connection? > > > > - Before security negotiation is complete? Surely not, because > > this allows a denial of service attack. > > > > - After security negotiation is complete? > > > > - Just before sending the last login response/transition to FFP? > > > > My inclination is to only consider the connection to be part of the > > connection when it has successfully completed the entire login > > sequence, and thus do connection reinstatement just prior to sending > > the last login response. > > > > 3) Here's a more esoteric question: if the login sequence for one > > connection ISID=1/TSIH=2/CID=3 is still in LoginOpNegotiation stage, > > and the initiator starts another connection with the same > > ISID/TSIH/CID, what is the target supposed to do? Does 'connection > > reinstatement' apply also to a connection which is not yet in FFP? > > > > My inclination is for the target to consider the second login > > request as spurious, and to return NotEnoughResources (since I > > am unwilling to dedicate two 'new connection' slots to the same > > ISID/TSIH/CID combination). > > > > > > I cannot find any text in the iSCSI spec that unambiguously addresses > > these issues. Am I missing anything? If not, would any of the > > authors care to give guidance? > > > > Thanks in advance for any help. > > -- > > Joe Pittman > > jpittman@netapp.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 exim@www1.ietf.org Thu Jan 8 14:45:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07825 for ; Thu, 8 Jan 2004 14:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg5M-0002Ya-D1 for ips-archive@odin.ietf.org; Thu, 08 Jan 2004 14:44:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Jiqn1009822 for ips-archive@odin.ietf.org; Thu, 8 Jan 2004 14:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg5K-0002YG-S1 for ips-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 14:44:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07789 for ; Thu, 8 Jan 2004 14:44:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeg5I-0001t4-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 14:44:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeg3O-0001mE-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 14:42:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeg2g-0001gC-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 14:42:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg2b-0002Kb-EG; Thu, 08 Jan 2004 14:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeftR-00014l-Lz for ips@optimus.ietf.org; Thu, 08 Jan 2004 14:32:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07300 for ; Thu, 8 Jan 2004 14:32:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeftP-0001Ca-00 for ips@ietf.org; Thu, 08 Jan 2004 14:32:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AefrZ-00018n-00 for ips@ietf.org; Thu, 08 Jan 2004 14:30:38 -0500 Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx with esmtp (Exim 4.12) id 1AefqQ-00014c-00 for ips@ietf.org; Thu, 08 Jan 2004 14:29:26 -0500 Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.12.10/8.12.10) with ESMTP id i08JR5oF017907; Thu, 8 Jan 2004 14:27:05 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.10/8.12.10/Submit) with ESMTP id i08JR5Hl017900; Thu, 8 Jan 2004 14:27:05 -0500 Date: Thu, 8 Jan 2004 14:27:05 -0500 (EST) From: "Robert D. Russell" To: Eddy Quicksall cc: "Mallikarjun C." , pat_thaler@agilent.com, Joseph.Pittman@netapp.com, ips@ietf.org Subject: Re: [Ips] iSCSI: When does a connection become part of a session? In-Reply-To: <000801c3d570$b00aff30$0303a8c0@ivvt2dxrc11> Message-ID: References: <3FFB69AB.4090302@rose.hp.com> <000801c3d570$b00aff30$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Mallikarjan: I agree with Eddy and Bill -- the current standard requires that the target fill in MaxCmdSN and ExpCmdSN with valid values on all Login Response PDUs that it sends. To do otherwise violates the standard and is potentially not interoperable with an arbitrary initiator. However, applying the philosophy of "conservative in what you send, liberal in what you receive", there is no apparent reason for the initiator to check these values if it doesn't want to, and not checking them will not violate the standard. Bob Russell > For case #1, that seems like a good idea but I don't think the spec says > this. > > If an initiator is using MaxCmdSN and ExpCmdSN to update internal registers, > then suddenly forcing them to 0 may cause problems in current > implementations. > > Eddy > > ----- Original Message ----- > From: "Mallikarjun C." > To: > Cc: ; > Sent: Tuesday, January 06, 2004 9:06 PM > Subject: Re: [Ips] iSCSI: When does a connection become part of a session? > > > > Let me attempt to answer Joe's questions and clarify > > a couple of Pat's points. > > > > On Joe's #1, I agree with Pat's comments - there is no > > need to return valid values of sequence numbers before > > the final successful login reponse. > > > > On Joe's #2, Joe said: > > "My inclination is to only consider the connection to be part of the > > connection when it has successfully completed the entire login > > sequence, and thus do connection reinstatement just prior to sending > > the last login response." > > > > This is indeed the intent. Connection reinstatement > > should be performed only when the target is ready to > > signal the final approval for the login attempt on the > > connection in question. A target cannot perform the > > reinstatement for an old CID instance unless it arrived > > at a new FFP connection with the same CID (clearly, I > > think, stated in 5.3.4), i.e. unless login process is > > successfully complete for the new instance. > > > > On Joe's #3, the general approach should be to allow > > new login attempts to proceed as long as the total > > number of connections is < MaxConnections. At the > > time the target moves a connection to FFP, it should > > consider any earlier instance of the same CID to have > > been reinstated and drop the old instance (10.12.7). > > I thus would not recommend the approach you're leaning > > towards. Note however that the 10.12.7 text assumes > > that the initiator is well-behaved - if the initiator > > is in fact launching multiple login requests at the > > same time for the same CID, then it's violating the MUST > > requirement in 10.12.7 - "The initiator connection > > state MUST be CLEANUP_WAIT (section 7.1.3) when the > > initiator attempts a connection reinstatement." > > > > On Pat's points - > > > > > "Successful connection/session reinstatement" might be > > > read to mean that the login for the new session successfully > > > completed rather than just a login request was received. > > > > Yes, as clarified above. > > > > >However note that a failed connection > > > reinstatement causes T15 which moves the session from LOGGED_IN to > > > CLEANUP_WAIT so a failed attempt would still disrupt an active > > > connection. > > > > True, that was intended. However, there are two state > > machines here (CSM-C and CSM-I, borrowing 7.2 terminology), > > and note that Pat's clarification applies to CSM-C (i.e. > > the state machine representing the old instance). The CSM-I, > > the new state machine the login is happening on, OTOH, > > takes the T7 transition from IN_LOGIN to FREE. > > > > A "failed connection reinstatement", however, should have > > been defined in the spec (as Pat says). For a connection > > reinstatement effort to be considered "failed" and thus > > cause a state change to CSM-C on the target end, the effort > > should have progressed (and failed) beyond the SecurityNegotiation > > stage. Ditto for session reinstatement. > > > > Hope that helps. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm [at] rose.hp.com > > > > > > > > > > > > pat_thaler@agilent.com wrote: > > > > > Joe, > > > > > > You raise interesting questions. For the first two items, I think I > > > agree that your inclinations are sensible though not necessarily > > > supported in the iSCSI draft. On the third one, I'm not sure. > > > > > > On 1 - treatment of MaxCmdSN and ExpCmdSN during login, it would make > > > sense to withhold valid values for these fields at least until the > > > security phase of Login has completed and there doesn't seem to be any > > > reason to provide them before the last login. However, I don't find > > > anything in the spec that supports doing this. Under the description of > > > status class for Login Response, it says > > > > > > The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if > > > Status-Class is 0. > > > > > > which implies that the fields are valid when Status-Class is 0 including > > > during the security phase. > > > > > > On 2 - at what point in a connection reinstatement login does the old > > > connection get closed, 5.3.4 > > > > > > The Login request performs the logout function of the old connection if > > > an explicit logout was not performed earlier. > > > > > > which appears to indicate that it is the reception of the initial Login > > > Request PDU that causes the logout. As you suggest, actually operating > > > this way would leave one vulnerable to denial of service type attacks. > > > It makes more sense to wait until at least security phase has completed > > > to do the logout. It may make sense to wait to do close the old > > > connection until ready to send the final login response as you suggest > > > because this login may not succeed. However for resource constrained > > > implementations the reinstated connection may need resources allocated > > > to the existing connection. > > > > > > The state machine description might be hoped to provide more detail, but > > > they don't seem to be entirely consistant. The definition in 7.1.2 for > > > T8, (T13 and T18 have similar text) > > > > > > -target: An internal event of sending a Logout response (success) on > > > another connection for a "close the session" Logout request was > > > received, or an internal event of a successful connection/session > > > reinstatement is received, thus prompting the target to close this > > > connection cleanly. > > > > > > "Successful connection/session reinstatement" might be read to mean that > > > the login for the new session successfully completed rather than just a > > > login request was received. However note that a failed connection > > > reinstatement causes T15 which moves the session from LOGGED_IN to > > > CLEANUP_WAIT so a failed attempt would still disrupt an active > > > connection. There doesn't seem to be any definition provided for > > > successful and failed connection reinstatement. In the description of > > > connection cleanup state transitions (7.2.2, M4) successful implicit > > > logout appears to be defined as having reached the state LOGGED_IN on > > > the new connection. > > > > > > On 3, I think connection reinstatement only applies to a connection > > > that has completed login. The state transitions for the target > > > connection state machine only allow for implicit logout in the LOGGED_IN > > > state and in the states that follow it. The transition from IN_LOGIN to > > > FREE, T4, doesn't make any mention of implicit logout or connection > > > reinstatement. Time out or the transport going away are the things that > > > get you from IN_LOGIN to FREE. One might get a second login attempt if > > > there was a problem on the initial connection such as the network > > > going down but it is probably okay to not accept it until the original > > > attempt has disappeared due to time out or closure of the transport > > > connection. Lack of resources would be a reasonable response. If one > > > does have the resources, I'm not sure it is a necessary response. > > > > > > Regards, > > > > > > Pat > > > > > > -----Original Message----- > > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of > > > Pittman, Joseph > > > Sent: Tuesday, January 06, 2004 1:02 PM > > > To: ips@ietf.org > > > Subject: [Ips] iSCSI: When does a connection become part of a session? > > > > > > I'm working on adding support for multi-connection sessions to an > > > iSCSI target implementation, and I have some questions about when > > > a new connection is considered to be part of a session. > > > > > > Consider this set of login request/response exchanges. Assume > > > that there already exists a session with ISID=1/TSIH=2 on the > > > target, so the initiator is trying to add a connection to an > > > existing session. The session is operating at ErrorRecoveryLevel=2, > > > and there already exists a connection with CID=3 within that > > > session, so connection reinstatement is required. > > > > > > Initiator sends Target responds > > > ------------------------- > > > -------------------------- > > > Exchange 0 LOGIN_REQ LOGIN_RESP > > > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > > > CID=3 > > > CSG=0, T=0 CSG=0, T=0 > > > AuthMethod=CHAP AuthMethod=CHAP > > > > > > ** Connection now in SecurityNegotiation phase > > > > > > Exchange 1 LOGIN_REQ LOGIN_RESP > > > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > > > CID=3 > > > CSG=0, T=0 CSG=0, T=0 > > > CHAP_A=5 CHAP_A=5 > > > CHAP_I=x > > > CHAP_C=x > > > > > > Exchange 2 LOGIN_REQ LOGIN_RESP > > > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > > > CID=3 > > > CSG=0, T=1, NSG=1 CSG=0, T=1, > NSG=1 > > > CHAP_R=x > > > CHAP_N=x > > > > > > ** Connection now in LoginOperationalNegotiation phase > > > > > > > > > Exchange 3 LOGIN_REQ > > > ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, > > > CID=3 > > > CSG=1, T=1, NSG=3 CSG=1, T=1, > NSG=3 > > > MaxRecvDSegLen=xxx > MaxRecvDSegLen=xxx > > > > > > ** Connection now in FullFeaturePhase phase > > > ** Connection has been added to the session ISID=1/TSIH=2 > > > ** Previous connection ISID=1/TSIH=2/CID=3 has been logged out for > > > recovery > > > > > > > > > Given this example, here are a few questions: > > > > > > 1) When is the target supposed to consider the connection as part of > > > the session, for the purposes of the response ExpCmdSN and > MaxCmdSN > > > fields? > > > > > > In general, the ExpCmdSN and MaxCmdSN fields contain information > > > about the current command window for a session. But when does > the > > > target consider the connection to be part the session: > > > > > > - Before security negotiation is complete? If true, then this > > > tells a spoofing initiator (who will eventually fail > > > authentication) > > > about the presence of a connection by the initiator being > spoofed > > > > > > - After security negotiation is complete? > > > > > > - Only in the last login response/transition to FFP? > > > > > > My inclination is to only consider the connection to be part of > the > > > connection when it has successfully completed the entire login > > > sequence, and thus to return the joined session's ExpCmdSN and > > > MaxCmdSN only in the last login response. > > > > > > > > > 2) When is the target supposed to perform the connection > reinstatement > > > algorithm, including the implicit logout for recovery of the > > > existing ISID=1/TSIH=2/CID=3 connection? > > > > > > - Before security negotiation is complete? Surely not, because > > > this allows a denial of service attack. > > > > > > - After security negotiation is complete? > > > > > > - Just before sending the last login response/transition to FFP? > > > > > > My inclination is to only consider the connection to be part of > the > > > connection when it has successfully completed the entire login > > > sequence, and thus do connection reinstatement just prior to > sending > > > the last login response. > > > > > > 3) Here's a more esoteric question: if the login sequence for one > > > connection ISID=1/TSIH=2/CID=3 is still in LoginOpNegotiation > stage, > > > and the initiator starts another connection with the same > > > ISID/TSIH/CID, what is the target supposed to do? Does > 'connection > > > reinstatement' apply also to a connection which is not yet in > FFP? > > > > > > My inclination is for the target to consider the second login > > > request as spurious, and to return NotEnoughResources (since I > > > am unwilling to dedicate two 'new connection' slots to the same > > > ISID/TSIH/CID combination). > > > > > > > > > I cannot find any text in the iSCSI spec that unambiguously > addresses > > > these issues. Am I missing anything? If not, would any of the > > > authors care to give guidance? > > > > > > Thanks in advance for any help. > > > -- > > > Joe Pittman > > > jpittman@netapp.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 > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 8 19:41:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20608 for ; Thu, 8 Jan 2004 19:41:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aekhm-00074k-N5 for ips-archive@odin.ietf.org; Thu, 08 Jan 2004 19:40:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i090eohQ027195 for ips-archive@odin.ietf.org; Thu, 8 Jan 2004 19:40:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aekhm-00074Y-G8 for ips-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 19:40:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20550 for ; Thu, 8 Jan 2004 19:40:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aekhk-0003fs-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 19:40:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aekfv-0003YS-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 19:38:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AekeE-0003SY-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 19:37:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeke7-0006dn-4R; Thu, 08 Jan 2004 19:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aekdr-0006cP-1q for ips@optimus.ietf.org; Thu, 08 Jan 2004 19:36:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20451 for ; Thu, 8 Jan 2004 19:36:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aekdp-0003Qt-00 for ips@ietf.org; Thu, 08 Jan 2004 19:36:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aekc3-0003Kr-00 for ips@ietf.org; Thu, 08 Jan 2004 19:34:57 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1AekaQ-0003EU-00 for ips@ietf.org; Thu, 08 Jan 2004 19:33:14 -0500 Received: from rosemail.rose.hp.com (postal.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id 02A241C002AF; Thu, 8 Jan 2004 19:33:11 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bea179.rose.hp.com [15.23.140.179]) by rosemail.rose.hp.com (Postfix) with ESMTP id CA3C97FFA; Thu, 8 Jan 2004 16:30:10 -0800 (PST) Message-ID: <3FFDF6BC.7040201@rose.hp.com> Date: Thu, 08 Jan 2004 16:33:00 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wrstuden@wasabisystems.com, ips@ietf.org Subject: Re: [Ips] iSCSI: When does a connection become part of a session? References: <3FFB69AB.4090302@rose.hp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >Also, our target expects StatSN (and > ExpStatSN) to be handled correctly even in login. As StatSN is > connection-specific, I see no session nor security problems > with this. :-) Agreed. > Does anyone see a security implication of the target leaking MaxCmdSN and > ExpCmdSN? I think inadvertent revealing of current ExpCmdSN even before the security negotiation stage allows an attacker to gain insights into traffic volumes - he can periodically use this to get snapshots of the ExpCmdSN value. >We take a third approach. If we don't already have MaxConnections + 2 > connections in FFP and in login, we let a new login proceed. OK, this is one implementation approach. I see this as a superset of the required behavior I described. >If we didn't > do something like this, then if you had a session with MaxConnections > connections, you could not do any ERL 2 recovery. Not necessarily. I'd think if a TCP connection for CID=x is dead from the initiator's perspective, the initiator can Logout CID=x on a connection with CID=y, and do a task reassign for all tasks active on CID=x. If MaxConnections=1 and connection recovery is supported and the target thinks the connection is still up though initiator thinks it's dead, it would have to adopt an approach like yours. My recollection is that the iSCSI spec in 3.2.1 says the following for the same reason. "For error recovery purposes, targets and initiators that support a single active connection in a session SHOULD support two connections during recovery." Mallikarjun wrstuden@wasabisystems.com wrote: > On Tue, 6 Jan 2004, Mallikarjun C. wrote: > > >>Let me attempt to answer Joe's questions and clarify >>a couple of Pat's points. > > > And I'll comment on your comments. :-) > > >>On Joe's #1, I agree with Pat's comments - there is no >>need to return valid values of sequence numbers before >>the final successful login reponse. > > > Note: Joe was talking about MaxCmdSN and ExpCmdSN, and I agree there is > some question about them. However you mentioned "sequence numbers", which > can be taken to include StatSN too. As best I can tell, StatSN needs to be > present and respected at all times. Also, our target expects StatSN (and > ExpStatSN) to be handled correctly even in login. As StatSN is > connection-specific, I see no session nor security problems with this. :-) > > I think perhaps we should split this question into two questions. 1) what > should the target put into MaxCmdSN and ExpCmdSN (and the initiator into > CmdSN), and 2) what should the target (or initiator) do with the CmdSN > (MaxCmdSN and ExpCmdSN) value(s) it gets. > > I think (2) is the more important. I think both the initiator and target > should ignore CmdSN, MaxCmdSN, and ExpCmdSN on PDUs other than the last > one. For the initial login and for session reinstatement, I think the > CmdSN on the last Login Request (the one that triggers the transition to > FFP) should seed the target's idea of ExpCmdSN (and thus MaxCmdSN). Other > than that, I think it should be ignored. As login commands are immediate, > that makes sense. > > As for (1), I think you're supposed to be shoving good values into the > response. Our target does. However with (2) in place, it wouldn't hurt if > the target just returned zero. > > Does anyone see a security implication of the target leaking MaxCmdSN and > ExpCmdSN? > > >>On Joe's #2, Joe said: >> "My inclination is to only consider the connection to be part of the >> connection when it has successfully completed the entire login >> sequence, and thus do connection reinstatement just prior to sending >> the last login response." >> >>This is indeed the intent. Connection reinstatement >>should be performed only when the target is ready to >>signal the final approval for the login attempt on the >>connection in question. A target cannot perform the >>reinstatement for an old CID instance unless it arrived >>at a new FFP connection with the same CID (clearly, I >>think, stated in 5.3.4), i.e. unless login process is >>successfully complete for the new instance. > > > Agreed. > > Actually, we have two levels of session membership. One is "full" which a > connection gets when it goes to FFP. This is what everyone thinks of for > connections being in a session. > > The other is a tentative membership, which we give new connections that > are members of an existing session. This isn't really covered in the spec. > We do this mainly so that we can limit the number of connections tied to a > session, and protect ourselves from DoS attacks. A connection in this > state can see what's happening in the session (it reports MaxCmdSN and > ExpCmdSN), but it can't impact the session. This is how we send back valid > MaxCmdSN and ExpCmdSN. > > You can only have MaxConnections connections in FFP, and MaxConnections + > a fudge factor (currently 2) connections in FFP and in login. > > >>On Joe's #3, the general approach should be to allow >>new login attempts to proceed as long as the total >>number of connections is < MaxConnections. At the >>time the target moves a connection to FFP, it should >>consider any earlier instance of the same CID to have >>been reinstated and drop the old instance (10.12.7). >>I thus would not recommend the approach you're leaning >>towards. Note however that the 10.12.7 text assumes >>that the initiator is well-behaved - if the initiator >>is in fact launching multiple login requests at the >>same time for the same CID, then it's violating the MUST >>requirement in 10.12.7 - "The initiator connection >>state MUST be CLEANUP_WAIT (section 7.1.3) when the >>initiator attempts a connection reinstatement." > > > We take a third approach. If we don't already have MaxConnections + 2 > connections in FFP and in login, we let a new login proceed. If we didn't > do something like this, then if you had a session with MaxConnections > connections, you could not do any ERL 2 recovery. > > We let the second (connection reinstatement) login attempt proceed as > well. When ever either of them reaches FFP, both the original connection > and the login that hasn't completed login get killed. > > Yes, this is a violation in that the initiator appears to be violating > 10.12.7. However if something went wrong with one reinstatement attempt, > we might get to this situation. > > >>On Pat's points - >> >> > "Successful connection/session reinstatement" might be >> > read to mean that the login for the new session successfully >> > completed rather than just a login request was received. >> >>Yes, as clarified above. > > > Agreed. It all happens at the end of login processing, just before the PDU > is sent indicating we're going to FFP. > > >> >However note that a failed connection >> > reinstatement causes T15 which moves the session from LOGGED_IN to >> > CLEANUP_WAIT so a failed attempt would still disrupt an active >> > connection. >> >>True, that was intended. However, there are two state >>machines here (CSM-C and CSM-I, borrowing 7.2 terminology), >>and note that Pat's clarification applies to CSM-C (i.e. >>the state machine representing the old instance). The CSM-I, >>the new state machine the login is happening on, OTOH, >>takes the T7 transition from IN_LOGIN to FREE. >> >>A "failed connection reinstatement", however, should have >>been defined in the spec (as Pat says). For a connection >>reinstatement effort to be considered "failed" and thus >>cause a state change to CSM-C on the target end, the effort >>should have progressed (and failed) beyond the SecurityNegotiation >>stage. Ditto for session reinstatement. > > > Take care, > > 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 exim@www1.ietf.org Thu Jan 8 20:19:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21401 for ; Thu, 8 Jan 2004 20:19:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AelIL-0000D5-Pw for ips-archive@odin.ietf.org; Thu, 08 Jan 2004 20:18:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i091IbKP000808 for ips-archive@odin.ietf.org; Thu, 8 Jan 2004 20:18:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AelIL-0000Cw-IY for ips-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 20:18:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21322 for ; Thu, 8 Jan 2004 20:18:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AelIJ-0005al-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 20:18:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AelGO-0005Sa-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 20:16:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AelFD-0005Kw-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 20:15:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AelEs-0008If-EW; Thu, 08 Jan 2004 20:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AelDy-0008Bk-Ou for ips@optimus.ietf.org; Thu, 08 Jan 2004 20:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21215 for ; Thu, 8 Jan 2004 20:14:04 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AelDr-0005Ht-00 for ips@ietf.org; Thu, 08 Jan 2004 20:13:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ael8E-00050q-00 for ips@ietf.org; Thu, 08 Jan 2004 20:08:11 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Ael5I-0004qA-00 for ips@ietf.org; Thu, 08 Jan 2004 20:05:08 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id E521C40138; Thu, 8 Jan 2004 20:04:40 -0500 (EST) Date: Thu, 8 Jan 2004 17:00:32 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Mallikarjun C." Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: When does a connection become part of a session? In-Reply-To: <3FFDF6BC.7040201@rose.hp.com> Message-ID: References: <3FFB69AB.4090302@rose.hp.com> <3FFDF6BC.7040201@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Thu, 8 Jan 2004, Mallikarjun C. wrote: > >Also, our target expects StatSN (and > > ExpStatSN) to be handled correctly even in login. As StatSN is > > connection-specific, I see no session nor security problems > > with this. :-) > > Agreed. > > > Does anyone see a security implication of the target leaking MaxCmdSN and > > ExpCmdSN? > > I think inadvertent revealing of current ExpCmdSN even before the > security negotiation stage allows an attacker to gain insights > into traffic volumes - he can periodically use this to get > snapshots of the ExpCmdSN value. I think I agree with you and Joseph (private EMail) that it would be advantageous to not expost ExpCmdSN & MaxCmdSN. Unfortunately the spec requires their inclusion at present. :-| > >We take a third approach. If we don't already have MaxConnections + 2 > > connections in FFP and in login, we let a new login proceed. > > OK, this is one implementation approach. I see this as a > superset of the required behavior I described. Yes, it's a superset. Oh, as for why it's + 2 as opposed to + 1 is a bit of over-conservativism on my part. :-) > >If we didn't > > do something like this, then if you had a session with MaxConnections > > connections, you could not do any ERL 2 recovery. > > Not necessarily. I'd think if a TCP connection for CID=x is dead from > the initiator's perspective, the initiator can Logout CID=x on a I had in mind the case where you had MaxConnections connections and they all died. Yes, it's extreme. > connection with CID=y, and do a task reassign for all tasks active > on CID=x. If MaxConnections=1 and connection recovery is supported > and the target thinks the connection is still up though initiator > thinks it's dead, it would have to adopt an approach like yours. > My recollection is that the iSCSI spec in 3.2.1 says the following > for the same reason. > > "For error recovery purposes, targets and initiators > that support a single active connection in a session > SHOULD support two connections during recovery." Yep. That's why we came up with permitting a little more than MaxConnections connections. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 8 20:19:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21419 for ; Thu, 8 Jan 2004 20:19:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AelId-0000Ea-1K for ips-archive@odin.ietf.org; Thu, 08 Jan 2004 20:18:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i091IsdA000894 for ips-archive@odin.ietf.org; Thu, 8 Jan 2004 20:18:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AelIb-0000EL-Us for ips-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 20:18:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21372 for ; Thu, 8 Jan 2004 20:18:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AelIZ-0005dJ-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 20:18:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AelGn-0005WY-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 20:17:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AelFo-0005Ox-00 for ips-web-archive@ietf.org; Thu, 08 Jan 2004 20:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AelFp-0008QY-PV; Thu, 08 Jan 2004 20:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AelFk-0008Pp-GW for ips@optimus.ietf.org; Thu, 08 Jan 2004 20:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21243 for ; Thu, 8 Jan 2004 20:15:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AelFi-0005Nn-00 for ips@ietf.org; Thu, 08 Jan 2004 20:15:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AelDb-0005Gw-00 for ips@ietf.org; Thu, 08 Jan 2004 20:13:45 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1Ael9D-00053Q-00 for ips@ietf.org; Thu, 08 Jan 2004 20:09:12 -0500 Received: from rosemail.rose.hp.com (postal.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 128821C010DD; Thu, 8 Jan 2004 20:08:42 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bea179.rose.hp.com [15.23.140.179]) by rosemail.rose.hp.com (Postfix) with ESMTP id CEC497FFA; Thu, 8 Jan 2004 17:05:41 -0800 (PST) Message-ID: <3FFDFF10.4070305@rose.hp.com> Date: Thu, 08 Jan 2004 17:08:32 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Robert D. Russell" Cc: Eddy Quicksall , ips@ietf.org Subject: Re: [Ips] iSCSI: When does a connection become part of a session? References: <3FFB69AB.4090302@rose.hp.com> <000801c3d570$b00aff30$0303a8c0@ivvt2dxrc11> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bob, >the current standard requires that the > target fill in MaxCmdSN and ExpCmdSN with valid values on all > Login Response PDUs that it sends. I don't see "all", but as someone pointed out earlier, the closest to this formulation is what I find in 10.13.5 - "The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if Status-Class is 0." I think a) there's a minor security exposure in revealing ExpCmdSN (as I said in an earler email), b) initiator has no reason to check/depend on ExpCmdSN from the first Login. I am not suggesting that we require changes in some implementations - the spec isn't that explicit (no MUST/SHOULD either way) to require changes. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Robert D. Russell wrote: > Mallikarjan: > > I agree with Eddy and Bill -- the current standard requires that the > target fill in MaxCmdSN and ExpCmdSN with valid values on all > Login Response PDUs that it sends. To do otherwise violates the > standard and is potentially not interoperable with an arbitrary > initiator. However, applying the philosophy of "conservative in > what you send, liberal in what you receive", there is no apparent > reason for the initiator to check these values if it doesn't want to, > and not checking them will not violate the standard. > > Bob Russell > > > >>For case #1, that seems like a good idea but I don't think the spec says >>this. >> >>If an initiator is using MaxCmdSN and ExpCmdSN to update internal registers, >>then suddenly forcing them to 0 may cause problems in current >>implementations. >> >>Eddy >> >>----- Original Message ----- >>From: "Mallikarjun C." >>To: >>Cc: ; >>Sent: Tuesday, January 06, 2004 9:06 PM >>Subject: Re: [Ips] iSCSI: When does a connection become part of a session? >> >> >> >>>Let me attempt to answer Joe's questions and clarify >>>a couple of Pat's points. >>> >>>On Joe's #1, I agree with Pat's comments - there is no >>>need to return valid values of sequence numbers before >>>the final successful login reponse. >>> >>>On Joe's #2, Joe said: >>> "My inclination is to only consider the connection to be part of the >>> connection when it has successfully completed the entire login >>> sequence, and thus do connection reinstatement just prior to sending >>> the last login response." >>> >>>This is indeed the intent. Connection reinstatement >>>should be performed only when the target is ready to >>>signal the final approval for the login attempt on the >>>connection in question. A target cannot perform the >>>reinstatement for an old CID instance unless it arrived >>>at a new FFP connection with the same CID (clearly, I >>>think, stated in 5.3.4), i.e. unless login process is >>>successfully complete for the new instance. >>> >>>On Joe's #3, the general approach should be to allow >>>new login attempts to proceed as long as the total >>>number of connections is < MaxConnections. At the >>>time the target moves a connection to FFP, it should >>>consider any earlier instance of the same CID to have >>>been reinstated and drop the old instance (10.12.7). >>>I thus would not recommend the approach you're leaning >>>towards. Note however that the 10.12.7 text assumes >>>that the initiator is well-behaved - if the initiator >>>is in fact launching multiple login requests at the >>>same time for the same CID, then it's violating the MUST >>>requirement in 10.12.7 - "The initiator connection >>>state MUST be CLEANUP_WAIT (section 7.1.3) when the >>>initiator attempts a connection reinstatement." >>> >>>On Pat's points - >>> >>> > "Successful connection/session reinstatement" might be >>> > read to mean that the login for the new session successfully >>> > completed rather than just a login request was received. >>> >>>Yes, as clarified above. >>> >>> >However note that a failed connection >>> > reinstatement causes T15 which moves the session from LOGGED_IN to >>> > CLEANUP_WAIT so a failed attempt would still disrupt an active >>> > connection. >>> >>>True, that was intended. However, there are two state >>>machines here (CSM-C and CSM-I, borrowing 7.2 terminology), >>>and note that Pat's clarification applies to CSM-C (i.e. >>>the state machine representing the old instance). The CSM-I, >>>the new state machine the login is happening on, OTOH, >>>takes the T7 transition from IN_LOGIN to FREE. >>> >>>A "failed connection reinstatement", however, should have >>>been defined in the spec (as Pat says). For a connection >>>reinstatement effort to be considered "failed" and thus >>>cause a state change to CSM-C on the target end, the effort >>>should have progressed (and failed) beyond the SecurityNegotiation >>>stage. Ditto for session reinstatement. >>> >>>Hope that helps. >>>-- >>>Mallikarjun >>> >>>Mallikarjun Chadalapaka >>>Networked Storage Architecture >>>Network Storage Solutions >>>Hewlett-Packard MS 5668 >>>Roseville CA 95747 >>>cbm [at] rose.hp.com >>> >>> >>> >>> >>> >>>pat_thaler@agilent.com wrote: >>> >>> >>>>Joe, >>>> >>>>You raise interesting questions. For the first two items, I think I >>>>agree that your inclinations are sensible though not necessarily >>>>supported in the iSCSI draft. On the third one, I'm not sure. >>>> >>>>On 1 - treatment of MaxCmdSN and ExpCmdSN during login, it would make >>>>sense to withhold valid values for these fields at least until the >>>>security phase of Login has completed and there doesn't seem to be any >>>>reason to provide them before the last login. However, I don't find >>>>anything in the spec that supports doing this. Under the description of >>>>status class for Login Response, it says >>>> >>>>The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if >>>>Status-Class is 0. >>>> >>>>which implies that the fields are valid when Status-Class is 0 including >>>>during the security phase. >>>> >>>>On 2 - at what point in a connection reinstatement login does the old >>>>connection get closed, 5.3.4 >>>> >>>>The Login request performs the logout function of the old connection if >>>>an explicit logout was not performed earlier. >>>> >>>>which appears to indicate that it is the reception of the initial Login >>>>Request PDU that causes the logout. As you suggest, actually operating >>>>this way would leave one vulnerable to denial of service type attacks. >>>>It makes more sense to wait until at least security phase has completed >>>>to do the logout. It may make sense to wait to do close the old >>>>connection until ready to send the final login response as you suggest >>>>because this login may not succeed. However for resource constrained >>>>implementations the reinstated connection may need resources allocated >>>>to the existing connection. >>>> >>>>The state machine description might be hoped to provide more detail, but >>>>they don't seem to be entirely consistant. The definition in 7.1.2 for >>>>T8, (T13 and T18 have similar text) >>>> >>>>-target: An internal event of sending a Logout response (success) on >>>>another connection for a "close the session" Logout request was >>>>received, or an internal event of a successful connection/session >>>>reinstatement is received, thus prompting the target to close this >>>>connection cleanly. >>>> >>>>"Successful connection/session reinstatement" might be read to mean that >>>>the login for the new session successfully completed rather than just a >>>>login request was received. However note that a failed connection >>>>reinstatement causes T15 which moves the session from LOGGED_IN to >>>>CLEANUP_WAIT so a failed attempt would still disrupt an active >>>>connection. There doesn't seem to be any definition provided for >>>>successful and failed connection reinstatement. In the description of >>>>connection cleanup state transitions (7.2.2, M4) successful implicit >>>>logout appears to be defined as having reached the state LOGGED_IN on >>>>the new connection. >>>> >>>> On 3, I think connection reinstatement only applies to a connection >>>>that has completed login. The state transitions for the target >>>>connection state machine only allow for implicit logout in the LOGGED_IN >>>>state and in the states that follow it. The transition from IN_LOGIN to >>>>FREE, T4, doesn't make any mention of implicit logout or connection >>>>reinstatement. Time out or the transport going away are the things that >>>>get you from IN_LOGIN to FREE. One might get a second login attempt if >>>>there was a problem on the initial connection such as the network >>>>going down but it is probably okay to not accept it until the original >>>>attempt has disappeared due to time out or closure of the transport >>>>connection. Lack of resources would be a reasonable response. If one >>>>does have the resources, I'm not sure it is a necessary response. >>>> >>>>Regards, >>>> >>>>Pat >>>> >>>> -----Original Message----- >>>>From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of >>>>Pittman, Joseph >>>>Sent: Tuesday, January 06, 2004 1:02 PM >>>>To: ips@ietf.org >>>>Subject: [Ips] iSCSI: When does a connection become part of a session? >>>> >>>> I'm working on adding support for multi-connection sessions to an >>>> iSCSI target implementation, and I have some questions about when >>>> a new connection is considered to be part of a session. >>>> >>>> Consider this set of login request/response exchanges. Assume >>>> that there already exists a session with ISID=1/TSIH=2 on the >>>> target, so the initiator is trying to add a connection to an >>>> existing session. The session is operating at ErrorRecoveryLevel=2, >>>> and there already exists a connection with CID=3 within that >>>> session, so connection reinstatement is required. >>>> >>>> Initiator sends Target responds >>>> ------------------------- >>>> -------------------------- >>>> Exchange 0 LOGIN_REQ LOGIN_RESP >>>> ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, >>>> CID=3 >>>> CSG=0, T=0 CSG=0, T=0 >>>> AuthMethod=CHAP AuthMethod=CHAP >>>> >>>> ** Connection now in SecurityNegotiation phase >>>> >>>> Exchange 1 LOGIN_REQ LOGIN_RESP >>>> ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, >>>> CID=3 >>>> CSG=0, T=0 CSG=0, T=0 >>>> CHAP_A=5 CHAP_A=5 >>>> CHAP_I=x >>>> CHAP_C=x >>>> >>>> Exchange 2 LOGIN_REQ LOGIN_RESP >>>> ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, >>>> CID=3 >>>> CSG=0, T=1, NSG=1 CSG=0, T=1, >> >>NSG=1 >> >>>> CHAP_R=x >>>> CHAP_N=x >>>> >>>> ** Connection now in LoginOperationalNegotiation phase >>>> >>>> >>>> Exchange 3 LOGIN_REQ >>>> ISID=1, TSIH=2, CID=3 ISID=1, TSIH=2, >>>> CID=3 >>>> CSG=1, T=1, NSG=3 CSG=1, T=1, >> >>NSG=3 >> >>>> MaxRecvDSegLen=xxx >> >>MaxRecvDSegLen=xxx >> >>>> ** Connection now in FullFeaturePhase phase >>>> ** Connection has been added to the session ISID=1/TSIH=2 >>>> ** Previous connection ISID=1/TSIH=2/CID=3 has been logged out for >>>> recovery >>>> >>>> >>>> Given this example, here are a few questions: >>>> >>>> 1) When is the target supposed to consider the connection as part of >>>> the session, for the purposes of the response ExpCmdSN and >> >>MaxCmdSN >> >>>> fields? >>>> >>>> In general, the ExpCmdSN and MaxCmdSN fields contain information >>>> about the current command window for a session. But when does >> >>the >> >>>> target consider the connection to be part the session: >>>> >>>> - Before security negotiation is complete? If true, then this >>>> tells a spoofing initiator (who will eventually fail >>>> authentication) >>>> about the presence of a connection by the initiator being >> >>spoofed >> >>>> - After security negotiation is complete? >>>> >>>> - Only in the last login response/transition to FFP? >>>> >>>> My inclination is to only consider the connection to be part of >> >>the >> >>>> connection when it has successfully completed the entire login >>>> sequence, and thus to return the joined session's ExpCmdSN and >>>> MaxCmdSN only in the last login response. >>>> >>>> >>>> 2) When is the target supposed to perform the connection >> >>reinstatement >> >>>> algorithm, including the implicit logout for recovery of the >>>> existing ISID=1/TSIH=2/CID=3 connection? >>>> >>>> - Before security negotiation is complete? Surely not, because >>>> this allows a denial of service attack. >>>> >>>> - After security negotiation is complete? >>>> >>>> - Just before sending the last login response/transition to FFP? >>>> >>>> My inclination is to only consider the connection to be part of >> >>the >> >>>> connection when it has successfully completed the entire login >>>> sequence, and thus do connection reinstatement just prior to >> >>sending >> >>>> the last login response. >>>> >>>> 3) Here's a more esoteric question: if the login sequence for one >>>> connection ISID=1/TSIH=2/CID=3 is still in LoginOpNegotiation >> >>stage, >> >>>> and the initiator starts another connection with the same >>>> ISID/TSIH/CID, what is the target supposed to do? Does >> >>'connection >> >>>> reinstatement' apply also to a connection which is not yet in >> >>FFP? >> >>>> My inclination is for the target to consider the second login >>>> request as spurious, and to return NotEnoughResources (since I >>>> am unwilling to dedicate two 'new connection' slots to the same >>>> ISID/TSIH/CID combination). >>>> >>>> >>>> I cannot find any text in the iSCSI spec that unambiguously >> >>addresses >> >>>> these issues. Am I missing anything? If not, would any of the >>>> authors care to give guidance? >>>> >>>> Thanks in advance for any help. >>>> -- >>>> Joe Pittman >>>> jpittman@netapp.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 >> _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 9 10:38:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06386 for ; Fri, 9 Jan 2004 10:38:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeyhc-0003Ni-2B for ips-archive@odin.ietf.org; Fri, 09 Jan 2004 10:37:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09FbZrf012985 for ips-archive@odin.ietf.org; Fri, 9 Jan 2004 10:37:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeyha-0003NB-Bd for ips-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 10:37:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06216 for ; Fri, 9 Jan 2004 10:37:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeyhX-0000ct-00 for ips-web-archive@ietf.org; Fri, 09 Jan 2004 10:37:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeyfn-0000Od-00 for ips-web-archive@ietf.org; Fri, 09 Jan 2004 10:35:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeyeM-00007M-00 for ips-web-archive@ietf.org; Fri, 09 Jan 2004 10:34:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeyeA-0002eR-GI; Fri, 09 Jan 2004 10:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeydN-0002RO-DO for ips@optimus.ietf.org; Fri, 09 Jan 2004 10:33:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05005 for ; Fri, 9 Jan 2004 10:33:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeydJ-0007nS-01 for ips@ietf.org; Fri, 09 Jan 2004 10:33:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeyIg-0006Za-00 for ips@ietf.org; Fri, 09 Jan 2004 10:11:51 -0500 Received: from ns.equallogic.com ([66.155.203.134] helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1AeyDA-0006GB-00 for ips@ietf.org; Fri, 09 Jan 2004 10:06:08 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i09F5C6a015562 for ; Fri, 9 Jan 2004 10:05:12 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i09F5CIg015557; Fri, 9 Jan 2004 10:05:12 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id i09F5AG25702; Fri, 9 Jan 2004 10:05:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16382.49958.497059.306729@gargle.gargle.HOWL> Date: Fri, 9 Jan 2004 10:05:10 -0500 From: Paul Koning To: cbm@rose.hp.com Cc: wrstuden@wasabisystems.com, ips@ietf.org Subject: Re: [Ips] iSCSI: When does a connection become part of a session? References: <3FFB69AB.4090302@rose.hp.com> <3FFDF6BC.7040201@rose.hp.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Mallikarjun" == Mallikarjun C writes: >> Also, our target expects StatSN (and ExpStatSN) to be handled >> correctly even in login. As StatSN is connection-specific, I see >> no session nor security problems with this. :-) Mallikarjun> Agreed. >> Does anyone see a security implication of the target leaking >> MaxCmdSN and ExpCmdSN? Mallikarjun> I think inadvertent revealing of current ExpCmdSN even Mallikarjun> before the security negotiation stage allows an attacker Mallikarjun> to gain insights into traffic volumes - he can Mallikarjun> periodically use this to get snapshots of the ExpCmdSN Mallikarjun> value. Traffic analysis is probably more easily done by watching existing connections than by active attack. But I'd agree that this is possible. The other issue, I think, is that ExpCmdSN is one of the pieces of state you need to succeed in connection hijacking. For that reason, it would be better not to reveal it until authentication is done. As a design principle, it would make sense to say that the security handshake portion of the login procedures contains NOTHING other than the data required for the security machinery. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 9 12:35:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16428 for ; Fri, 9 Jan 2004 12:35:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0Xe-0001SL-ND for ips-archive@odin.ietf.org; Fri, 09 Jan 2004 12:35:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09HZQPR005587 for ips-archive@odin.ietf.org; Fri, 9 Jan 2004 12:35:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0Xc-0001Rx-H8 for ips-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 12:35:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16337 for ; Fri, 9 Jan 2004 12:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af0Xa-0002Lu-00 for ips-web-archive@ietf.org; Fri, 09 Jan 2004 12:35:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af0Tx-0001Wj-00 for ips-web-archive@ietf.org; Fri, 09 Jan 2004 12:31:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af0PX-0000n0-00 for ips-web-archive@ietf.org; Fri, 09 Jan 2004 12:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0PU-0000NH-Mw; Fri, 09 Jan 2004 12:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0Oe-0000DB-Vg for ips@optimus.ietf.org; Fri, 09 Jan 2004 12:26:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15218 for ; Fri, 9 Jan 2004 12:26:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af0Od-0000jf-00 for ips@ietf.org; Fri, 09 Jan 2004 12:26:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af0Mx-0000Yw-00 for ips@ietf.org; Fri, 09 Jan 2004 12:24:24 -0500 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1Af0Kx-00005I-00 for ips@ietf.org; Fri, 09 Jan 2004 12:22:19 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (rwcrmhc11) with SMTP id <2004010917214801300ihhd2e> (Authid: esquicksall); Fri, 9 Jan 2004 17:21:49 +0000 Message-ID: <001c01c3d6d5$10afca40$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Paul Koning" , Cc: , References: <3FFB69AB.4090302@rose.hp.com><3FFDF6BC.7040201@rose.hp.com> <16382.49958.497059.306729@gargle.gargle.HOWL> Subject: Re: [Ips] iSCSI: When does a connection become part of a session? Date: Fri, 9 Jan 2004 12:21:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It seems that everyone agrees that ExpCmdSN and MaxCmdSN should not be reported during security stage. But the spec does not say that and does not even imply that. I think there needs to be an errata to the spec to specifically say this. Eddy ----- Original Message ----- From: "Paul Koning" To: Cc: ; Sent: Friday, January 09, 2004 10:05 AM Subject: Re: [Ips] iSCSI: When does a connection become part of a session? > >>>>> "Mallikarjun" == Mallikarjun C writes: > > >> Also, our target expects StatSN (and ExpStatSN) to be handled > >> correctly even in login. As StatSN is connection-specific, I see > >> no session nor security problems with this. :-) > > Mallikarjun> Agreed. > > >> Does anyone see a security implication of the target leaking > >> MaxCmdSN and ExpCmdSN? > > Mallikarjun> I think inadvertent revealing of current ExpCmdSN even > Mallikarjun> before the security negotiation stage allows an attacker > Mallikarjun> to gain insights into traffic volumes - he can > Mallikarjun> periodically use this to get snapshots of the ExpCmdSN > Mallikarjun> value. > > Traffic analysis is probably more easily done by watching existing > connections than by active attack. But I'd agree that this is > possible. > > The other issue, I think, is that ExpCmdSN is one of the pieces of > state you need to succeed in connection hijacking. For that reason, > it would be better not to reveal it until authentication is done. > > As a design principle, it would make sense to say that the security > handshake portion of the login procedures contains NOTHING other than > the data required for the security machinery. > > paul > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Jan 9 15:37:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12642 for ; Fri, 9 Jan 2004 15:37:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3N0-0005YO-GU for ips-archive@odin.ietf.org; Fri, 09 Jan 2004 15:36:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09Kac3D021348 for ips-archive@odin.ietf.org; Fri, 9 Jan 2004 15:36:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3N0-0005YF-Bv for ips-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 15:36:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12246 for ; Fri, 9 Jan 2004 15:36:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3Mu-0002wS-00 for ips-web-archive@ietf.org; Fri, 09 Jan 2004 15:36:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af3Il-0001lA-00 for ips-web-archive@ietf.org; Fri, 09 Jan 2004 15:32:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af3By-0000Ha-00 for ips-web-archive@ietf.org; Fri, 09 Jan 2004 15:25:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Bn-0004Lg-Lo; Fri, 09 Jan 2004 15:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Az-0004E0-U3 for ips@optimus.ietf.org; Fri, 09 Jan 2004 15:24:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08532 for ; Fri, 9 Jan 2004 15:24:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3Ay-0007hJ-00 for ips@ietf.org; Fri, 09 Jan 2004 15:24:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af2a8-0001QH-00 for ips@ietf.org; Fri, 09 Jan 2004 14:46:13 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1Af1q7-0007Tj-00 for ips@ietf.org; Fri, 09 Jan 2004 13:58:35 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (rwcrmhc12) with SMTP id <2004010918573801400pb893e> (Authid: esquicksall); Fri, 9 Jan 2004 18:57:38 +0000 Message-ID: <004301c3d6e2$73c43fa0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: References: Subject: Re: [Ips] iSCSI: a Reject during text negotiations Date: Fri, 9 Jan 2004 13:57:37 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C3D6B8.8A53CC60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C3D6B8.8A53CC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It was determined by previous EMAIL's on this thread that a text = negotiation reset (TTT=3D0xFFFFFFFF) only effects the ITT that is being = reset. But now I'm wondering if that was the intent of the reset. Consider the = following: I->T text request, ITT=3D8F, TTT=3DFFFFFFFF, F=3D0 T->I text response, ITT=3D8F, F=3D0 I->T text request, ITT=3D8C, TTT=3DFFFFFFFF (a reset) Does the TTT=3DFFFFFFFF reset everything such that 8F is killed too or = does it reset task 8C only? When I first read the reset description, I thought the intent was a way = for the initiator to have a clean start during a text negotiation.=20 If it only resets task 8C but the initiator never finishes task 8F, what = should the target do? In this case, what practical use does the reset = have? Does the task just remain outstanding until the initiator sends the F = bit for task 8F? Is this another case for Time2Retain? Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Sunday, January 04, 2004 5:08 AM Subject: Re: [Ips] iSCSI: a Reject during text negotiations Eddy,=20 The sequence is valid.=20 On the other hand since the initiator missbehaves (has two outstanding = text requests) the target may choose (and still be compliant) to = completely reset the session etc.=20 Julo=20 "Eddy Quicksall" =20 03/01/2004 01:07=20 To Julian Satran/Haifa/IBM@IBMIL =20 cc =20 Subject Re: [Ips] iSCSI: a Reject during text negotiations = =20 =20 Julian, Could I have misunderstood you? This interpretation seems to make = sense. Here is the example: I->T, ITT=3Dx, TTT=3DFFFFFFFF, MaxRecvDataSegmentLength=3D512, F=3D0 T->I, ITT=3Dx, TTT=3D00000001, F=3D0 I->T, ITT=3Dy, TTT=3DFFFFFFFF, F=3D1 T->I Reject (MaxRecvDataSegmentLength not changed yet) I->T, ITT=3Dx, TTT=3D00000001, F=3D1 T->I, ITT=3Dx, TTT=3DFFFFFFFF, F=3D1 (MaxRecvDataSegmentLength is now = 512) Eddy ------=_NextPart_000_0040_01C3D6B8.8A53CC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It was determined by previous EMAIL's on this thread = that a=20 text negotiation reset (TTT=3D0xFFFFFFFF) only effects the ITT that is = being=20 reset.
 
But now I'm wondering if that was the intent of the = reset.=20 Consider the following:
 
I->T text request, ITT=3D8F, TTT=3DFFFFFFFF, = F=3D0
T->I text response, ITT=3D8F, F=3D0
I->T text request, ITT=3D8C, TTT=3DFFFFFFFF (a=20 reset)
 
Does the TTT=3DFFFFFFFF reset everything such = that 8F=20 is killed too or does it reset task 8C = only?
 
When I first read the reset description, I = thought the=20 intent was a way for the initiator to have a clean start during a = text=20 negotiation.
 
If it only resets task 8C but the initiator never = finishes=20 task 8F, what should the target do? In this case, what practical use = does the=20 reset have?
 
Does the task just remain outstanding until the = initiator=20 sends the F bit for task 8F?
 
Is this another case for Time2Retain?
 
Eddy
 
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Sunday, January 04, 2004 = 5:08=20 AM
Subject: Re: [Ips] iSCSI: a = Reject during=20 text negotiations


Eddy, =

The sequence is valid.
On the other hand since the initiator missbehaves (has two = outstanding=20 text requests) the target may choose (and still be compliant) to = completely=20 reset the session etc.

Julo=20


"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20

03/01/2004 01:07

To
Julian Satran/Haifa/IBM@IBMIL =
cc
<ips@ietf.org>=20
Subject
Re: [Ips] = iSCSI: a=20 Reject during text = negotiations

=




Julian,

Could I have misunderstood you? This = interpretation=20 seems to make sense.

Here is the example:

I->T, = ITT=3Dx,=20 TTT=3DFFFFFFFF, MaxRecvDataSegmentLength=3D512, F=3D0
T->I, = ITT=3Dx,=20 TTT=3D00000001, F=3D0
I->T, ITT=3Dy, TTT=3DFFFFFFFF, = F=3D1
T->I Reject=20 (MaxRecvDataSegmentLength not changed yet)
I->T, ITT=3Dx, = TTT=3D00000001,=20 F=3D1
T->I, ITT=3Dx, TTT=3DFFFFFFFF, F=3D1 = (MaxRecvDataSegmentLength is now=20 512)

Eddy


------=_NextPart_000_0040_01C3D6B8.8A53CC60-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Jan 10 08:50:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05185 for ; Sat, 10 Jan 2004 08:50:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfJVJ-0007Jo-3K for ips-archive@odin.ietf.org; Sat, 10 Jan 2004 08:50:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ADoH8w028127 for ips-archive@odin.ietf.org; Sat, 10 Jan 2004 08:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfJVI-0007Ja-S1 for ips-web-archive@optimus.ietf.org; Sat, 10 Jan 2004 08:50:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05161 for ; Sat, 10 Jan 2004 08:50:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfJVH-0000KG-00 for ips-web-archive@ietf.org; Sat, 10 Jan 2004 08:50:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfJTP-0000Fh-00 for ips-web-archive@ietf.org; Sat, 10 Jan 2004 08:48:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AfJSM-0000BO-00 for ips-web-archive@ietf.org; Sat, 10 Jan 2004 08:47:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfJS9-00075V-JV; Sat, 10 Jan 2004 08:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfJRI-00073k-2T for ips@optimus.ietf.org; Sat, 10 Jan 2004 08:46:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05044 for ; Sat, 10 Jan 2004 08:46:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfJRG-00007q-00 for ips@ietf.org; Sat, 10 Jan 2004 08:46:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfJPL-00001G-00 for ips@ietf.org; Sat, 10 Jan 2004 08:44:08 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1AfJNX-0007hr-00; Sat, 10 Jan 2004 08:42:15 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0ADfVRm075876; Sat, 10 Jan 2004 13:41:31 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0ADfT4i250020; Sat, 10 Jan 2004 14:41:31 +0100 In-Reply-To: <004301c3d6e2$73c43fa0$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Sat, 10 Jan 2004 15:41:27 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/01/2004 15:41:31, Serialize complete at 10/01/2004 15:41:31 Content-Type: multipart/alternative; boundary="=_alternative 0049DFE6C2256E17_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 0049DFE6C2256E17_= Content-Type: text/plain; charset="US-ASCII" Eddy, Evidently you sequence contains 2 pending text comands and the target should reject second I->T (8C) or both. Julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 09/01/2004 20:57 To cc Subject Re: [Ips] iSCSI: a Reject during text negotiations It was determined by previous EMAIL's on this thread that a text negotiation reset (TTT=0xFFFFFFFF) only effects the ITT that is being reset. But now I'm wondering if that was the intent of the reset. Consider the following: I->T text request, ITT=8F, TTT=FFFFFFFF, F=0 T->I text response, ITT=8F, F=0 I->T text request, ITT=8C, TTT=FFFFFFFF (a reset) Does the TTT=FFFFFFFF reset everything such that 8F is killed too or does it reset task 8C only? When I first read the reset description, I thought the intent was a way for the initiator to have a clean start during a text negotiation. If it only resets task 8C but the initiator never finishes task 8F, what should the target do? In this case, what practical use does the reset have? Does the task just remain outstanding until the initiator sends the F bit for task 8F? Is this another case for Time2Retain? Eddy ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ietf.org Sent: Sunday, January 04, 2004 5:08 AM Subject: Re: [Ips] iSCSI: a Reject during text negotiations Eddy, The sequence is valid. On the other hand since the initiator missbehaves (has two outstanding text requests) the target may choose (and still be compliant) to completely reset the session etc. Julo "Eddy Quicksall" 03/01/2004 01:07 To Julian Satran/Haifa/IBM@IBMIL cc Subject Re: [Ips] iSCSI: a Reject during text negotiations Julian, Could I have misunderstood you? This interpretation seems to make sense. Here is the example: I->T, ITT=x, TTT=FFFFFFFF, MaxRecvDataSegmentLength=512, F=0 T->I, ITT=x, TTT=00000001, F=0 I->T, ITT=y, TTT=FFFFFFFF, F=1 T->I Reject (MaxRecvDataSegmentLength not changed yet) I->T, ITT=x, TTT=00000001, F=1 T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512) Eddy --=_alternative 0049DFE6C2256E17_= Content-Type: text/html; charset="US-ASCII"
Eddy,

Evidently you sequence contains 2 pending text comands and the target should reject second I->T (8C) or both.

Julo



"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-admin@ietf.org

09/01/2004 20:57

To
<ips@ietf.org>
cc
Subject
Re: [Ips] iSCSI: a Reject during text negotiations





It was determined by previous EMAIL's on this thread that a text negotiation reset (TTT=0xFFFFFFFF) only effects the ITT that is being reset.
 
But now I'm wondering if that was the intent of the reset. Consider the following:
 
I->T text request, ITT=8F, TTT=FFFFFFFF, F=0
T->I text response, ITT=8F, F=0
I->T text request, ITT=8C, TTT=FFFFFFFF (a reset)
 
Does the TTT=FFFFFFFF reset everything such that 8F is killed too or does it reset task 8C only?
 
When I first read the reset description, I thought the intent was a way for the initiator to have a clean start during a text negotiation.
 
If it only resets task 8C but the initiator never finishes task 8F, what should the target do? In this case, what practical use does the reset have?
 
Does the task just remain outstanding until the initiator sends the F bit for task 8F?
 
Is this another case for Time2Retain?
 
Eddy
 
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Sunday, January 04, 2004 5:08 AM
Subject: Re: [Ips] iSCSI: a Reject during text negotiations


Eddy,

The sequence is valid.
On the other hand since the initiator missbehaves (has two outstanding text requests) the target may choose (and still be compliant) to completely reset the session etc.

Julo

"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

03/01/2004 01:07


To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
Re: [Ips] iSCSI: a Reject during text negotiations







Julian,

Could I have misunderstood you? This interpretation seems to make sense.

Here is the example:

I->T, ITT=x, TTT=FFFFFFFF, MaxRecvDataSegmentLength=512, F=0
T->I, ITT=x, TTT=00000001, F=0
I->T, ITT=y, TTT=FFFFFFFF, F=1
T->I Reject (MaxRecvDataSegmentLength not changed yet)
I->T, ITT=x, TTT=00000001, F=1
T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512)

Eddy
--=_alternative 0049DFE6C2256E17_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Jan 12 00:45:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01375 for ; Mon, 12 Jan 2004 00:45:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afusp-0001n8-FK for ips-archive@odin.ietf.org; Mon, 12 Jan 2004 00:45:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0C5j3MT006883 for ips-archive@odin.ietf.org; Mon, 12 Jan 2004 00:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afusn-0001mn-S3 for ips-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 00:45:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01367 for ; Mon, 12 Jan 2004 00:44:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afusg-0000GF-00 for ips-web-archive@ietf.org; Mon, 12 Jan 2004 00:44:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfuoA-0000A0-00 for ips-web-archive@ietf.org; Mon, 12 Jan 2004 00:40:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AfumR-00005Z-00 for ips-web-archive@ietf.org; Mon, 12 Jan 2004 00:38:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afum0-0001Yb-LK; Mon, 12 Jan 2004 00:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aful4-0001Hl-Q5 for ips@optimus.ietf.org; Mon, 12 Jan 2004 00:37:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01211 for ; Mon, 12 Jan 2004 00:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afukt-00003F-00 for ips@ietf.org; Mon, 12 Jan 2004 00:36:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afugw-000006-00 for ips@ietf.org; Mon, 12 Jan 2004 00:32:47 -0500 Received: from adsl-67-124-61-228.dsl.snfc21.pacbell.net ([67.124.61.228] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1Afueo-0007kp-00 for ips@ietf.org; Mon, 12 Jan 2004 00:30:34 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1AfuUs-0001db-00; Sun, 11 Jan 2004 21:20:18 -0800 Subject: Re: [Ips] iSCSI: When does a connection become part of a session? From: "Nicholas A. Bellinger" To: ips@ietf.org Cc: wrstuden@wasabisystems.com, cbm@rose.hp.com, Andre Hedrick Content-Type: text/plain Message-Id: <1073884805.1239.102.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 11 Jan 2004 21:20:06 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fellow iSCSI Architects, I wanted to bring up a few points in regards to Joseph Pitmann's 2nd topic: "when should Connection Reinstatement occur?", how it applies to the discussion below, and the implementation method we use that does not require connection count to exceed MaxConnections even in the single connection ErrorRecoveryLevel=2 case, and hence makes the passage in section 3.2.1 not apply. "For error recovery purposes, targets and initiators that support a single active connection in a session SHOULD support two connections during recovery." First a couple prerequisites on both sides: Initiator: In an ErrorRecoveryLevel=2 single or multiple connection session, when a connection fails the initiator will attempt to perform connection reinstatement on the failed CID before creating a connection with a new CID. Target: The login process controls how many login attempts are possible on a given session to prevent a DoS attack. End prerequisites. Now, the following order of steps on the target allows MaxConnections to be inforced while still allowing a single connection (as well as multiple, but the main concern Mallikarjun mentioned was the single connection example) ErrorRecoveryLevel=2 session to perform Connection Recovery. In a single connection ErrorRecoveryLevel=2 connection, CID 0 goes into cleanup state from the initiators perspective yet remains active on the Target. The Initiator sends a non zero TSIH login request (CSM-I) with CID 0 to perform Session Continuation by way of Connection Reinstatement (and hence Implict Logout) of the failed connection still active from the Target's perspective (CSM-C). Connection Reinstatement is performed after SecurityNegoitation phase has completed successfuly but before MaxConnections is checked. The ExpStatSN of the initial login request is checked against commands of the connection that was just forced to shutdown (CSM-C) to release those acknowledged by the initiator before the connection failed, then finally the MaxConnection key is checked. At this point we continue to LoginOperationalNegotiation stage. This is the implementation we have used for a period of time and think is the correct method to avoid having to exceed the negoitated MaxConnections key. We have come to the conclusion based primarly on the following point that Pat and Mallikarijun mentioned: >> However note that a failed connection >> reinstatement causes T15 which moves the session from LOGGED_IN to >> CLEANUP_WAIT so a failed attempt would still disrupt an active >> connection. > True, that was intended. However, there are two state > machines here (CSM-C and CSM-I, borrowing 7.2 terminology), > and note that Pat's clarification applies to CSM-C (i.e. > the state machine representing the old instance). The CSM-I, > the new state machine the login is happening on, OTOH, > takes the T7 transition from IN_LOGIN to FREE. > A "failed connection reinstatement", however, should have > been defined in the spec (as Pat says). For a connection > reinstatement effort to be considered "failed" and thus > cause a state change to CSM-C on the target end, the effort > should have progressed (and failed) beyond the SecurityNegotiation > stage. Ditto for session reinstatement. Taking this into account, I see the above order of steps as the desired implementation because when a connection makes it past the point of successful SecurityNeogitation, the existing CID (CSM-C) will be forced into shutdown regardless if CSM-I makes it into Full Feature Phase or not. The other implemenation example(s) that has been discussed so far that requires the connection count to exceed MaxConnections in a single (or multple) connection ErrorRecoveryLevel=2 session roughly follow these steps: Connection Reinstatement happens when the last login response is sent before moving to Full Feature Phase. The MaxConnection key is checked either before or after security negotiation phase, requiring the connection count to temporarily exceed MaxConnections in order to perform Connection Reinstatement before moving to FFP. This is of course legal but IMHO exceeding MaxConnections is generally frowned upon. As mentioned in the prerequisities, an Initiator in a single or multiple connection ErrorRecoveryLevel=2 session should attempt connection reinstatement before starting a new connection with a different CID. So basically in ErrorRecoveryLevel=2, Session Continuation is achieved by performing continuous Connection Reinstatement on failed CIDs and NOT by starting new connections with different CIDs. This is the method that our ErrorRecoveryLevel=2 multiple connection session iSCSI Initiator uses that will be open sourced in the near future. Thanks! -- Nicholas A. Bellinger On Thu, 2004-01-08 at 17:00, wrstuden@wasabisystems.com wrote: > On Thu, 8 Jan 2004, Mallikarjun C. wrote: > > > >Also, our target expects StatSN (and > > > ExpStatSN) to be handled correctly even in login. As StatSN is > > > connection-specific, I see no session nor security problems > > > with this. :-) > > > > Agreed. > > > > > Does anyone see a security implication of the target leaking MaxCmdSN and > > > ExpCmdSN? > > > > I think inadvertent revealing of current ExpCmdSN even before the > > security negotiation stage allows an attacker to gain insights > > into traffic volumes - he can periodically use this to get > > snapshots of the ExpCmdSN value. > > I think I agree with you and Joseph (private EMail) that it would be > advantageous to not expost ExpCmdSN & MaxCmdSN. Unfortunately the spec > requires their inclusion at present. :-| > > > >We take a third approach. If we don't already have MaxConnections + 2 > > > connections in FFP and in login, we let a new login proceed. > > > > OK, this is one implementation approach. I see this as a > > superset of the required behavior I described. > > Yes, it's a superset. > > Oh, as for why it's + 2 as opposed to + 1 is a bit of over-conservativism > on my part. :-) > > > >If we didn't > > > do something like this, then if you had a session with MaxConnections > > > connections, you could not do any ERL 2 recovery. > > > > Not necessarily. I'd think if a TCP connection for CID=x is dead from > > the initiator's perspective, the initiator can Logout CID=x on a > > I had in mind the case where you had MaxConnections connections and they > all died. Yes, it's extreme. > > > connection with CID=y, and do a task reassign for all tasks active > > on CID=x. If MaxConnections=1 and connection recovery is supported > > and the target thinks the connection is still up though initiator > > thinks it's dead, it would have to adopt an approach like yours. > > My recollection is that the iSCSI spec in 3.2.1 says the following > > for the same reason. > > > > "For error recovery purposes, targets and initiators > > that support a single active connection in a session > > SHOULD support two connections during recovery." > > Yep. That's why we came up with permitting a little more than > MaxConnections connections. > > Take care, > > 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 exim@www1.ietf.org Mon Jan 12 10:47:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03088 for ; Mon, 12 Jan 2004 10:47:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4Ha-0000sV-5k for ips-archive@odin.ietf.org; Mon, 12 Jan 2004 10:47:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CFlEkm003371 for ips-archive@odin.ietf.org; Mon, 12 Jan 2004 10:47:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4Ha-0000sI-1G for ips-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 10:47:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02997 for ; Mon, 12 Jan 2004 10:47:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4HX-0000VL-00 for ips-web-archive@ietf.org; Mon, 12 Jan 2004 10:47:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4Fm-0000MV-00 for ips-web-archive@ietf.org; Mon, 12 Jan 2004 10:45:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag4Db-0000DO-00 for ips-web-archive@ietf.org; Mon, 12 Jan 2004 10:43:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4DW-0000Rm-W0; Mon, 12 Jan 2004 10:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4DL-0000P6-8k for ips@optimus.ietf.org; Mon, 12 Jan 2004 10:42:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02647 for ; Mon, 12 Jan 2004 10:42:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4DI-00007t-00 for ips@ietf.org; Mon, 12 Jan 2004 10:42:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag46a-0007gH-00 for ips@ietf.org; Mon, 12 Jan 2004 10:35:53 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1Ag41r-0007OR-00; Mon, 12 Jan 2004 10:31:00 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0CFT2RT100394; Mon, 12 Jan 2004 15:29:02 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CFSvXj226944; Mon, 12 Jan 2004 16:28:58 +0100 In-Reply-To: <001001c3d185$3cdc1e20$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: a Reject during text negotiations X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Mon, 12 Jan 2004 17:28:55 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 12/01/2004 17:29:01, Serialize complete at 12/01/2004 17:29:01 Content-Type: multipart/alternative; boundary="=_alternative 005497C5C2256E19_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 005497C5C2256E19_= Content-Type: text/plain; charset="US-ASCII" It makes sense. The Reject I assume is for ITT=y. However a target might also decide to drop both x and y and reject later also ITT=x TTT=00001. Regards, Julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 03/01/2004 01:07 To Julian Satran/Haifa/IBM@IBMIL cc Subject Re: [Ips] iSCSI: a Reject during text negotiations Julian, Could I have misunderstood you? This interpretation seems to make sense. Here is the example: I->T, ITT=x, TTT=FFFFFFFF, MaxRecvDataSegmentLength=512, F=0 T->I, ITT=x, TTT=00000001, F=0 I->T, ITT=y, TTT=FFFFFFFF, F=1 T->I Reject (MaxRecvDataSegmentLength not changed yet) I->T, ITT=x, TTT=00000001, F=1 T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512) Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Friday, January 02, 2004 1:55 PM Subject: Re: [Ips] iSCSI: a Reject during text negotiations > On Thu, 1 Jan 2004, Eddy Quicksall wrote: > > > In the example [above], are you saying the first task is still active and the > > initiator should send an empty text request with F=1 to allow the target to > > send F=1 and the MaxRecvDataSegmentLength given by the first task should be > > accepted by the target? > > > > I.e., the reset (as indicated by Reject in section 5.4) only effects the > > second task? > > Yes. > > Different ITT == different task. > > As I understand Reject, there is no reason it should function on more than > one ITT. So the reject shouldn't touch the first task (first ITT). > > Take care, > > 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 --=_alternative 005497C5C2256E19_= Content-Type: text/html; charset="US-ASCII"
It makes sense.
The Reject I assume is for ITT=y.

However a target might also decide to drop both x and y and reject later also ITT=x TTT=00001.

Regards,
Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-admin@ietf.org

03/01/2004 01:07

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
Re: [Ips] iSCSI: a Reject during text negotiations





Julian,

Could I have misunderstood you? This interpretation seems to make sense.

Here is the example:

I->T, ITT=x, TTT=FFFFFFFF, MaxRecvDataSegmentLength=512, F=0
T->I, ITT=x, TTT=00000001, F=0
I->T, ITT=y, TTT=FFFFFFFF, F=1
T->I Reject (MaxRecvDataSegmentLength not changed yet)
I->T, ITT=x, TTT=00000001, F=1
T->I, ITT=x, TTT=FFFFFFFF, F=1 (MaxRecvDataSegmentLength is now 512)

Eddy

----- Original Message -----
From: <wrstuden@wasabisystems.com>
To: "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@Comcast.net>
Cc: <ips@ietf.org>
Sent: Friday, January 02, 2004 1:55 PM
Subject: Re: [Ips] iSCSI: a Reject during text negotiations


> On Thu, 1 Jan 2004, Eddy Quicksall wrote:
>
> > In the example [above], are you saying the first task is still active
and the
> > initiator should send an empty text request with F=1 to allow the target
to
> > send F=1 and the MaxRecvDataSegmentLength given by the first task should
be
> > accepted by the target?
> >
> > I.e., the reset (as indicated by Reject in section 5.4) only effects the
> > second task?
>
> Yes.
>
> Different ITT == different task.
>
> As I understand Reject, there is no reason it should function on more than
> one ITT. So the reject shouldn't touch the first task (first ITT).
>
> Take care,
>
> 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
--=_alternative 005497C5C2256E19_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Jan 12 22:34:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10521 for ; Mon, 12 Jan 2004 22:34:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgFJx-0001bu-CH for ips-archive@odin.ietf.org; Mon, 12 Jan 2004 22:34:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0D3YP4D006189 for ips-archive@odin.ietf.org; Mon, 12 Jan 2004 22:34:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgFJx-0001bk-6p for ips-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 22:34:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10508 for ; Mon, 12 Jan 2004 22:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgFJu-0007Zk-00 for ips-web-archive@ietf.org; Mon, 12 Jan 2004 22:34:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgFI3-0007V3-00 for ips-web-archive@ietf.org; Mon, 12 Jan 2004 22:32:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgFGw-0007Q0-00 for ips-web-archive@ietf.org; Mon, 12 Jan 2004 22:31:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgFGf-0001S5-LZ; Mon, 12 Jan 2004 22:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgFFi-0001PC-7L for ips@optimus.ietf.org; Mon, 12 Jan 2004 22:30:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10359 for ; Mon, 12 Jan 2004 22:29:58 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgFFe-0007Ne-00 for ips@ietf.org; Mon, 12 Jan 2004 22:29:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgFDl-0007Kt-00 for ips@ietf.org; Mon, 12 Jan 2004 22:28:02 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AgFBz-0007H4-00 for ips@ietf.org; Mon, 12 Jan 2004 22:26:11 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 030F740135; Mon, 12 Jan 2004 22:26:07 -0500 (EST) Date: Mon, 12 Jan 2004 19:21:55 -0800 (PST) X-X-Sender: wrstuden@neverwinter To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations In-Reply-To: <004301c3d6e2$73c43fa0$0303a8c0@ivvt2dxrc11> Message-ID: References: <004301c3d6e2$73c43fa0$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Fri, 9 Jan 2004, Eddy Quicksall wrote: > It was determined by previous EMAIL's on this thread that a text > negotiation reset (TTT=0xFFFFFFFF) only effects the ITT that is being > reset. > > But now I'm wondering if that was the intent of the reset. Consider the > following: > > I->T text request, ITT=8F, TTT=FFFFFFFF, F=0 > T->I text response, ITT=8F, F=0 > I->T text request, ITT=8C, TTT=FFFFFFFF (a reset) > > Does the TTT=FFFFFFFF reset everything such that 8F is killed too or > does it reset task 8C only? 8F is untouched. It is a separate ITT, so it is a separate task. Whatever happens with 8C should not impact 8F. Julian has suggested that the target may kill 8F too, since the initiator had two outstanding text negotiations. I don't think the target should silently do this, but I think it would be ok (not required) for the target to kill the whole session, under the assumption that an initiator that has two open text requests at once is on drugs. :-) > When I first read the reset description, I thought the intent was a way > for the initiator to have a clean start during a text negotiation. > > If it only resets task 8C but the initiator never finishes task 8F, what > should the target do? In this case, what practical use does the reset > have? Task 8F is still outstanding. The target should do whatever it does to tasks that don't complete. It could be it just keeps the task around forever. The initiator will log out eventually. :-) As to what use does the reset pose? I'm not really sure. I _think_ it would be for a case where the initiator decided it didn't want anymore info. I mean there are only two things you can do in a Text Negotiation. You can announce a new MaxRecvDataSegmentLength, and you can do a SendTargets. Only SendTargets can possibly generate so much data as to need a second PDU, and with 8k MaxDataSegmentLength the default, it would have to be a big list (or a really under-powered initiator) to actually do it. So I think it'd be for a case where the initiator did a SendTargets, got more than it expected, and decided it didn't want any more of the negotiations. It could also just be a bit of over-engineering. :-) > Does the task just remain outstanding until the initiator sends the F > bit for task 8F? Yeah, it probably should. Note that we're talking about a case where the initiator forgot what it was doing. I don't really see this as the target's problem. > Is this another case for Time2Retain? I don't see why. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 13 12:33:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27407 for ; Tue, 13 Jan 2004 12:33:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSOy-0006aI-8u for ips-archive@odin.ietf.org; Tue, 13 Jan 2004 12:32:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DHWSHJ025310 for ips-archive@odin.ietf.org; Tue, 13 Jan 2004 12:32:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSOy-0006a9-1F for ips-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 12:32:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27357 for ; Tue, 13 Jan 2004 12:32:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgSOw-0006u5-00 for ips-web-archive@ietf.org; Tue, 13 Jan 2004 12:32:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgSN3-0006pa-00 for ips-web-archive@ietf.org; Tue, 13 Jan 2004 12:30:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgSLr-0006mT-00 for ips-web-archive@ietf.org; Tue, 13 Jan 2004 12:29:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSLd-00067b-2v; Tue, 13 Jan 2004 12:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSL0-00066J-To for ips@optimus.ietf.org; Tue, 13 Jan 2004 12:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27182 for ; Tue, 13 Jan 2004 12:28:19 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgSKy-0006jw-00 for ips@ietf.org; Tue, 13 Jan 2004 12:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgSJ4-0006ew-00 for ips@ietf.org; Tue, 13 Jan 2004 12:26:23 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AgSHC-0006Xy-00 for ips@ietf.org; Tue, 13 Jan 2004 12:24:26 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id BD03140136; Tue, 13 Jan 2004 12:24:19 -0500 (EST) Date: Tue, 13 Jan 2004 09:20:07 -0800 (PST) X-X-Sender: wrstuden@neverwinter To: "Nicholas A. Bellinger" Cc: ips@ietf.org, cbm@rose.hp.com, Andre Hedrick Subject: Re: [Ips] iSCSI: When does a connection become part of a session? In-Reply-To: <1073884805.1239.102.camel@subjekt.volcom.net> Message-ID: References: <1073884805.1239.102.camel@subjekt.volcom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Sun, 11 Jan 2004, Nicholas A. Bellinger wrote: > Fellow iSCSI Architects, > > I wanted to bring up a few points in regards to Joseph Pitmann's > 2nd topic: "when should Connection Reinstatement occur?", how it applies > to the discussion below, and the implementation method we use that does > not require connection count to exceed MaxConnections even in the single > connection ErrorRecoveryLevel=2 case, and hence makes the passage in > section 3.2.1 not apply. > > "For error recovery purposes, targets and initiators that support a > single active connection in a session SHOULD support two connections > during recovery." > > First a couple prerequisites on both sides: > > Initiator: > > In an ErrorRecoveryLevel=2 single or multiple connection session, when a > connection fails the initiator will attempt to perform connection > reinstatement on the failed CID before creating a connection with a new > CID. Well, that's not the only thing the initiator can do. You're talking about adding a more-narrow restriction on the initiator than the spec says; you're talking about not permitting CSM-E. > Target: > > The login process controls how many login attempts are possible on a > given session to prevent a DoS attack. > > End prerequisites. > > Now, the following order of steps on the target allows MaxConnections to > be inforced while still allowing a single connection (as well as > multiple, but the main concern Mallikarjun mentioned was the single > connection example) ErrorRecoveryLevel=2 session to perform Connection > Recovery. > > In a single connection ErrorRecoveryLevel=2 connection, CID 0 goes into > cleanup state from the initiators perspective yet remains active on the > Target. The Initiator sends a non zero TSIH login request (CSM-I) with > CID 0 to perform Session Continuation by way of Connection Reinstatement > (and hence Implict Logout) of the failed connection still active from > the Target's perspective (CSM-C). > > Connection Reinstatement is performed after SecurityNegoitation phase > has completed successfuly but before MaxConnections is checked. The > ExpStatSN of the initial login request is checked against commands of > the connection that was just forced to shutdown (CSM-C) to release those > acknowledged by the initiator before the connection failed, then finally > the MaxConnection key is checked. At this point we continue to > LoginOperationalNegotiation stage. I do not see what is gained by having connection reinstatement happen between the Security and Operational phases. You _still_ have to support a connection that hasn't passed through security (you have to allocate resources to support security), and you have also muddled the waters for a connection that bypasses the security phase all together (which is legal). I think it's easier to just wait for FFP to happen. > This is the implementation we have used for a period of time and think > is the correct method to avoid having to exceed the negoitated > MaxConnections key. We have come to the conclusion based primarly on > the following point that Pat and Mallikarijun mentioned: > > >> However note that a failed connection > >> reinstatement causes T15 which moves the session from LOGGED_IN to > >> CLEANUP_WAIT so a failed attempt would still disrupt an active > >> connection. > > > True, that was intended. However, there are two state > > machines here (CSM-C and CSM-I, borrowing 7.2 terminology), > > and note that Pat's clarification applies to CSM-C (i.e. > > the state machine representing the old instance). The CSM-I, > > the new state machine the login is happening on, OTOH, > > takes the T7 transition from IN_LOGIN to FREE. > > > A "failed connection reinstatement", however, should have > > been defined in the spec (as Pat says). For a connection > > reinstatement effort to be considered "failed" and thus > > cause a state change to CSM-C on the target end, the effort > > should have progressed (and failed) beyond the SecurityNegotiation > > stage. Ditto for session reinstatement. > > Taking this into account, I see the above order of steps as the desired > implementation because when a connection makes it past the point of > successful SecurityNeogitation, the existing CID (CSM-C) will be forced > into shutdown regardless if CSM-I makes it into Full Feature Phase or > not. To be honest, I think I'd just can (throw out) the concept of "reinstatement failed" for the target. Waiting for FFP seems much cleaner and simpler. The only reason I'd see that a target would fail the transition after starting it would be some sort of internal error. I think the state makes a lot of sense for an initiator, for which it knows that it is trying to do the reinstatement. All we're doing by having this state in the target is having the reinstatement code let a misbehaving initiator (I mean come on, how do you screw up reinstatement operational processing, if you aren't being stupid? :-) trigger state transitions. As the spec was vague about this point, it seems valid to define the transition in the target such that it won't fail. > The other implemenation example(s) that has been discussed so far that > requires the connection count to exceed MaxConnections in a single (or > multple) connection ErrorRecoveryLevel=2 session roughly follow these > steps: > > Connection Reinstatement happens when the last login response is sent > before moving to Full Feature Phase. The MaxConnection key is checked > either before or after security negotiation phase, requiring the > connection count to temporarily exceed MaxConnections in order to > perform Connection Reinstatement before moving to FFP. This is of > course legal but IMHO exceeding MaxConnections is generally frowned > upon. I disagree with this statement. MaxConnections is to protect resources. What resources do you need in the operational phase that you don't need in the security phase? For both, you need the negotiating engine, and you need to know what you're negotiating. So I see no advantage to looking at MaxConnections at Security->Operational. Either you look at tcp_accept() time (when you're allocating connection resources), or you look after negotiations are done. Also, as above, connections can bypass the security phase altogether. So it strikes me as much cleaner to think about connections as in login or done with it. Doing otherwise (looking in the middle) seems messy. Finally, the "having two in error recovery" is, as far as I can tell, to permit people to do CSM-E cleanup. So when we do the connection counting won't matter; to do CSM-E, you will still need to let the new connection get to FFP so that it can clean the old one up. > As mentioned in the prerequisities, an Initiator in a single or multiple > connection ErrorRecoveryLevel=2 session should attempt connection > reinstatement before starting a new connection with a different CID. > So basically in ErrorRecoveryLevel=2, Session Continuation is achieved > by performing continuous Connection Reinstatement on failed CIDs and NOT > by starting new connections with different CIDs. This is the method that > our ErrorRecoveryLevel=2 multiple connection session iSCSI Initiator > uses that will be open sourced in the near future. While that would work, you are adding a requirement to the spec that is not there. The encouragement (SHOULD) to being able to exceed MaxConnections during error recovery indicates that the spec authors really wanted to be able to log in a different connection and do an explicit Logout on the old connection. Also, I think you've muddled two things in the above. You're talking about doing the connection count at the transition between security and operational phases, and you talk about CSM-I being prefered. I think prefering CSM-I is what lets you get around MaxConnections=1, and that looking in the middle of login isn't helping there. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 14 02:05:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10704 for ; Wed, 14 Jan 2004 02:05:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agf54-00035a-3c for ips-archive@odin.ietf.org; Wed, 14 Jan 2004 02:04:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E74jH7011873 for ips-archive@odin.ietf.org; Wed, 14 Jan 2004 02:04:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agf53-00035Q-BR for ips-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 02:04:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10069 for ; Wed, 14 Jan 2004 02:04:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agf4z-0005fq-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 02:04:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agf34-0005cL-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 02:02:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agf1Y-0005ZR-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 02:01:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agf1V-0002lr-8u; Wed, 14 Jan 2004 02:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agf11-0002iD-B0 for ips@optimus.ietf.org; Wed, 14 Jan 2004 02:00:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05711 for ; Wed, 14 Jan 2004 02:00:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agf0x-0005W2-00 for ips@ietf.org; Wed, 14 Jan 2004 02:00:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agez5-0005Sl-00 for ips@ietf.org; Wed, 14 Jan 2004 01:58:37 -0500 Received: from adsl-67-124-61-228.dsl.snfc21.pacbell.net ([67.124.61.228] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1AgeyW-0005Pv-00 for ips@ietf.org; Wed, 14 Jan 2004 01:58:00 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1Ageor-0002Kp-00; Tue, 13 Jan 2004 22:48:01 -0800 Subject: Re: [Ips] iSCSI: When does a connection become part of a session? From: "Nicholas A. Bellinger" To: wrstuden@wasabisystems.com Cc: ips@ietf.org, Mallikarjun Chadalapaka , Andre Hedrick In-Reply-To: References: <1073884805.1239.102.camel@subjekt.volcom.net> Content-Type: text/plain Message-Id: <1074062880.1239.373.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 13 Jan 2004 22:48:00 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-01-13 at 09:20, wrstuden@wasabisystems.com wrote: > On Sun, 11 Jan 2004, Nicholas A. Bellinger wrote: > > > Fellow iSCSI Architects, > > > > I wanted to bring up a few points in regards to Joseph Pitmann's > > 2nd topic: "when should Connection Reinstatement occur?", how it applies > > to the discussion below, and the implementation method we use that does > > not require connection count to exceed MaxConnections even in the single > > connection ErrorRecoveryLevel=2 case, and hence makes the passage in > > section 3.2.1 not apply. > > > > "For error recovery purposes, targets and initiators that support a > > single active connection in a session SHOULD support two connections > > during recovery." > > > > First a couple prerequisites on both sides: > > > > Initiator: > > > > In an ErrorRecoveryLevel=2 single or multiple connection session, when a > > connection fails the initiator will attempt to perform connection > > reinstatement on the failed CID before creating a connection with a new > > CID. > > Well, that's not the only thing the initiator can do. You're talking about > adding a more-narrow restriction on the initiator than the spec says; > you're talking about not permitting CSM-E. First off, lets both agree that CSM-E is an explict logout by way of a REMOVECONNFORRECOVERY Logout Request, and has an nothing explicty to do with exceeding MaxConnections. I have not mentioned anything about not permitting CSM-E, what I am discussing is the implementation method and very clear case where it is not needed in a single connection ErrorRecoveryLevel=2 session in the context of enforcing the negoitated MaxConnections key. The fact that this method works regardless of ErrorRecoveryLevel is a key factor into why it is a simpler and effective method of achiving our desired goal of interoperable implementations. The fact of the matter is when a target follows the aforementioned steps of checking MaxConnections after Connection Reinstatement occurs, there are very few (one that I can think of) situations where creating a new connection with a different CID is adventagous to performing Session Continuaion by way of continous Connection Reinstatement, and hence making CSM-E a not apply. The only example that I have encountered requires user intervention in a 'traditional iSCSI' single connection ErrorRecoveryLevel=2 session is as follows. Initiator: CID 0 to IP address 0 on Communication (Ethernet) Port 0 fails. Connection Reinstatement to IP address 0 fails because IP address 0 no longer exists or Communcation Port 0 is no longer active. With User Intervention: While the Initiator is attempting to perform Connection Reinstatement on CID 0 unsuccessfuly and before the session falls back to Session Reinstatement, the User attempts to add another connection with CID 1 to IP address 1 on Communcation Port 1 with the same Target Portal Group Tag where communcation is active. In the example where the Initiator is temporarily allowed to exceed MaxConnections, a explict logout (CSM-E) is sent on CID 1 to shutdown CID 0 and then returns to a connection count that does not exceed MaxConnections. In the example where MaxConnections is enforced the Login Request for CID 1 by User is rejected, Connectection Reinstatement on CID 0 times out and the session falls back to Session Reinstatement. (ie: the 'Without User Intervention' case) Without User Intervention: After the Connection Reinstatement attempt on CID 0 times out, the Initiator falls back to Session Reinstatement and into Target Portal Group failover looking for a IP address on a Communcation Port that it can perform Session Reinstatement into. Once Session Reinstatement is performed, the connection still active from the Target's prespective is forced to shutdown. If there is any other situation(s) where MaxConnections must be exceeded in order to continue on with Connection Recovery while following the single Initiator prerequsite of performing Session Continuation by way of continous Connection Reinstatement, and the aforementioned method of performing Connection Reinstatement before checking MaxConnections after SecurityNegotiation is complete in _any_ ErrorRecoveryLevel, I would like to hear them now. > > > Target: > > > > The login process controls how many login attempts are possible on a > > given session to prevent a DoS attack. > > > > End prerequisites. > > > > Now, the following order of steps on the target allows MaxConnections to > > be inforced while still allowing a single connection (as well as > > multiple, but the main concern Mallikarjun mentioned was the single > > connection example) ErrorRecoveryLevel=2 session to perform Connection > > Recovery. > > > > In a single connection ErrorRecoveryLevel=2 connection, CID 0 goes into > > cleanup state from the initiators perspective yet remains active on the > > Target. The Initiator sends a non zero TSIH login request (CSM-I) with > > CID 0 to perform Session Continuation by way of Connection Reinstatement > > (and hence Implict Logout) of the failed connection still active from > > the Target's perspective (CSM-C). > > > > Connection Reinstatement is performed after SecurityNegoitation phase > > has completed successfuly but before MaxConnections is checked. The > > ExpStatSN of the initial login request is checked against commands of > > the connection that was just forced to shutdown (CSM-C) to release those > > acknowledged by the initiator before the connection failed, then finally > > the MaxConnection key is checked. At this point we continue to > > LoginOperationalNegotiation stage. > > I do not see what is gained by having connection reinstatement happen > between the Security and Operational phases. You _still_ have to support a > connection that hasn't passed through security (you have to allocate > resources to support security), and you have also muddled the waters for a > connection that bypasses the security phase all together (which is legal). > I think it's easier to just wait for FFP to happen. The key advantage to this whole discussion is when the Initiator does Session Continuation by way of continious Connection Reinstatement, and the Target performs Connection Reinstatement after SecurityNegoitation is complete, MaxConnection can be enforced. As for MaxConnections, I have always interpreted its meaning as the maximum allowable Full Feature Phase connections in an iSCSI Session. Its value has no bearing on connections that have not passed into Full Feature Phase state. This is the reason for the above Target Prerequsite for controlling resources and avoiding DoS attacks. Additonally, it is obvious that when AuthMethod is negoitiated to None, or the Initiator decides to skip SecurityNegotiation all together with a Login Request containing CSG=1 and NSG=[1,3], the Connection Reinstatement and MaxConnections checks occur upon receipt of the initial Login Request that indicates its desire to skip CSG=0. This is why I explictly said after SecurityNegotiation and not during. > > > This is the implementation we have used for a period of time and think > > is the correct method to avoid having to exceed the negoitated > > MaxConnections key. We have come to the conclusion based primarly on > > the following point that Pat and Mallikarijun mentioned: > > > > >> However note that a failed connection > > >> reinstatement causes T15 which moves the session from LOGGED_IN to > > >> CLEANUP_WAIT so a failed attempt would still disrupt an active > > >> connection. > > > > > True, that was intended. However, there are two state > > > machines here (CSM-C and CSM-I, borrowing 7.2 terminology), > > > and note that Pat's clarification applies to CSM-C (i.e. > > > the state machine representing the old instance). The CSM-I, > > > the new state machine the login is happening on, OTOH, > > > takes the T7 transition from IN_LOGIN to FREE. > > > > > A "failed connection reinstatement", however, should have > > > been defined in the spec (as Pat says). For a connection > > > reinstatement effort to be considered "failed" and thus > > > cause a state change to CSM-C on the target end, the effort > > > should have progressed (and failed) beyond the SecurityNegotiation > > > stage. Ditto for session reinstatement. > > > > Taking this into account, I see the above order of steps as the desired > > implementation because when a connection makes it past the point of > > successful SecurityNeogitation, the existing CID (CSM-C) will be forced > > into shutdown regardless if CSM-I makes it into Full Feature Phase or > > not. > > To be honest, I think I'd just can (throw out) the concept of > "reinstatement failed" for the target. Waiting for FFP seems much cleaner > and simpler. The only reason I'd see that a target would fail the > transition after starting it would be some sort of internal error. > > I think the state makes a lot of sense for an initiator, for which it > knows that it is trying to do the reinstatement. > > All we're doing by having this state in the target is having the > reinstatement code let a misbehaving initiator (I mean come on, how do you > screw up reinstatement operational processing, if you aren't being > stupid? :-) trigger state transitions. As the spec was vague about this > point, it seems valid to define the transition in the target such that it > won't fail. I see the primary reason for enforcing the concept of 'reinstatement failed' is the simple fact that a Initiator would not be attempting Connection Reinstatement on a given CID unless it had already failed from its perspective. There is not a single reason once a Connection Reinstatement attempt has passed SecurityNegotiation on a target, that CSM-C should not be forced to shutdown given this very clear point. This state is not about accomidating broken initiators, this state is a subtle indication about what is the correct point during the login procedure to perform Connection Reinstatement. That point being after sucessfuly SecurityNegotitation, or upon reciept of a logout request containing CSG=1 and NSG=[1,3] > > > The other implemenation example(s) that has been discussed so far that > > requires the connection count to exceed MaxConnections in a single (or > > multple) connection ErrorRecoveryLevel=2 session roughly follow these > > steps: > > > > Connection Reinstatement happens when the last login response is sent > > before moving to Full Feature Phase. The MaxConnection key is checked > > either before or after security negotiation phase, requiring the > > connection count to temporarily exceed MaxConnections in order to > > perform Connection Reinstatement before moving to FFP. This is of > > course legal but IMHO exceeding MaxConnections is generally frowned > > upon. > > I disagree with this statement. MaxConnections is to protect resources. > What resources do you need in the operational phase that you don't need in > the security phase? For both, you need the negotiating engine, and you > need to know what you're negotiating. So I see no advantage to looking at > MaxConnections at Security->Operational. Either you look at tcp_accept() > time (when you're allocating connection resources), or you look after > negotiations are done. > > Also, as above, connections can bypass the security phase altogether. So > it strikes me as much cleaner to think about connections as in login or > done with it. Doing otherwise (looking in the middle) seems messy. > > Finally, the "having two in error recovery" is, as far as I can tell, to > permit people to do CSM-E cleanup. So when we do the connection counting > won't matter; to do CSM-E, you will still need to let the new connection > get to FFP so that it can clean the old one up. I stand firm to the points made above: The negotiated MaxConnections keys sole purpose is the control the maximum allowed Full Feature Phase connections in an iSCSI session, and not to control resource allocation during login. I have never seen MaxConnections discussed in a pre-FFP resource allocation capacity until this thread. Pre-FFP resource allocation should be controlled by an external mechinism as was mentioned in the Target's prerequsites. In the previous points regarding Connection Reinstatement and MaxConnections being checked after SecurityNegotation is complete (or upon the initial login request with CSG=1, NSG[1,3]). The check of MaxConnections is all that occurs and the connection count is not incremented until Full Feature Phase occurs. As for the third paragraph quoted above, all of the examples and concerns have been addressed at the top of this reply. There is no logical reason why an Initiator should start an new connection with a different CID when Connection Reinstatement is performed before MaxConnections checked. The only two examples where CSM-E is required in a single connection ErrorRecoveryLevel=2 session if when a new connection with a different CID is started instead of performing Connection Reinstatement (which ErrorRecoveryLevel=2 Initiators do this as normal operation?), and in the case of a Target that performs Connection Reinstatement before Full Feature Phase, and after MaxConnections is checked and hence exceed. Using CSM-E in the latter case for normal single connection ErrorRecoveryLevel=2 operation is accomidating a Target that chooses to use a implementation method that goes against the 'failed connection reinstatement' stage mentioned above. > > > As mentioned in the prerequisities, an Initiator in a single or multiple > > connection ErrorRecoveryLevel=2 session should attempt connection > > reinstatement before starting a new connection with a different CID. > > So basically in ErrorRecoveryLevel=2, Session Continuation is achieved > > by performing continuous Connection Reinstatement on failed CIDs and NOT > > by starting new connections with different CIDs. This is the method that > > our ErrorRecoveryLevel=2 multiple connection session iSCSI Initiator > > uses that will be open sourced in the near future. > > While that would work, you are adding a requirement to the spec that is > not there. The encouragement (SHOULD) to being able to exceed > MaxConnections during error recovery indicates that the spec authors > really wanted to be able to log in a different connection and do an > explicit Logout on the old connection. > > Also, I think you've muddled two things in the above. You're talking about > doing the connection count at the transition between security and > operational phases, and you talk about CSM-I being prefered. I think > prefering CSM-I is what lets you get around MaxConnections=1, and that > looking in the middle of login isn't helping there. This is not a requirement, but a simple and straightforward implementation method that allows the negotiated MaxConnections key to be enforced. Considering there is only a single, unlikely, and interrupted by user situation where starting a new connection with a different CID is adventagous to performing Session Continuation by way of Connection Reinstatement in both single connection ErrorRecoveryLevel=2 and non ErrorRecoveryLevel=2 sessions, it demonstrates our implementation method to be the simplest while still enforcing negotiated SessionWide keys, and conforming to the iSCSI specification. I have to reinterate the same challenge above given the following scenario: Initiator: Performs continuous Session Continuation by way of Connection Reinstatement. Target: Connection Reinstatement occurs and then MaxConnections is checked after SecurityNegotiation is complete, or upon reciept of a Login Request containing CSG=1, NSG=[1,3]. The 'failed connection reinstatement' state is enforced as there is no single reason to keep CSM-C around when the Initiator has attempted Connection Reinstatement. What other recovery situations invoke Session Continuation by starting a new connection with a different CID as opposed to continous Connection Reinstatement other than the single user invoked example mentioned above that would cause a non-zero TSIH login attempt to be rejected due to exceeding MaxConnections when Connection Reinstatement and MaxConnections are checked in the order I have proposed? Any takers? :-) -- Nicholas A. Bellinger > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 14 10:49:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24485 for ; Wed, 14 Jan 2004 10:49:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgnGA-0006kt-8u for ips-archive@odin.ietf.org; Wed, 14 Jan 2004 10:48:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EFmksq025962 for ips-archive@odin.ietf.org; Wed, 14 Jan 2004 10:48:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgnGA-0006kf-3G for ips-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 10:48:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24475 for ; Wed, 14 Jan 2004 10:48:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgnG7-0001GM-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 10:48:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgnFH-0001FT-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 10:47:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgnEf-0001EL-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 10:47:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgnES-0006dI-Jg; Wed, 14 Jan 2004 10:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgnEH-0006d3-Og for ips@optimus.ietf.org; Wed, 14 Jan 2004 10:46:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24428 for ; Wed, 14 Jan 2004 10:46:46 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgnEF-0001Cm-00 for ips@ietf.org; Wed, 14 Jan 2004 10:46:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgnDE-0001BR-00 for ips@ietf.org; Wed, 14 Jan 2004 10:45:44 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AgnCK-000184-00 for ips@ietf.org; Wed, 14 Jan 2004 10:44:48 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id B1E0140149; Wed, 14 Jan 2004 10:44:41 -0500 (EST) Date: Wed, 14 Jan 2004 07:40:27 -0800 (PST) X-X-Sender: wrstuden@neverwinter To: "Nicholas A. Bellinger" Cc: ips@ietf.org, Mallikarjun Chadalapaka , Andre Hedrick Subject: Re: CSM [Ips] iSCSI: When does a connection become part of a session? In-Reply-To: <1074062880.1239.373.camel@subjekt.volcom.net> Message-ID: References: <1073884805.1239.102.camel@subjekt.volcom.net> <1074062880.1239.373.camel@subjekt.volcom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 13 Jan 2004, Nicholas A. Bellinger wrote: > On Tue, 2004-01-13 at 09:20, wrstuden@wasabisystems.com wrote: > > On Sun, 11 Jan 2004, Nicholas A. Bellinger wrote: > > Finally, the "having two in error recovery" is, as far as I can tell, to > > permit people to do CSM-E cleanup. So when we do the connection counting > > won't matter; to do CSM-E, you will still need to let the new connection > > get to FFP so that it can clean the old one up. [snip] > As for the third paragraph quoted above, all of the examples and > concerns have been addressed at the top of this reply. There is no > logical reason why an Initiator should start an new connection with a > different CID when Connection Reinstatement is performed before > MaxConnections checked. The "logical" reason for the initiator to choose CSM-E recovery is that that is what the initiator author(s) chose to do. Just because it is not your choice does not mean it won't be someone else's choice. You say that doing things this way would permit always enforcing MaxConnections. You are correct. However to make a difference in the targets (to have a strong impact), targets have to be coded to ignore the SHOULD in the spec concerning MaxConnections & error recovery. That's changing the spec; I don't think your discussion above is an appropriate technical reason for a target to ignore the spec. > > Also, I think you've muddled two things in the above. You're talking about > > doing the connection count at the transition between security and > > operational phases, and you talk about CSM-I being prefered. I think > > prefering CSM-I is what lets you get around MaxConnections=1, and that > > looking in the middle of login isn't helping there. > > This is not a requirement, but a simple and straightforward > implementation method that allows the negotiated MaxConnections key to > be enforced. As above, enforcing MaxConnections like this breaks a SHOULD in the spec. I do not think you have given a sufficient justification for a target to get around the SHOULD. This discussion may have lead to the SHOULD's removal had it been made earlier in the standards process, but for now we have a SHOULD. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 14 13:48:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02601 for ; Wed, 14 Jan 2004 13:48:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agq3V-00007b-CK for ips-archive@odin.ietf.org; Wed, 14 Jan 2004 13:47:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EIlr9Y000461 for ips-archive@odin.ietf.org; Wed, 14 Jan 2004 13:47:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agq3V-00007M-6g for ips-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 13:47:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02560 for ; Wed, 14 Jan 2004 13:47:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agq3S-00023n-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 13:47:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agq2X-00022L-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 13:46:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agq1k-00021S-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 13:46:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agq1i-0008Ri-0f; Wed, 14 Jan 2004 13:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agq1f-0008R9-KT for ips@optimus.ietf.org; Wed, 14 Jan 2004 13:45:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02503 for ; Wed, 14 Jan 2004 13:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agq1d-00020o-00 for ips@ietf.org; Wed, 14 Jan 2004 13:45:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agq0d-0001zl-00 for ips@ietf.org; Wed, 14 Jan 2004 13:44:56 -0500 Received: from [198.70.192.130] (helo=homer.qlogic.org) by ietf-mx with esmtp (Exim 4.12) id 1Agpzw-0001xA-00 for ips@ietf.org; Wed, 14 Jan 2004 13:44:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DACE.5EB1CC8E" Date: Wed, 14 Jan 2004 10:43:58 -0800 Message-ID: <2A8D600C919D2D41A3DAA2D2FEC717147014FE@homer.qlogic.org> Thread-Topic: CmdSN, StatSN in text PDUs Thread-Index: AcPazl7+FFxanokMTymb+vuErEA7gw== From: "Dean Scoville" To: "Julian Satran" Cc: Subject: [Ips] CmdSN, StatSN in text PDUs Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DACE.5EB1CC8E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, Could you please confirm whether my understanding of CmdSN and StatSN = for=20 Text PDUs is correct? The behavior of CmdSN when C=3D1 isn't explicitly = stated=20 in the draft, so I'm assuming CmdSN is still advanced. Here are my = thoughts: The initiator should always increment CmdSN after sending a=20 non-immediate Text Request PDU, regardless of whether the Final = and/or Continuation flags are set in the PDU header. CmdSN should never be = advanced, however, after sending an immediate Text Request PDU. The target should always increment StatSN after sending a Text = Response PDU, regardless of the values of the Final and Continuation flags in the = PDU header. Is this a correct understanding of CmdSN and StatSN operation in Text = PDUs?=20 (Note: For the purposes of this question, I'm ignoring the case of Text = PDU=20 retransmissions caused by SNACKs, digest errors, or timeouts when=20 ErrorRecoveryLevel >0.) thanks, Dean Scoville ------_=_NextPart_001_01C3DACE.5EB1CC8E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CmdSN, StatSN in text PDUs

Julian,

Could you please confirm whether my = understanding of CmdSN and StatSN for
Text PDUs is correct? The behavior of = CmdSN when C=3D1 isn't explicitly stated
in the draft, so I'm assuming CmdSN is = still advanced. Here are my thoughts:

   The initiator should = always increment CmdSN after sending a
   non-immediate Text = Request PDU, regardless of whether the Final and/or
   Continuation flags are = set in the PDU header. CmdSN should never be advanced,
   however, after sending an = immediate Text Request PDU.

   The target should always = increment StatSN after sending a Text Response PDU,
   regardless of the values = of the Final and Continuation flags in the PDU header.

Is this a correct understanding of = CmdSN and StatSN operation in Text PDUs?

(Note: For the purposes of this = question, I'm ignoring the case of Text PDU
retransmissions caused by SNACKs, = digest errors,  or timeouts when
ErrorRecoveryLevel >0.)

thanks,
Dean Scoville

------_=_NextPart_001_01C3DACE.5EB1CC8E-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 14 18:23:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20850 for ; Wed, 14 Jan 2004 18:23:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AguLp-0007eM-Br for ips-archive@odin.ietf.org; Wed, 14 Jan 2004 18:23:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ENN5ke029406 for ips-archive@odin.ietf.org; Wed, 14 Jan 2004 18:23:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AguLp-0007e9-86 for ips-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 18:23:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20798 for ; Wed, 14 Jan 2004 18:22:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AguLl-0000zQ-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 18:23:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AguKt-0000xJ-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 18:22:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AguJz-0000uo-00 for ips-web-archive@ietf.org; Wed, 14 Jan 2004 18:21:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AguJq-0007S0-Iy; Wed, 14 Jan 2004 18:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AguIt-0007Q9-EP for ips@optimus.ietf.org; Wed, 14 Jan 2004 18:20:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20553 for ; Wed, 14 Jan 2004 18:19:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AguIq-0000r7-00 for ips@ietf.org; Wed, 14 Jan 2004 18:20:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AguHu-0000pZ-00 for ips@ietf.org; Wed, 14 Jan 2004 18:19:03 -0500 Received: from razorbill.mail.pas.earthlink.net ([207.217.121.248]) by ietf-mx with esmtp (Exim 4.12) id 1AguHF-0000nt-00; Wed, 14 Jan 2004 18:18:21 -0500 Received: from 9.sub-166-154-182.myvzw.com ([166.154.182.9] helo=EGRodriguez) by razorbill.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 1AguHD-0004oo-00; Wed, 14 Jan 2004 15:18:20 -0800 From: "Elizabeth Rodriguez" To: , Date: Wed, 14 Jan 2004 15:18:04 -0800 Message-ID: <005601c3daf4$ad9ed990$09b69aa6@EGRodriguez> 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.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-ELNK-Trace: 298a5331f71a6b7b79fa035ab2d882059ef193a6bfc3dd482963ec55751d50dda02a3b78a927ce26bd9aa8b00e01cd47350badd9bab72f9c350badd9bab72f9c Content-Transfer-Encoding: quoted-printable Subject: [Ips] FW: Processing of Expired Internet-Drafts Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable FYI For IPS, this applies to the iscsi naming extension and the iSNS MIB. It does not currently apply to any IMSS draft. This also applies to individual submissions not yet an official working group item. Elizabeth Rodriguez -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] = On Behalf Of The IETF Secretariat Sent: Wednesday, January 14, 2004 7:53 AM To: IETF-Announce: Cc: iesg@ietf.org Subject: Processing of Expired Internet-Drafts The IETF Secretariat has updated its procedures for processing expired=20 Internet-Drafts. The updated procedures, which are presented below,=20 can also be found in the document entitled "Guidelines to Authors of=20 Internet-Drafts" (http://www.ietf.org/ietf/1id-guidelines.txt). =20 An Internet-Draft will expire exactly 185 days from the date that it is posted=20 on the IETF Web site (http://www.ietf.org/ID.html) unless it is replaced = by an updated version (in which case the clock will start all over again = for the new version, and the old version will be removed from the = Internet-Draft repositories), or unless it is under official review by the IESG=20 (i.e., a request to publish it has been submitted). Specifically, when=20 an Internet-Draft enters the "Publication Requested" state in the I-D Tracker,=20 it will not be expired until its status is resolved (e.g., it is = published as=20 an RFC). I-D Tracker states not associated with a formal request to = publish a document (e.g., "AD is Watching") will not prevent an Internet-Draft = from=20 expiring after 185 days. Internet-Drafts will not expire during the period surrounding an IETF Meeting=20 when submission of updates to Internet-Drafts is suspended (i.e., = between=20 the cutoff date for submission of updated drafts, which is two weeks = prior to=20 an IETF Meeting, and the date that Internet-Draft submissions are once = again being accepted). All Internet-Drafts scheduled to expire during this = period will expire on the day that the Secretariat reopens Internet-Draft submissions. When an Internet-Draft expires, a "tombstone" file will be created that includes the filename and version number of the Internet-Draft that has expired. = The filename of the tombstone file will be the same as that of the = expired=20 Internet-Draft with the version number increased by one. If a revised version=20 of an expired Internet-Draft is submitted for posting, then the revised version will replace the tombstone file and will receive the same version number = as that previously assigned to the tombstone file. Tombstone files will never expire and will always be available for reference unless they are replaced by updated=20 versions of the subject Internet-Drafts. The IETF Secretariat _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 15 01:26:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02508 for ; Thu, 15 Jan 2004 01:26:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah0xN-0002og-Jd for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 01:26:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F6QH4c010820 for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 01:26:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah0xN-0002oR-DC for ips-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 01:26:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02505 for ; Thu, 15 Jan 2004 01:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah0xK-0006ye-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 01:26:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah0wL-0006xI-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 01:25:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah0wD-0006wN-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 01:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah0wB-0002hB-Dt; Thu, 15 Jan 2004 01:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah0vO-0002gA-UD for ips@optimus.ietf.org; Thu, 15 Jan 2004 01:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02468 for ; Thu, 15 Jan 2004 01:24:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah0vL-0006vL-00 for ips@ietf.org; Thu, 15 Jan 2004 01:24:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah0uN-0006tA-00 for ips@ietf.org; Thu, 15 Jan 2004 01:23:12 -0500 Received: from adsl-67-124-61-228.dsl.snfc21.pacbell.net ([67.124.61.228] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1Ah0tQ-0006qj-00 for ips@ietf.org; Thu, 15 Jan 2004 01:22:13 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1Ah0jk-0002ja-00; Wed, 14 Jan 2004 22:12:12 -0800 Subject: Re: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue From: "Nicholas A. Bellinger" To: wrstuden@wasabisystems.com Cc: ips@ietf.org, Mallikarjun Chadalapaka , Andre Hedrick , pat_thaler@agilent.com, Julian_Satran@il.ibm.com, Black_David@emc.com, Joseph.Pittman@netapp.com In-Reply-To: References: <1073884805.1239.102.camel@subjekt.volcom.net> <1074062880.1239.373.camel@subjekt.volcom.net> Content-Type: text/plain Message-Id: <1074147130.1239.586.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 14 Jan 2004 22:12:10 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-01-14 at 07:40, wrstuden@wasabisystems.com wrote: > On Tue, 13 Jan 2004, Nicholas A. Bellinger wrote: > > > On Tue, 2004-01-13 at 09:20, wrstuden@wasabisystems.com wrote: > > > On Sun, 11 Jan 2004, Nicholas A. Bellinger wrote: > > > Finally, the "having two in error recovery" is, as far as I can tell, to > > > permit people to do CSM-E cleanup. So when we do the connection counting > > > won't matter; to do CSM-E, you will still need to let the new connection > > > get to FFP so that it can clean the old one up. > > [snip] > > > As for the third paragraph quoted above, all of the examples and > > concerns have been addressed at the top of this reply. There is no > > logical reason why an Initiator should start an new connection with a > > different CID when Connection Reinstatement is performed before > > MaxConnections checked. > > The "logical" reason for the initiator to choose CSM-E recovery is that > that is what the initiator author(s) chose to do. Just because it is not > your choice does not mean it won't be someone else's choice. > No, the "logical" reason is that no-one can name a single reason why CSM-E would occur during normal operation in a single connection ErrorRecoveryLevel=2 session in the first place. Furthermore I have yet to encounter an ErrorRecoveryLevel=2 Initiator that takes this approach, or any other technical reason why needing to have two approaches other than to give Initiator authors more 'choice' ensures interoperability. If imposing a small restriction (how hard can it be to use a CID from a failed connection as opposed to assigning a new one?) ensures interopability between ErrorRecoveryLevel=2 implementations than it is a small price to pay to avoid single connection ErrorRecoveryLevel=2 implementations from potentially falling back to Session Reinstatement aka 'Degraded Mode' every time. Considering the passage in section 3.2.1 that you continuously sight as a reason to prevent a simpler and more effective method of ensuring interoperability is a SHOULD, there is a very obvious interoptability hole that needs to be closed. > You say that doing things this way would permit always enforcing > MaxConnections. You are correct. However to make a difference in the > targets (to have a strong impact), targets have to be coded to ignore the > SHOULD in the spec concerning MaxConnections & error recovery. That's > changing the spec; I don't think your discussion above is an appropriate > technical reason for a target to ignore the spec. > This SHOULD is the interoperability problem for ErrorRecoveryLevel=2 implementations I am trying to close. Consider the two following implementation scenraios operating in a multi-vendor enviroment given the following methods of iSCSI vendor X and vendor Y: iSCSI Target Vendor X: Enforces a MaxConnections check after Connection Reinstatement occurs. iSCSI Target Vendor Y: Allows MaxConnections to be exceeded at any time. Scenario 0: iSCSI Initiator Vendor A: Performs Session Continuation by way of continutions Connection Reinstatement (CSM-I). Interoptiablity Issues: iSCSI Target Vendor X: None iSCSI Target Vendor Y: None. Scenario 1: iSCSI Initiator Vendor B: Performs Session Continuation by way of creating a new connection with a different CID, and logging out the failed connection with a explict logout request. (CSM-E). Interoptiablity Issues: iSCSI Target Vendor X: MaxConnections is enforced as section 3.2.1 defines a SHOULD instead of a MUST. The login attempt is with rejected with a Status Class/Detail of 0x0206. iSCSI Target Vendor Y: None. > > > Also, I think you've muddled two things in the above. You're talking about > > > doing the connection count at the transition between security and > > > operational phases, and you talk about CSM-I being prefered. I think > > > prefering CSM-I is what lets you get around MaxConnections=1, and that > > > looking in the middle of login isn't helping there. > > > > This is not a requirement, but a simple and straightforward > > implementation method that allows the negotiated MaxConnections key to > > be enforced. > > As above, enforcing MaxConnections like this breaks a SHOULD in the spec. > I do not think you have given a sufficient justification for a target to > get around the SHOULD. This discussion may have lead to the SHOULD's > removal had it been made earlier in the standards process, but for now we > have a SHOULD. > It comes down to one of two options the working group has in order to prevent the clear interoperability issue between ErrorRecoveryLevel=2 implementations described above. 0: Change the SHOULD to a MUST in section 3.2.1 and require all Targets to exceed MaxConnections for the sole purpose of creating more 'choice' for Initiator Authors. Additionally, not a _single_ technicial reason has been raised that explains why CSM-E should ever happen during normal operation in a single connection ErrorRecoveryLevel=2 session. OR 1: Require ErrorRecoveryLevel=2 Initiator Implementations to perform Connection Resinstatement (CSM-I) before attempting to start a new connection with a different CID (CSM-E). This allows targets to enforce MaxConnections. Additionally I believe it has been proven beyond a reasonable doubt that the correct location to perform Connection Reinstatement on a Target is after a succcessful SecurityNegotiation or upon reciept of a Login Request containing CSG=1 and NSG=[1,3], and before MaxConnections is checked. I believe the 'reinstatement failed' state mentioned in the previous replys is a clear indication of why this is the appropriate place, and when used in conjunction with the second option mentioned above allows for interoperable ErrorRecoveryLevel=2 implementations with the desired side effect of enforcing the negotiated MaxConnections key. Consensus Please? -- Nicholas A. Bellinger > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 15 03:51:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19726 for ; Thu, 15 Jan 2004 03:51:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3D7-00048o-JW for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 03:50:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F8ofi5015907 for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 03:50:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3D4-00048Q-9T for ips-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 03:50:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19592 for ; Thu, 15 Jan 2004 03:50:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah3D1-0004uu-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 03:50:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah3Bv-0004j9-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 03:49:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ah3B0-0004fx-03 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 03:48:30 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ah36m-0004Fb-VO for ips-web-archive@ietf.org; Thu, 15 Jan 2004 03:44:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah36g-0003qg-BD; Thu, 15 Jan 2004 03:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah35w-0003ml-Bf for ips@optimus.ietf.org; Thu, 15 Jan 2004 03:43:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19362 for ; Thu, 15 Jan 2004 03:43:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah35t-0004Wh-00 for ips@ietf.org; Thu, 15 Jan 2004 03:43:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah34y-0004Uc-00 for ips@ietf.org; Thu, 15 Jan 2004 03:42:17 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1Ah343-0004SU-00 for ips@ietf.org; Thu, 15 Jan 2004 03:41:19 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0F8enRT053196; Thu, 15 Jan 2004 08:40:49 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0F8emNA255002; Thu, 15 Jan 2004 09:40:48 +0100 In-Reply-To: <2A8D600C919D2D41A3DAA2D2FEC717147014FE@homer.qlogic.org> To: "Dean Scoville" Cc: ips@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Thu, 15 Jan 2004 10:40:47 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 15/01/2004 10:40:48, Serialize complete at 15/01/2004 10:40:48 Content-Type: multipart/alternative; boundary="=_alternative 002EBD71C2256E1C_=" Subject: [Ips] Re: CmdSN, StatSN in text PDUs Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 002EBD71C2256E1C_= Content-Type: text/plain; charset="US-ASCII" Dean, "Dean Scoville" wrote on 14/01/2004 20:43:58: > Julian, > Could you please confirm whether my understanding of CmdSN and StatSN for > Text PDUs is correct? The behavior of CmdSN when C=1 isn't explicitly stated > in the draft, so I'm assuming CmdSN is still advanced. Here are my thoughts: > The initiator should always increment CmdSN after sending a > non-immediate Text Request PDU, regardless of whether the Final and/or > Continuation flags are set in the PDU header. CmdSN should never beadvanced, > however, after sending an immediate Text Request PDU. Correct. > The target should always increment StatSN after sending a Text Response PDU, > regardless of the values of the Final and Continuation flags in the > PDU header. Correct again. > Is this a correct understanding of CmdSN and StatSN operation in Text PDUs? > (Note: For the purposes of this question, I'm ignoring the case of Text PDU > retransmissions caused by SNACKs, digest errors, or timeouts when > ErrorRecoveryLevel >0.) > thanks, > Dean Scoville Correct on both - Julo --=_alternative 002EBD71C2256E1C_= Content-Type: text/html; charset="US-ASCII"
Dean,

"Dean Scoville" <dean.scoville@qlogic.com> wrote on 14/01/2004 20:43:58:

> Julian,
> Could you please confirm whether my understanding of CmdSN and StatSN for
> Text PDUs is correct? The behavior of CmdSN when C=1 isn't explicitly stated
> in the draft, so I'm assuming CmdSN is still advanced. Here are my thoughts:
>    The initiator should always increment CmdSN after sending a
>    non-immediate Text Request PDU, regardless of whether the Final and/or
>    Continuation flags are set in the PDU header. CmdSN should never beadvanced,
>    however, after sending an immediate Text Request PDU.

Correct.

>    The target should always increment StatSN after sending a Text Response PDU,
>    regardless of the values of the Final and Continuation flags in the
> PDU header.

Correct again.

> Is this a correct understanding of CmdSN and StatSN operation in Text PDUs?
> (Note: For the purposes of this question, I'm ignoring the case of Text PDU
> retransmissions caused by SNACKs, digest errors,  or timeouts when
> ErrorRecoveryLevel >0.)
> thanks,
> Dean Scoville

Correct on both - Julo --=_alternative 002EBD71C2256E1C_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 15 16:27:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29818 for ; Thu, 15 Jan 2004 16:27:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhF1O-0002tY-Bl for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 16:27:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FLRMZ5011128 for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 16:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhF1O-0002tP-7B for ips-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 16:27:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29741 for ; Thu, 15 Jan 2004 16:27:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhF1L-0003Ko-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 16:27:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhEzm-00035c-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 16:25:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhEyl-0002qt-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 16:24:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhEyD-0001pa-Qp; Thu, 15 Jan 2004 16:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDrC-0007aN-PS for ips@optimus.ietf.org; Thu, 15 Jan 2004 15:12:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25679 for ; Thu, 15 Jan 2004 15:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhDrB-0007TJ-00 for ips@ietf.org; Thu, 15 Jan 2004 15:12:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhDqA-0007NC-00 for ips@ietf.org; Thu, 15 Jan 2004 15:11:43 -0500 Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx with esmtp (Exim 4.12) id 1AhDpG-0007Ew-00 for ips@ietf.org; Thu, 15 Jan 2004 15:10:47 -0500 Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.12.10/8.12.10) with ESMTP id i0FK7xoF006177; Thu, 15 Jan 2004 15:07:59 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.10/8.12.10/Submit) with ESMTP id i0FK7xZm006173; Thu, 15 Jan 2004 15:07:59 -0500 Date: Thu, 15 Jan 2004 15:07:59 -0500 (EST) From: "Robert D. Russell" To: Julian Satran cc: ips@ietf.org Subject: Re: [Ips] ABORT of immediate commands In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Julian: I have a question about what Response code a target should send in the following situation. 1. An initiator sends an immediate command, with I=1, ITT=t, and CmdSN = x. 2. At some later time, the initiator decides to abort that task, so it sends a task management function request with I=1, ITT=u, RTT=t, CmdSN = y and RefCmdSN = y (CmdSN = y = RefCmdSN in order to refer to an immediate command as required by 10.5.5), and y is within the valid CmdSN window. 3. The target receives the task management function request to abort RTT = t, but it cannot find this task (either because it never received it or because it already finished it or whatever...) The 3 cases listed in 10.6.1 for the ABORT TASK function do not seem to apply in this case, because: a) the RTT does not identify a valid task b) the RefCmdSN is not less than the CmdSN in the TM request c) the RefCmdSN is not outside the valid CmdSN Since none of these 3 cases apply, should the target respond with "Function complete", by analogy with point b), or with "Task does not exist", by analogy with point c)? My preference would be point b), "Function Complete", but clearly it could go either way. In either case, perhaps a clarification is needed as a separate point for aborting tasks (essentially corresponding with the separate point described in 10.5.5 to deal with tasks created by immediate commands): d) If the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Management function request equals the CmdSN field in the Task Management function request, then targets must return the "xxxx" response. Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 15 17:23:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05452 for ; Thu, 15 Jan 2004 17:23:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFtK-0007G3-1A for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 17:23:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FMN6AY027893 for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 17:23:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFtJ-0007Fn-T3 for ips-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 17:23:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05394 for ; Thu, 15 Jan 2004 17:23:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFtH-0001ew-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 17:23:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFsI-0001Yo-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 17:22:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhFrN-0001Qc-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 17:21:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFrM-0006yZ-9i; Thu, 15 Jan 2004 17:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFqy-0006u9-PR for ips@optimus.ietf.org; Thu, 15 Jan 2004 17:20:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05047 for ; Thu, 15 Jan 2004 17:20:37 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFqw-0001K9-00 for ips@ietf.org; Thu, 15 Jan 2004 17:20:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFpE-00018e-00 for ips@ietf.org; Thu, 15 Jan 2004 17:18:53 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AhFoh-000163-00 for ips@ietf.org; Thu, 15 Jan 2004 17:18:19 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 4DAB840134; Thu, 15 Jan 2004 17:18:14 -0500 (EST) Date: Thu, 15 Jan 2004 14:13:58 -0800 (PST) X-X-Sender: wrstuden@neverwinter To: "Nicholas A. Bellinger" Cc: ips@ietf.org Subject: Re: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue In-Reply-To: <1074147130.1239.586.camel@subjekt.volcom.net> Message-ID: References: <1073884805.1239.102.camel@subjekt.volcom.net> <1074062880.1239.373.camel@subjekt.volcom.net> <1074147130.1239.586.camel@subjekt.volcom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Wed, 14 Jan 2004, Nicholas A. Bellinger wrote: > On Wed, 2004-01-14 at 07:40, wrstuden@wasabisystems.com wrote: > > On Tue, 13 Jan 2004, Nicholas A. Bellinger wrote: > > > > > > The "logical" reason for the initiator to choose CSM-E recovery is that > > that is what the initiator author(s) chose to do. Just because it is not > > your choice does not mean it won't be someone else's choice. > > No, the "logical" reason is that no-one can name a single reason why > CSM-E would occur during normal operation in a single connection > ErrorRecoveryLevel=2 session in the first place. Furthermore I have yet > to encounter an ErrorRecoveryLevel=2 Initiator that takes this approach, > or any other technical reason why needing to have two approaches other > than to give Initiator authors more 'choice' ensures interoperability. With the "logic" you are showing above, no one will ever convince you of a thing - you seem to have already convinced yourself. > If imposing a small restriction (how hard can it be to use a CID from a > failed connection as opposed to assigning a new one?) ensures > interopability between ErrorRecoveryLevel=2 implementations than it is a > small price to pay to avoid single connection ErrorRecoveryLevel=2 > implementations from potentially falling back to Session Reinstatement > aka 'Degraded Mode' every time. > > Considering the passage in section 3.2.1 that you continuously sight as > a reason to prevent a simpler and more effective method of ensuring > interoperability is a SHOULD, there is a very obvious interoptability > hole that needs to be closed. From RFC 2119, 'SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.' "I think it would be cleaner to never exceed MaxConnections ever" does not strike me, personally, as a valid reason to violate this SHOULD. The fact the text is there and survived the many-year development process indicates that the WG didn't find it a concern. I also did not find it terribly difficult to implement. You speak of a better way of ensuring interoperability and a hole that needs closing. The hole is not the spec, it is a target that chose to ignore a SHOULD. That target should receive the blunt of concern regarding interop issues; it made a decision against a recomendation in the spec. Also, you are talking about ERL=2. What about ERL=0 or ERL=1? Here, CSM-E is the best choice for recovery, as it gives you final status for the tasks; you know which tasks were completed during the connection failures and which got killed. > > You say that doing things this way would permit always enforcing > > MaxConnections. You are correct. However to make a difference in the > > targets (to have a strong impact), targets have to be coded to ignore the > > SHOULD in the spec concerning MaxConnections & error recovery. That's > > changing the spec; I don't think your discussion above is an appropriate > > technical reason for a target to ignore the spec. > > > > This SHOULD is the interoperability problem for ErrorRecoveryLevel=2 > implementations I am trying to close. Consider the two following > implementation scenraios operating in a multi-vendor enviroment given > the following methods of iSCSI vendor X and vendor Y: > > iSCSI Target Vendor X: Enforces a MaxConnections check after Connection > Reinstatement occurs. > > iSCSI Target Vendor Y: Allows MaxConnections to be exceeded at any time. > > Scenario 0: > > iSCSI Initiator Vendor A: Performs Session Continuation by way of > continutions Connection Reinstatement (CSM-I). > > Interoptiablity Issues: > > iSCSI Target Vendor X: None > > iSCSI Target Vendor Y: None. > > Scenario 1: > > iSCSI Initiator Vendor B: Performs Session Continuation by way of > creating a new connection with a different CID, and logging out the > failed connection with a explict logout request. (CSM-E). > > Interoptiablity Issues: > > iSCSI Target Vendor X: MaxConnections is enforced as section 3.2.1 > defines a SHOULD instead of a MUST. The login attempt is with rejected > with a Status Class/Detail of 0x0206. Vendor X distrgarded a SHOULD. Problems may result. And you still have session recovery, so you're not out of recovery options. Thus the initiator and target can still interoperate, even if it's not as nicely as you'd wish. > iSCSI Target Vendor Y: None. > > It comes down to one of two options the working group has in order to > prevent the clear interoperability issue between ErrorRecoveryLevel=2 > implementations described above. > > 0: Change the SHOULD to a MUST in section 3.2.1 and require all Targets > to exceed MaxConnections for the sole purpose of creating more 'choice' > for Initiator Authors. Additionally, not a _single_ technicial reason > has been raised that explains why CSM-E should ever happen during normal > operation in a single connection ErrorRecoveryLevel=2 session. > > OR > > 1: Require ErrorRecoveryLevel=2 Initiator Implementations to perform > Connection Resinstatement (CSM-I) before attempting to start a new > connection with a different CID (CSM-E). This allows targets to enforce > MaxConnections. Actually, there is a third option. You have a configuration that contains a target which is violating a SHOULD. You should ether accept that you may have issues, and/or you should raise the issue with the target vendor. The reason, as I understand it, that this section is a SHOULD and not a MUST is so that iSCSI can support (for some value of support) exceptionally simplistic targets. Say one that only only only supported one connection and thus one session. > Additionally I believe it has been proven beyond a reasonable doubt that > the correct location to perform Connection Reinstatement on a Target is > after a succcessful SecurityNegotiation or upon reciept of a Login > Request containing CSG=1 and NSG=[1,3], and before MaxConnections is > checked. I believe the 'reinstatement failed' state mentioned in the > previous replys is a clear indication of why this is the appropriate > place, and when used in conjunction with the second option mentioned > above allows for interoperable ErrorRecoveryLevel=2 implementations with > the desired side effect of enforcing the negotiated MaxConnections key. > > Consensus Please? I doubt you'll get concensus. Concensus is everyone coming together to work something out. The tone of your notes does not seem condusive to you shifting position. In fact, the notes sound much more like you are trying to bludgeon us into agreeing with you rather than actually discussing things. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 15 17:53:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06523 for ; Thu, 15 Jan 2004 17:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGMH-0000ek-7t for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 17:53:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FMr152002516 for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 17:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGMG-0000eV-Ny for ips-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 17:53:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06476 for ; Thu, 15 Jan 2004 17:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhGME-0003MZ-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 17:52:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhGLR-0003IG-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 17:52:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhGKX-0003DZ-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 17:51:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGKL-0000SH-8K; Thu, 15 Jan 2004 17:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGKD-0000Q6-0H for ips@optimus.ietf.org; Thu, 15 Jan 2004 17:50:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06354 for ; Thu, 15 Jan 2004 17:50:49 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhGKA-0003Br-00 for ips@ietf.org; Thu, 15 Jan 2004 17:50:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhGJ9-0003A3-00 for ips@ietf.org; Thu, 15 Jan 2004 17:49:47 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AhGIo-00038i-00 for ips@ietf.org; Thu, 15 Jan 2004 17:49:26 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 3099240134; Thu, 15 Jan 2004 17:49:27 -0500 (EST) Date: Thu, 15 Jan 2004 14:45:11 -0800 (PST) X-X-Sender: wrstuden@neverwinter To: "Robert D. Russell" Cc: Julian Satran , ips@ietf.org Subject: Re: [Ips] ABORT of immediate commands In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Thu, 15 Jan 2004, Robert D. Russell wrote: > Julian: > > I have a question about what Response code a target should send > in the following situation. Hmmm... It's a good one. > 1. An initiator sends an immediate command, with I=1, ITT=t, > and CmdSN = x. > > 2. At some later time, the initiator decides to abort that task, > so it sends a task management function request with I=1, ITT=u, > RTT=t, CmdSN = y and RefCmdSN = y (CmdSN = y = RefCmdSN in > order to refer to an immediate command as required by 10.5.5), > and y is within the valid CmdSN window. > > 3. The target receives the task management function request to abort > RTT = t, but it cannot find this task (either because it > never received it or because it already finished it or whatever...) > The 3 cases listed in 10.6.1 for the ABORT TASK function do not > seem to apply in this case, because: > a) the RTT does not identify a valid task > b) the RefCmdSN is not less than the CmdSN in the TM request > c) the RefCmdSN is not outside the valid CmdSN > > Since none of these 3 cases apply, should the target respond with > "Function complete", by analogy with point b), or with > "Task does not exist", by analogy with point c)? > > My preference would be point b), "Function Complete", but clearly > it could go either way. I'd say the right response is "Task does not exist." I took the "command does not exist but CmdSN is in window" case as applying to non-immediate commands only. In that case we build a "never run me I've already been aborted" entry in the CmdSN-waiting-queue. We then return "Function Complete" as we have aborted this command we haven't received yet. :-) It's a way to abort commands while we're in cleanup/facing connectivity issues. Or so I thought. > In either case, perhaps a clarification is needed as a separate point for > aborting tasks (essentially corresponding with the separate point described > in 10.5.5 to deal with tasks created by immediate commands): > > d) If the Referenced Task Tag does not identify an existing > task but if the CmdSN indicated by the RefCmdSN field in the > Task Management function request equals the CmdSN field in the > Task Management function request, then targets must return the > "xxxx" response. Agreed, clarification is good. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 15 23:37:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16467 for ; Thu, 15 Jan 2004 23:37:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhLiI-00006d-Q1 for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 23:36:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G4a6Tb000403 for ips-archive@odin.ietf.org; Thu, 15 Jan 2004 23:36:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhLiI-00006Q-KK for ips-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 23:36:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16420 for ; Thu, 15 Jan 2004 23:35:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhLiB-00014o-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 23:35:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhLhF-00012A-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 23:35:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhLgJ-0000zL-00 for ips-web-archive@ietf.org; Thu, 15 Jan 2004 23:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhLgG-0008OH-GO; Thu, 15 Jan 2004 23:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhLgE-0008O4-KI for ips@optimus.ietf.org; Thu, 15 Jan 2004 23:33:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16359 for ; Thu, 15 Jan 2004 23:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhLgC-0000yB-00 for ips@ietf.org; Thu, 15 Jan 2004 23:33:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhLfF-0000wX-00 for ips@ietf.org; Thu, 15 Jan 2004 23:32:58 -0500 Received: from adsl-67-124-61-228.dsl.snfc21.pacbell.net ([67.124.61.228] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1AhLel-0000ta-00 for ips@ietf.org; Thu, 15 Jan 2004 23:32:27 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1AhLV1-00033y-00; Thu, 15 Jan 2004 20:22:23 -0800 Subject: Re: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue From: "Nicholas A. Bellinger" To: wrstuden@wasabisystems.com Cc: ips@ietf.org Content-Type: text/plain Message-Id: <1074226942.1239.790.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 15 Jan 2004 20:22:23 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thur, 15 Jan 2005, wrstuden@wasabisystems.com wrote: > On Wed, 14 Jan 2004, Nicholas A. Bellinger wrote: > > On Wed, 2004-01-14 at 07:40, wrstuden@wasabisystems.com wrote: > > > > > > > > > The "logical" reason for the initiator to choose CSM-E recovery is that > > > that is what the initiator author(s) chose to do. Just because it is not > > > your choice does not mean it won't be someone else's choice. > > > > No, the "logical" reason is that no-one can name a single reason why > > CSM-E would occur during normal operation in a single connection > > ErrorRecoveryLevel=2 session in the first place. Furthermore I have yet > > to encounter an ErrorRecoveryLevel=2 Initiator that takes this approach, > > or any other technical reason why needing to have two approaches other > > than to give Initiator authors more 'choice' ensures interoperability. > With the "logic" you are showing above, no one will ever convince you of a > thing - you seem to have already convinced yourself. I can be convinced by a solid technical reason. I have yet to see a single response other than 'more choice for Initiator Authors' to any of the previous challenges regarding this issue. > > If imposing a small restriction (how hard can it be to use a CID from a > > failed connection as opposed to assigning a new one?) ensures > > interopability between ErrorRecoveryLevel=2 implementations than it is a > > small price to pay to avoid single connection ErrorRecoveryLevel=2 > > implementations from potentially falling back to Session Reinstatement > > aka 'Degraded Mode' every time. > > > > Considering the passage in section 3.2.1 that you continuously sight as > > a reason to prevent a simpler and more effective method of ensuring > > interoperability is a SHOULD, there is a very obvious interoptability > > hole that needs to be closed. > "I think it would be cleaner to never exceed MaxConnections ever" does >not strike me, personally, as a valid reason to violate this SHOULD. > The fact the text is there and survived the many-year development > process indicates that the WG didn't find it a concern. I also did not > find it terribly difficult to implement. > > You speak of a better way of ensuring interoperability and a hole that > needs closing. The hole is not the spec, it is a target that chose to > ignore a SHOULD. That target should receive the blunt of concern regarding > interop issues; it made a decision against a recomendation in the spec. This has nothing to do with difficultly of implementing. As I have stated in previous emails, there is a situation where by a user involked action in single connection ErrorRecoveryLevel=2 where temporarly exceeding MaxConnections should be allowed when the IP Address and Communication Port of CSM-I is no longer active, and hence preventing Session Reinstatement from having to occur. This is the only situation where exceeding MaxConnections is useful and is a situation we currently support in our Initiator. If a SHOULD causes ErrorRecoveryLevel=2 implementations to fall back to Session Reinstatement every time, then there is a problem. The SHOULD needs to be changed to a MUST. > Also, you are talking about ERL=2. What about ERL=0 or ERL=1? Here, CSM-E > is the best choice for recovery, as it gives you final status for the > tasks; you know which tasks were completed during the connection failures > and which got killed. I have already covered all non ERL=2 situations in previous emails. We can agree that the one half of CSM-E, an explict logout by way of a Logout Request with ReasonCode=2 is strictly an ErrorRecoveryLevel=2 feature. Lets focus on the other half of CSM-E, a Logout Request with ReasonCode 1. Saying that an Explict Logout with ReasonCode 1 in CSM-E is the 'best choice' for recovery because it contains the ExpStatSN of the Connection to be closed so it can be determined which 'tasks were completed during the connection failures and which got killed' is a incorrect. An implict Logout by way of CSM-I contains the very same ExpStatSN value. (See section 10.12.9) If this was an incorrect assumption as to why you deam CSM-E as the 'best choice' for non ERL=2 implementations to perform Session Continuation, I am waiting to be corrected. > > > You say that doing things this way would permit always enforcing > > > MaxConnections. You are correct. However to make a difference in the > > > targets (to have a strong impact), targets have to be coded to ignore the > > > SHOULD in the spec concerning MaxConnections & error recovery. That's > > > changing the spec; I don't think your discussion above is an appropriate > > > technical reason for a target to ignore the spec. > > > > > > > This SHOULD is the interoperability problem for ErrorRecoveryLevel=2 > > implementations I am trying to close. Consider the two following > > implementation scenraios operating in a multi-vendor enviroment given > > the following methods of iSCSI vendor X and vendor Y: > > > > iSCSI Target Vendor X: Enforces a MaxConnections check after Connection > > Reinstatement occurs. > > > > iSCSI Target Vendor Y: Allows MaxConnections to be exceeded at any time. > > > > Scenario 0: > > > > iSCSI Initiator Vendor A: Performs Session Continuation by way of > > continutions Connection Reinstatement (CSM-I). > > > > Interoptiablity Issues: > > > > iSCSI Target Vendor X: None > > > > iSCSI Target Vendor Y: None. > > > > Scenario 1: > > > > iSCSI Initiator Vendor B: Performs Session Continuation by way of > > creating a new connection with a different CID, and logging out the > > failed connection with a explict logout request. (CSM-E). > > > > Interoptiablity Issues: > > > > iSCSI Target Vendor X: MaxConnections is enforced as section 3.2.1 > > defines a SHOULD instead of a MUST. The login attempt is with rejected > > with a Status Class/Detail of 0x0206. > > Vendor X distrgarded a SHOULD. Problems may result. Again, this SHOULD needs to be a MUST to prevent a interoperability issue > And you still have session recovery, so you're not out of recovery > options. Thus the initiator and target can still interoperate, even if > it's not as nicely as you'd wish. This is obvious, as quoted in the 2nd paragraph of my reply: "from potentially falling back to Session Reinstatement aka 'Degraded Mode' every time." > > iSCSI Target Vendor Y: None. > > > > It comes down to one of two options the working group has in order to > > prevent the clear interoperability issue between ErrorRecoveryLevel=2 > > implementations described above. > > > > 0: Change the SHOULD to a MUST in section 3.2.1 and require all Targets > > to exceed MaxConnections for the sole purpose of creating more 'choice' > > for Initiator Authors. Additionally, not a _single_ technicial reason > > has been raised that explains why CSM-E should ever happen during normal > > operation in a single connection ErrorRecoveryLevel=2 session. > > > > OR > > > > 1: Require ErrorRecoveryLevel=2 Initiator Implementations to perform > > Connection Resinstatement (CSM-I) before attempting to start a new > > connection with a different CID (CSM-E). This allows targets to enforce > > MaxConnections. > Actually, there is a third option. You have a configuration that contains > a target which is violating a SHOULD. You should ether accept that you may > have issues, and/or you should raise the issue with the target vendor. > I have no issues whatsoever. It is the oppososing point of view here that seems to be encourging a interoperability hole caused by a vauge SHOULD to be left open. > The reason, as I understand it, that this section is a SHOULD and not a > MUST is so that iSCSI can support (for some value of support) > exceptionally simplistic targets. Say one that only only only supported > one connection and thus one session. Section 3.2.1: "targets and initiators that support a single active connection in a session SHOULD support two connections during recovery." The key word being 'during recovery'. Well what type of recovery could this mean? Session Recovery: This is the most basic form of recovery that 'exceptionally simplistic' implementations would support. This form has no bearing on extra connection(s) needing to be started.. Leaving the 'exceptionally simplistic' field we have Session Continuation: Connection Reinstatement (both ERL=2 and non ERL=2): During normal operation, the SHOULD does not apply. Explict Logout with ReasonCode 1 in non ERL=2: During normal operation the SHOULD applies. Explict Logout with ReasonCode 1 in ERL=2: Not used in the context of recovery, see ReasonCode 2. Explict Logout with ReasonCode 2 in non ERL=2: Illegal, see Logout Response ResponseCode 2. Explict Logout with ReasonCode 2 in ERL=2: During normal operation the SHOULD applies in a Single Connection Session Only. Considering 'exceptionally simplistic' really only means Session Recovery, I see the above interpretation as being incorrect. Under the assumption that a implementation that supports more than Session Recovery (ie: Session Continuation) is beyond the realm of simplistic, it works out to: "targets and initiators that support a single active connection in a session and support session continuation (see Section 5.3.6), MUST support two connections during continuation." This means that _only_ when MaxConnections=1 (as with the original passage) is it legal to exceed MaxConnections to 2 when Session Continuation is supported on the Target. Exceeding MaxConnections when MaxConnections!=1 is clearly a violation of the above as well as orignal passage. > > Additionally I believe it has been proven beyond a reasonable doubt that > > the correct location to perform Connection Reinstatement on a Target is > > after a succcessful SecurityNegotiation or upon reciept of a Login > > Request containing CSG=1 and NSG=[1,3], and before MaxConnections is > > checked. I believe the 'reinstatement failed' state mentioned in the > > previous replys is a clear indication of why this is the appropriate > > place, and when used in conjunction with the second option mentioned > > above allows for interoperable ErrorRecoveryLevel=2 implementations with > > the desired side effect of enforcing the negotiated MaxConnections key. > > > > Consensus Please? > > I doubt you'll get concensus. Concensus is everyone coming together to > work something out. The tone of your notes does not seem condusive to you > shifting position. In fact, the notes sound much more like you are trying > to bludgeon us into agreeing with you rather than actually discussing > things. If bludgeoning involves making solid technical point after technical point including unearthing an interoperability issue, then I am guilty. (I would be more than happy to list them all again if need be :-) This is not about who is right or wrong, but about closing an issue that exists because of a SHOULD. My only concern is with fostering an enviroment where ErrorRecoveryLevel=2 implementations run at ErrorRecoveryLevel=2, and not in some type of degraded mode. The latter is a very real possibly if the vauge SHOULD in the final sentance of section 3.2.1 is not changed to a clear MUST. Please, comments from someone besides Bill and I? Mallikarjun? -- Nicholas A. Bellinger P.S: Or we can simply follow the 2nd option made in my previous reply that makes the this whole debate invalid in all but a single user involked case. :-)) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 16 00:52:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18495 for ; Fri, 16 Jan 2004 00:52:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMtm-0003O9-DX for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 00:52:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G5q2vd013024 for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 00:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMtm-0003Nz-A9 for ips-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 00:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18447 for ; Fri, 16 Jan 2004 00:51:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhMtj-0004BU-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 00:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhMt4-00048q-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 00:51:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhMs4-00046O-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 00:50:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMrs-0003Bb-ND; Fri, 16 Jan 2004 00:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMrn-0003AU-T2 for ips@optimus.ietf.org; Fri, 16 Jan 2004 00:49:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18358 for ; Fri, 16 Jan 2004 00:49:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhMrl-00044E-00 for ips@ietf.org; Fri, 16 Jan 2004 00:49:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhMqp-00041Z-00 for ips@ietf.org; Fri, 16 Jan 2004 00:49:00 -0500 Received: from web42006.mail.yahoo.com ([66.218.93.174]) by ietf-mx with smtp (Exim 4.12) id 1AhMpw-0003xF-00 for ips@ietf.org; Fri, 16 Jan 2004 00:48:05 -0500 Message-ID: <20040116054734.73481.qmail@web42006.mail.yahoo.com> Received: from [66.134.241.90] by web42006.mail.yahoo.com via HTTP; Thu, 15 Jan 2004 21:47:34 PST Date: Thu, 15 Jan 2004 21:47:34 -0800 (PST) From: Alberto Alesina To: ips@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1463442521-1074232054=:70804" Subject: [Ips] iSCSI connections Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1463442521-1074232054=:70804 Content-Type: text/plain; charset=us-ascii hello all, Can it be possible that two different iSCSI sessions between an initiator and a target use the same TCP connection (i.e. use the same TCP socket because the TCP session endpoint identifiers are same)? The assumption is that the target has nodes with multiple target portal groups but just one network portal (IP address and TCP port number). Also, can it be possible to have two logical iSCSI connections for a single iSCSI session and they use the same underlying TCP connection (same socket)? Thanks a lot for your time. Alberto Alesina --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1463442521-1074232054=:70804 Content-Type: text/html; charset=us-ascii
hello all,
 
Can it be possible that two different iSCSI sessions between an initiator and a target use the same TCP connection (i.e. use the same TCP socket because the TCP session endpoint identifiers are same)? The assumption is that the target has nodes with multiple target portal groups but just one network portal (IP address and TCP port number).
 
Also, can it be possible to have two logical iSCSI connections for a single iSCSI session and they use the same underlying TCP connection (same socket)?
 
 
Thanks a lot for your time.
 
Alberto Alesina

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1463442521-1074232054=:70804-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 16 11:34:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20619 for ; Fri, 16 Jan 2004 11:34:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWrp-0002O5-7h for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 11:30:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GGUfP1009178 for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 11:30:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWrp-0002Nx-24 for ips-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 11:30:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20332 for ; Fri, 16 Jan 2004 11:30:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhWro-0006VW-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 11:30:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhWqt-0006QC-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 11:29:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhWqO-0006Lf-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 11:29:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWqD-0002D3-OZ; Fri, 16 Jan 2004 11:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhWpQ-00029D-S8 for ips@optimus.ietf.org; Fri, 16 Jan 2004 11:28:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20213 for ; Fri, 16 Jan 2004 11:28:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhWpP-0006GU-00 for ips@ietf.org; Fri, 16 Jan 2004 11:28:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhWng-0006Av-00 for ips@ietf.org; Fri, 16 Jan 2004 11:26:24 -0500 Received: from ns.equallogic.com ([66.155.203.134] helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1AhWlD-0005yq-00 for ips@ietf.org; Fri, 16 Jan 2004 11:23:51 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i0GGMt6a022722 for ; Fri, 16 Jan 2004 11:22:55 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i0GGMqIg022717; Fri, 16 Jan 2004 11:22:52 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id i0GGMqQ08086; Fri, 16 Jan 2004 11:22:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16392.4060.698348.288011@gargle.gargle.HOWL> Date: Fri, 16 Jan 2004 11:22:52 -0500 From: Paul Koning To: aalesina@yahoo.com Cc: ips@ietf.org Subject: Re: [Ips] iSCSI connections References: <20040116054734.73481.qmail@web42006.mail.yahoo.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Alberto" == Alberto Alesina writes: Alberto> hello all, Can it be possible that two different iSCSI Alberto> sessions between an initiator and a target use the same TCP Alberto> connection (i.e. use the same TCP socket because the TCP Alberto> session endpoint identifiers are same)? The assumption is Alberto> that the target has nodes with multiple target portal groups Alberto> but just one network portal (IP address and TCP port Alberto> number). No. The target side identifiers are the same for all the connections to that portal, but the initiator side identifiers are different for all the connections. You can't have multiple sessions in the same TCP connection because there are no application layer addresses (session identifiers, for example) in the iSCSI PDU header. So the session is implicit from the TCP connection, which means that each TCP connection is bound to exactly one session. Alberto> Also, can it be possible to have two logical iSCSI Alberto> connections for a single iSCSI session and they use the same Alberto> underlying TCP connection (same socket)? No -- same reason. It would be pointless to do so anyway. Multiple connections per session may improve performance and reliability, but only if they have separate TCP connections (and at least some of the network resources used by those connections differ). paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 16 18:44:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05452 for ; Fri, 16 Jan 2004 18:44:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahdcs-00059R-UB for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 18:43:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GNhgek019797 for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 18:43:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahdcs-00059E-OL for ips-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 18:43:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05449 for ; Fri, 16 Jan 2004 18:43:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahdcp-0004iK-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 18:43:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahdbr-0004fT-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 18:42:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhdbO-0004ck-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 18:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhdbE-00050o-K8; Fri, 16 Jan 2004 18:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahdas-0004zl-4t for ips@optimus.ietf.org; Fri, 16 Jan 2004 18:41:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05371 for ; Fri, 16 Jan 2004 18:41:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahdao-0004bM-00 for ips@ietf.org; Fri, 16 Jan 2004 18:41:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhdZu-0004Z1-00 for ips@ietf.org; Fri, 16 Jan 2004 18:40:39 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1AhdZI-0004WL-00 for ips@ietf.org; Fri, 16 Jan 2004 18:40:00 -0500 Received: from rosemail.rose.hp.com (postal.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id 784BA1C010AC; Fri, 16 Jan 2004 18:40:00 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bea179.rose.hp.com [15.23.140.179]) by rosemail.rose.hp.com (Postfix) with ESMTP id DED0D80E5; Fri, 16 Jan 2004 15:36:25 -0800 (PST) Message-ID: <40087647.3090600@rose.hp.com> Date: Fri, 16 Jan 2004 15:39:51 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Robert D. Russell" Cc: Julian Satran , ips@ietf.org Subject: Re: [Ips] ABORT of immediate commands References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My recollection is that "Function Complete" was meant to be returned for all "valid" abort requests - "valid" being within the CmdSN window. Clarifying so would also be consistent with the last para in section 6.9. IIRC, the special casing for immediate commands (RefCmdSN=CmdSN) was introduced a little later in iSCSI's design thus leaving the original text incomplete. My suggestion would be to provide two clarifications - a) Add "(or Referenced Task Tag in the case of immediate commands)" to last para in 6.9 so it becomes: "If the abort request is received and the original command is missing, targets MUST consider the original command with that RefCmdSN (or Referenced Task Tag in the case of immediate commands) to be received and issue a Task Management response with the response code: "Function Complete". This response concludes the task on both ends." b) Add "or equal to" to the 10.6.1 bullet (b) so it in part becomes: "....is within the valid CmdSN window and less than or equal to the CmdSN of the Task Management function request itself,...." -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Robert D. Russell wrote: > Julian: > > I have a question about what Response code a target should send > in the following situation. > > 1. An initiator sends an immediate command, with I=1, ITT=t, > and CmdSN = x. > > 2. At some later time, the initiator decides to abort that task, > so it sends a task management function request with I=1, ITT=u, > RTT=t, CmdSN = y and RefCmdSN = y (CmdSN = y = RefCmdSN in > order to refer to an immediate command as required by 10.5.5), > and y is within the valid CmdSN window. > > 3. The target receives the task management function request to abort > RTT = t, but it cannot find this task (either because it > never received it or because it already finished it or whatever...) > The 3 cases listed in 10.6.1 for the ABORT TASK function do not > seem to apply in this case, because: > a) the RTT does not identify a valid task > b) the RefCmdSN is not less than the CmdSN in the TM request > c) the RefCmdSN is not outside the valid CmdSN > > Since none of these 3 cases apply, should the target respond with > "Function complete", by analogy with point b), or with > "Task does not exist", by analogy with point c)? > > My preference would be point b), "Function Complete", but clearly > it could go either way. > > In either case, perhaps a clarification is needed as a separate point for > aborting tasks (essentially corresponding with the separate point described > in 10.5.5 to deal with tasks created by immediate commands): > > d) If the Referenced Task Tag does not identify an existing > task but if the CmdSN indicated by the RefCmdSN field in the > Task Management function request equals the CmdSN field in the > Task Management function request, then targets must return the > "xxxx" response. > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > _______________________________________________ > 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 exim@www1.ietf.org Fri Jan 16 20:04:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08268 for ; Fri, 16 Jan 2004 20:04:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhesY-0000oK-9x for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 20:03:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0H13wK4003110 for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 20:03:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhesX-0000o5-F7 for ips-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 20:03:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08257 for ; Fri, 16 Jan 2004 20:03:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhesQ-0001Zu-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 20:03:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aheq4-0001Qt-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 20:01:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aheo0-0001Kq-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 19:59:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahenk-0000SX-Hp; Fri, 16 Jan 2004 19:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahen7-0000GP-Et for ips@optimus.ietf.org; Fri, 16 Jan 2004 19:58:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08158 for ; Fri, 16 Jan 2004 19:58:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahen0-0001IH-00 for ips@ietf.org; Fri, 16 Jan 2004 19:58:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhekR-0001DO-00 for ips@ietf.org; Fri, 16 Jan 2004 19:55:37 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1Aheil-00016U-00 for ips@ietf.org; Fri, 16 Jan 2004 19:53:51 -0500 Received: from rosemail.rose.hp.com (postal.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 56E261C01335 for ; Fri, 16 Jan 2004 19:53:26 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bea179.rose.hp.com [15.23.140.179]) by rosemail.rose.hp.com (Postfix) with ESMTP id 708978006 for ; Fri, 16 Jan 2004 16:49:41 -0800 (PST) Message-ID: <40088773.8030105@rose.hp.com> Date: Fri, 16 Jan 2004 16:53:07 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue References: <1074226942.1239.790.camel@subjekt.volcom.net> In-Reply-To: <1074226942.1239.790.camel@subjekt.volcom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Please, comments from someone besides Bill and I? Mallikarjun? I don't claim to have followed this thread very closely, nor I may be able to. With that, a couple of quick comments. - A target normally supporting only one connection, in order to cater to a connection recovery attempt via implicit logout from an initiator seeing original connection to have failed on its end, has to implement most of the functionality required to support the same via an explicit logout with a new CID. IOW, target "almost" has to support two connections - if it promises to concurrently handle two active CSMs at somepoint (which is what connection recovery is). - Allowing an explicit logout approach from the initiator has the additional benefit that an initiator can choose to use a different Logout reason code from that implied based on operational ErrorRecoveryLevel (look at the table at the end of 10.14). E.g., despite an operationl ErrorRecoveryLevel=2, an initiator may simply close the failed connection (i.e. Reason code=1) via an explicit logout (i.e. CSM-E way). - OTOH, the above flexibility wasn't deemed critical to mandate multi-connection sessions for the first time in the spec - hence the SHOULD. - When the original text was written, the idea is that a "connection reinstatement" is a _successful_ act of replacing a connection with a new one where the new one inherits all the open tasks. So, I'm at a loss to follow what you mean by "doing connection reinstatement after SecurityNegotiation stage" - reinstatement can't be "done" without a successful FFP connection. I see no reason to change the original notion. The net is that I do not see an interoperability problem, nor anything that needs changing in the spec. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Nicholas A. Bellinger wrote: > On Thur, 15 Jan 2005, wrstuden@wasabisystems.com wrote: > > >>On Wed, 14 Jan 2004, Nicholas A. Bellinger wrote: >> >>>On Wed, 2004-01-14 at 07:40, wrstuden@wasabisystems.com wrote: >>> >>>> >>>>The "logical" reason for the initiator to choose CSM-E recovery is that >>>>that is what the initiator author(s) chose to do. Just because it is not >>>>your choice does not mean it won't be someone else's choice. >>> >>>No, the "logical" reason is that no-one can name a single reason why >>>CSM-E would occur during normal operation in a single connection >>>ErrorRecoveryLevel=2 session in the first place. Furthermore I have yet >>>to encounter an ErrorRecoveryLevel=2 Initiator that takes this approach, >>>or any other technical reason why needing to have two approaches other >>>than to give Initiator authors more 'choice' ensures interoperability. > > >>With the "logic" you are showing above, no one will ever convince you of a >>thing - you seem to have already convinced yourself. > > > I can be convinced by a solid technical reason. I have yet to see a single > response other than 'more choice for Initiator Authors' to any of the > previous challenges regarding this issue. > > > >>>If imposing a small restriction (how hard can it be to use a CID from a >>>failed connection as opposed to assigning a new one?) ensures >>>interopability between ErrorRecoveryLevel=2 implementations than it is a >>>small price to pay to avoid single connection ErrorRecoveryLevel=2 >>>implementations from potentially falling back to Session Reinstatement >>>aka 'Degraded Mode' every time. >>> >>>Considering the passage in section 3.2.1 that you continuously sight as >>>a reason to prevent a simpler and more effective method of ensuring >>>interoperability is a SHOULD, there is a very obvious interoptability >>>hole that needs to be closed. > > >>"I think it would be cleaner to never exceed MaxConnections ever" does >>not strike me, personally, as a valid reason to violate this SHOULD. >>The fact the text is there and survived the many-year development >>process indicates that the WG didn't find it a concern. I also did not >>find it terribly difficult to implement. >> >>You speak of a better way of ensuring interoperability and a hole that >>needs closing. The hole is not the spec, it is a target that chose to >>ignore a SHOULD. That target should receive the blunt of concern regarding >>interop issues; it made a decision against a recomendation in the spec. > > > This has nothing to do with difficultly of implementing. As I have stated > in previous emails, there is a situation where by a user involked action in > single connection ErrorRecoveryLevel=2 where temporarly exceeding > MaxConnections should be allowed when the IP Address and Communication Port > of CSM-I is no longer active, and hence preventing Session Reinstatement from > having to occur. This is the only situation where exceeding MaxConnections is > useful and is a situation we currently support in our Initiator. > > If a SHOULD causes ErrorRecoveryLevel=2 implementations to fall back to > Session Reinstatement every time, then there is a problem. The SHOULD needs to > be changed to a MUST. > > >>Also, you are talking about ERL=2. What about ERL=0 or ERL=1? Here, CSM-E >>is the best choice for recovery, as it gives you final status for the >>tasks; you know which tasks were completed during the connection failures >>and which got killed. > > > I have already covered all non ERL=2 situations in previous emails. > We can agree that the one half of CSM-E, an explict logout by way of a Logout > Request with ReasonCode=2 is strictly an ErrorRecoveryLevel=2 feature. Lets > focus on the other half of CSM-E, a Logout Request with ReasonCode 1. > > Saying that an Explict Logout with ReasonCode 1 in CSM-E is the 'best choice' > for recovery because it contains the ExpStatSN of the Connection to be closed so > it can be determined which 'tasks were completed during the connection failures > and which got killed' is a incorrect. An implict Logout by way of CSM-I > contains the very same ExpStatSN value. (See section 10.12.9) > > If this was an incorrect assumption as to why you deam CSM-E as the 'best choice' > for non ERL=2 implementations to perform Session Continuation, I am waiting to be > corrected. > > > >>>>You say that doing things this way would permit always enforcing >>>>MaxConnections. You are correct. However to make a difference in the >>>>targets (to have a strong impact), targets have to be coded to ignore the >>>>SHOULD in the spec concerning MaxConnections & error recovery. That's >>>>changing the spec; I don't think your discussion above is an appropriate >>>>technical reason for a target to ignore the spec. >>>> >>> >>>This SHOULD is the interoperability problem for ErrorRecoveryLevel=2 >>>implementations I am trying to close. Consider the two following >>>implementation scenraios operating in a multi-vendor enviroment given >>>the following methods of iSCSI vendor X and vendor Y: >>> >>>iSCSI Target Vendor X: Enforces a MaxConnections check after Connection >>>Reinstatement occurs. >>> >>>iSCSI Target Vendor Y: Allows MaxConnections to be exceeded at any time. >>> >>>Scenario 0: >>> >>>iSCSI Initiator Vendor A: Performs Session Continuation by way of >>>continutions Connection Reinstatement (CSM-I). >>> >>>Interoptiablity Issues: >>> >>>iSCSI Target Vendor X: None >>> >>>iSCSI Target Vendor Y: None. >>> >>>Scenario 1: >>> >>>iSCSI Initiator Vendor B: Performs Session Continuation by way of >>>creating a new connection with a different CID, and logging out the >>>failed connection with a explict logout request. (CSM-E). >>> >>>Interoptiablity Issues: >>> >>>iSCSI Target Vendor X: MaxConnections is enforced as section 3.2.1 >>>defines a SHOULD instead of a MUST. The login attempt is with rejected >>>with a Status Class/Detail of 0x0206. >> >>Vendor X distrgarded a SHOULD. Problems may result. > > > Again, this SHOULD needs to be a MUST to prevent a interoperability issue > > > >>And you still have session recovery, so you're not out of recovery >>options. Thus the initiator and target can still interoperate, even if >>it's not as nicely as you'd wish. > > > This is obvious, as quoted in the 2nd paragraph of my reply: > > "from potentially falling back to Session Reinstatement aka > 'Degraded Mode' every time." > > > >>>iSCSI Target Vendor Y: None. >>> >>>It comes down to one of two options the working group has in order to >>>prevent the clear interoperability issue between ErrorRecoveryLevel=2 >>>implementations described above. >>> >>>0: Change the SHOULD to a MUST in section 3.2.1 and require all Targets >>>to exceed MaxConnections for the sole purpose of creating more 'choice' >>>for Initiator Authors. Additionally, not a _single_ technicial reason >>>has been raised that explains why CSM-E should ever happen during normal >>>operation in a single connection ErrorRecoveryLevel=2 session. >>> >>>OR >>> >>>1: Require ErrorRecoveryLevel=2 Initiator Implementations to perform >>>Connection Resinstatement (CSM-I) before attempting to start a new >>>connection with a different CID (CSM-E). This allows targets to enforce >>>MaxConnections. > > >>Actually, there is a third option. You have a configuration that contains >>a target which is violating a SHOULD. You should ether accept that you may >>have issues, and/or you should raise the issue with the target vendor. >> > > > I have no issues whatsoever. It is the oppososing point of view here that > seems to be encourging a interoperability hole caused by a vauge SHOULD to > be left open. > > > >>The reason, as I understand it, that this section is a SHOULD and not a >>MUST is so that iSCSI can support (for some value of support) >>exceptionally simplistic targets. Say one that only only only supported >>one connection and thus one session. > > > Section 3.2.1: > > "targets and initiators that support a single active connection in a > session SHOULD support two connections during recovery." > > The key word being 'during recovery'. Well what type of recovery could > this mean? > > Session Recovery: This is the most basic form of recovery that > 'exceptionally simplistic' implementations would support. This form > has no bearing on extra connection(s) needing to be started.. > > Leaving the 'exceptionally simplistic' field we have Session > Continuation: > > Connection Reinstatement (both ERL=2 and non ERL=2): During normal > operation, the SHOULD does not apply. > > Explict Logout with ReasonCode 1 in non ERL=2: During normal operation > the SHOULD applies. > > Explict Logout with ReasonCode 1 in ERL=2: Not used in the context > of recovery, see ReasonCode 2. > > Explict Logout with ReasonCode 2 in non ERL=2: Illegal, see Logout > Response ResponseCode 2. > > Explict Logout with ReasonCode 2 in ERL=2: During normal operation the > SHOULD applies in a Single Connection Session Only. > > Considering 'exceptionally simplistic' really only means Session > Recovery, I see the above interpretation as being incorrect. Under the > assumption that a implementation that supports more than Session Recovery > (ie: Session Continuation) is beyond the realm of simplistic, it works > out to: > > "targets and initiators that support a single active connection in a > session and support session continuation (see Section 5.3.6), MUST support > two connections during continuation." > > This means that _only_ when MaxConnections=1 (as with the original passage) > is it legal to exceed MaxConnections to 2 when Session Continuation is > supported on the Target. Exceeding MaxConnections when MaxConnections!=1 is > clearly a violation of the above as well as orignal passage. > > > >>>Additionally I believe it has been proven beyond a reasonable doubt that >>>the correct location to perform Connection Reinstatement on a Target is >>>after a succcessful SecurityNegotiation or upon reciept of a Login >>>Request containing CSG=1 and NSG=[1,3], and before MaxConnections is >>>checked. I believe the 'reinstatement failed' state mentioned in the >>>previous replys is a clear indication of why this is the appropriate >>>place, and when used in conjunction with the second option mentioned >>>above allows for interoperable ErrorRecoveryLevel=2 implementations with >>>the desired side effect of enforcing the negotiated MaxConnections key. >>> >>>Consensus Please? >> >>I doubt you'll get concensus. Concensus is everyone coming together to >>work something out. The tone of your notes does not seem condusive to you >>shifting position. In fact, the notes sound much more like you are trying >>to bludgeon us into agreeing with you rather than actually discussing >>things. > > > If bludgeoning involves making solid technical point after technical point > including unearthing an interoperability issue, then I am guilty. (I would be > more than happy to list them all again if need be :-) > > This is not about who is right or wrong, but about closing an issue that > exists because of a SHOULD. My only concern is with fostering an enviroment > where ErrorRecoveryLevel=2 implementations run at ErrorRecoveryLevel=2, and > not in some type of degraded mode. The latter is a very real possibly if the > vauge SHOULD in the final sentance of section 3.2.1 is not changed to a clear > MUST. > > Please, comments from someone besides Bill and I? Mallikarjun? > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 16 23:36:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12911 for ; Fri, 16 Jan 2004 23:36:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhiC1-0002N9-2f for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 23:36:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0H4aHx9009119 for ips-archive@odin.ietf.org; Fri, 16 Jan 2004 23:36:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhiC0-0002Ms-I4 for ips-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 23:36:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12898 for ; Fri, 16 Jan 2004 23:36:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhiBx-00032i-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 23:36:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhiB5-00030J-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 23:35:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhiA8-0002xg-00 for ips-web-archive@ietf.org; Fri, 16 Jan 2004 23:34:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahi9q-0002A7-FX; Fri, 16 Jan 2004 23:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahi9c-00029i-L1 for ips@optimus.ietf.org; Fri, 16 Jan 2004 23:33:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12851 for ; Fri, 16 Jan 2004 23:33:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahi9Z-0002wJ-00 for ips@ietf.org; Fri, 16 Jan 2004 23:33:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahi8Z-0002tc-00 for ips@ietf.org; Fri, 16 Jan 2004 23:32:45 -0500 Received: from adsl-67-124-61-228.dsl.snfc21.pacbell.net ([67.124.61.228] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1Ahi7f-0002qL-00 for ips@ietf.org; Fri, 16 Jan 2004 23:31:48 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1Ahhrq-0003hV-00; Fri, 16 Jan 2004 20:15:26 -0800 Subject: Re: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue From: "Nicholas A. Bellinger" To: "Mallikarjun C." Cc: ips@ietf.org In-Reply-To: <40088773.8030105@rose.hp.com> References: <1074226942.1239.790.camel@subjekt.volcom.net> <40088773.8030105@rose.hp.com> Content-Type: text/plain Message-Id: <1074312925.1239.882.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 16 Jan 2004 20:15:25 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-01-16 at 16:53, Mallikarjun C. wrote: > > Please, comments from someone besides Bill and I? Mallikarjun? > > I don't claim to have followed this thread very closely, > nor I may be able to. With that, a couple of quick comments. > > - A target normally supporting only one connection, in > order to cater to a connection recovery attempt via > implicit logout from an initiator seeing original connection > to have failed on its end, has to implement most of the > functionality required to support the same via an explicit > logout with a new CID. IOW, target "almost" has to > support two connections - if it promises to concurrently > handle two active CSMs at somepoint (which is what > connection recovery is). > No disagreement here. The main topic for up for disscussion was when it is legal to exceed MaxConnections. The last sentance of section 3.2.1 seems to imply that this is only permitted when MaxConnections=1, and be bumped up to MaxConnections=2 for Session Continuation purposes. If this is a correct assumption, then I think changing a vauge 'in error recovery.' SHOULD into a clear MUST along the following lines does not break simple implementations that only support Session Recovery: "targets and initiators that support a single active connection in a session and support session continuation (see Section 5.3.6), MUST support two connections during continuation." This seems to be along the lines of what you mention above, and has the desired side effect of closing a interoperabililty issue on Targets that ignore a SHOULD, support Session Continuation, but do not support exceeding MaxConnections in any ErrorRecovery. The undesired outcome (espically in ErrorRecoveryLevel=2), is Initiators who perfer CSM-E to CSM-I having to falling back to Session Recovery every time. Also, there is the first paragraph of section 5.3.4: "In sessions with a single connection, this may imply the opening of a second connection with the sole purpose of cleaning up the first. Targets MUST support opening a second connection even when they do not support multiple connections in Full Feature Phase if ErrorRecoveryLevel is 2 and SHOULD support opening a second connection if ErrorRecoveryLevel is less than 2." This is more along of lines of what I think is correct, but seems to be at odds with the SHOULD from section 3.2.1. Also since its only mentioned in the context of Connection Reinstatement it many not fall under the guise of CSM-E to the reader. > - Allowing an explicit logout approach from the initiator > has the additional benefit that an initiator can choose > to use a different Logout reason code from that implied > based on operational ErrorRecoveryLevel (look at the > table at the end of 10.14). E.g., despite an operationl > ErrorRecoveryLevel=2, an initiator may simply close the > failed connection (i.e. Reason code=1) via an explicit > logout (i.e. CSM-E way). > I assume that a Logout Request with ReasonCode=2 must still follow an Logout Request with ReasonCode=1 if any active commands acknowledged by ExpCmdSN are intended to be reassigned to another opreational connection? I also assume its legal to only send a ReasonCode=1 if the Initiator intends to perform Session Continuation and the failed connection only contains commands greater than or equal to ExpCmdSN that are going to be retried, or no commands at all? If not, could you please give an example otherwise? > - OTOH, the above flexibility wasn't deemed critical > to mandate multi-connection sessions for the first time > in the spec - hence the SHOULD. > Please see above. > - When the original text was written, the idea is that a > "connection reinstatement" is a _successful_ act of > replacing a connection with a new one where the new one > inherits all the open tasks. So, I'm at a loss to > follow what you mean by "doing connection reinstatement > after SecurityNegotiation stage" - reinstatement can't > be "done" without a successful FFP connection. I see > no reason to change the original notion. > By "doing connection reinstatement after SecurityNegotiation stage", I mean checking for a active CID matching the implict logout request's CID, and shutting down the CID active from the target's prespective (CSM-C) at this point. The advantage is that when CSM-C is shutdown upon completion of SecurityNegotiation or upon reciept of a Login Request containing CSM=1 and NSG=[1,3], yet before MaxConnections is checked, MaxConnections can be enforced. This opposed to performing the shutdown of the active CID before sending the last Login Request before moving to FFP, and hence exceeding MaxConnections in order to allow the implict logout to continue. I give the 'reinstatement failed' state previously mentioned as reasoning for the former case. That logic dictates CSM-C must be failed when CSM-I makes it past the point of SecurityNegotition, but not necessarily into FFP. I believe this state shows why it is correct to shutdown CSM-C after completion of SecurityNegotiation and any MaxConnections check. Additionaly, when this implementation method is referenced with the above noted SHOULD and MUST from section 5.3.4 it makes both not apply, or at least not in the context of Connection Reinstatement. Of course that is an implementation specific issue. :-) > The net is that I do not see an interoperability problem, > nor anything that needs changing in the spec. The ErrorRecoveryMan has spoken. :-) Thanks! -- Nicholas A. Bellinger > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Jan 19 03:51:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06815 for ; Mon, 19 Jan 2004 03:51:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiV7K-0003Fi-VY for ips-archive@odin.ietf.org; Mon, 19 Jan 2004 03:50:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0J8ogVW012503 for ips-archive@odin.ietf.org; Mon, 19 Jan 2004 03:50:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiV7K-0003Fa-Hg for ips-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 03:50:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06798 for ; Mon, 19 Jan 2004 03:50:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiV7I-00043R-00 for ips-web-archive@ietf.org; Mon, 19 Jan 2004 03:50:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiV6O-0003yU-00 for ips-web-archive@ietf.org; Mon, 19 Jan 2004 03:49:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiV5o-0003uT-00 for ips-web-archive@ietf.org; Mon, 19 Jan 2004 03:49:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiV5i-0002yR-Qq; Mon, 19 Jan 2004 03:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiV5D-0002xM-5c for ips@optimus.ietf.org; Mon, 19 Jan 2004 03:48:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06705 for ; Mon, 19 Jan 2004 03:48:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiV5A-0003tZ-00 for ips@ietf.org; Mon, 19 Jan 2004 03:48:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiV4G-0003qS-00 for ips@ietf.org; Mon, 19 Jan 2004 03:47:33 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1AiV3P-0003lB-00; Mon, 19 Jan 2004 03:46:40 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0J8kAHI065366; Mon, 19 Jan 2004 08:46:10 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0J8k9mx237944; Mon, 19 Jan 2004 09:46:09 +0100 In-Reply-To: <20040116054734.73481.qmail@web42006.mail.yahoo.com> To: Alberto Alesina Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI connections X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Mon, 19 Jan 2004 00:46:06 -0800 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 19/01/2004 10:46:09, Serialize complete at 19/01/2004 10:46:09 Content-Type: multipart/alternative; boundary="=_alternative 00512CEEC2256E1F_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 00512CEEC2256E1F_= Content-Type: text/plain; charset="US-ASCII" Alberto, The answer to both your questions is negative. Julo Alberto Alesina Sent by: ips-admin@ietf.org 16/01/2004 07:47 To ips@ietf.org cc Subject [Ips] iSCSI connections hello all, Can it be possible that two different iSCSI sessions between an initiator and a target use the same TCP connection (i.e. use the same TCP socket because the TCP session endpoint identifiers are same)? The assumption is that the target has nodes with multiple target portal groups but just one network portal (IP address and TCP port number). Also, can it be possible to have two logical iSCSI connections for a single iSCSI session and they use the same underlying TCP connection (same socket)? Thanks a lot for your time. Alberto Alesina Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --=_alternative 00512CEEC2256E1F_= Content-Type: text/html; charset="US-ASCII"
Alberto,

The answer to both your questions is negative.

Julo


Alberto Alesina <aalesina@yahoo.com>
Sent by: ips-admin@ietf.org

16/01/2004 07:47

To
ips@ietf.org
cc
Subject
[Ips] iSCSI connections





hello all,
 
Can it be possible that two different iSCSI sessions between an initiator and a target use the same TCP connection (i.e. use the same TCP socket because the TCP session endpoint identifiers are same)? The assumption is that the target has nodes with multiple target portal groups but just one network portal (IP address and TCP port number).
 
Also, can it be possible to have two logical iSCSI connections for a single iSCSI session and they use the same underlying TCP connection (same socket)?
 
 
Thanks a lot for your time.
 
Alberto Alesina

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

--=_alternative 00512CEEC2256E1F_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Jan 19 03:51:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06831 for ; Mon, 19 Jan 2004 03:51:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiV7L-0003Fx-Fq for ips-archive@odin.ietf.org; Mon, 19 Jan 2004 03:50:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0J8ohAq012513 for ips-archive@odin.ietf.org; Mon, 19 Jan 2004 03:50:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiV7L-0003Fj-A2 for ips-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 03:50:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06801 for ; Mon, 19 Jan 2004 03:50:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiV7I-00043W-00 for ips-web-archive@ietf.org; Mon, 19 Jan 2004 03:50:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiV6P-0003yc-00 for ips-web-archive@ietf.org; Mon, 19 Jan 2004 03:49:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiV5o-0003uU-00 for ips-web-archive@ietf.org; Mon, 19 Jan 2004 03:49:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiV5h-0002yH-SU; Mon, 19 Jan 2004 03:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiV57-0002xG-HZ for ips@optimus.ietf.org; Mon, 19 Jan 2004 03:48:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06684 for ; Mon, 19 Jan 2004 03:48:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiV55-0003sl-00 for ips@ietf.org; Mon, 19 Jan 2004 03:48:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiV47-0003pG-00 for ips@ietf.org; Mon, 19 Jan 2004 03:47:25 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1AiV3D-0003l8-00 for ips@ietf.org; Mon, 19 Jan 2004 03:46:27 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0J8jvpS029580; Mon, 19 Jan 2004 08:45:57 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0J8jsJZ279148; Mon, 19 Jan 2004 09:45:56 +0100 In-Reply-To: <40087647.3090600@rose.hp.com> To: "Mallikarjun C." Cc: ips@ietf.org, "Robert D. Russell" MIME-Version: 1.0 Subject: Re: [Ips] ABORT of immediate commands X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Mon, 19 Jan 2004 00:45:53 -0800 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 19/01/2004 10:45:57, Serialize complete at 19/01/2004 10:45:57 Content-Type: multipart/alternative; boundary="=_alternative 004C8E92C2256E1F_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 004C8E92C2256E1F_= Content-Type: text/plain; charset="US-ASCII" Bob, Sorry for not being able to answer earlier. Strange how memory works. I recall a long discussion with Mallikarjun over this exact matter at a lunch table in a London restaurant. We concluded that for an immediate command we should be silent (i.e., the standard text should not say anything explicit abut it). Immediate commands have an "aura of uncertainty". The target has no way of distinguishing if the initiator issued an immediate command with ITT=t and the command was lost or the the command was executed already or the command is still in flight (recall that immediate commands are not creating holes). The initiator may eliminate the ambiguity (in flight or not) by issuing at least one non-immediate command between the immediate command and it's abort. The target may answer with "function complete" only if it can unambiguously determine that the task with ITT=t was issued (if at all) prior to the abort (this was the reason for RefCmdSN=CmdSN). Otherwise it should answer with "task does not exist". I think that the text covers both cases but we may want to add the "unambiguous case" to 6.9 explicitly. Regards, Julo "Mallikarjun C." 17/01/2004 01:39 To "Robert D. Russell" cc Julian Satran/Haifa/IBM@IBMIL, ips@ietf.org Subject Re: [Ips] ABORT of immediate commands My recollection is that "Function Complete" was meant to be returned for all "valid" abort requests - "valid" being within the CmdSN window. Clarifying so would also be consistent with the last para in section 6.9. IIRC, the special casing for immediate commands (RefCmdSN=CmdSN) was introduced a little later in iSCSI's design thus leaving the original text incomplete. My suggestion would be to provide two clarifications - a) Add "(or Referenced Task Tag in the case of immediate commands)" to last para in 6.9 so it becomes: "If the abort request is received and the original command is missing, targets MUST consider the original command with that RefCmdSN (or Referenced Task Tag in the case of immediate commands) to be received and issue a Task Management response with the response code: "Function Complete". This response concludes the task on both ends." b) Add "or equal to" to the 10.6.1 bullet (b) so it in part becomes: "....is within the valid CmdSN window and less than or equal to the CmdSN of the Task Management function request itself,...." -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Robert D. Russell wrote: > Julian: > > I have a question about what Response code a target should send > in the following situation. > > 1. An initiator sends an immediate command, with I=1, ITT=t, > and CmdSN = x. > > 2. At some later time, the initiator decides to abort that task, > so it sends a task management function request with I=1, ITT=u, > RTT=t, CmdSN = y and RefCmdSN = y (CmdSN = y = RefCmdSN in > order to refer to an immediate command as required by 10.5.5), > and y is within the valid CmdSN window. > > 3. The target receives the task management function request to abort > RTT = t, but it cannot find this task (either because it > never received it or because it already finished it or whatever...) > The 3 cases listed in 10.6.1 for the ABORT TASK function do not > seem to apply in this case, because: > a) the RTT does not identify a valid task > b) the RefCmdSN is not less than the CmdSN in the TM request > c) the RefCmdSN is not outside the valid CmdSN > > Since none of these 3 cases apply, should the target respond with > "Function complete", by analogy with point b), or with > "Task does not exist", by analogy with point c)? > > My preference would be point b), "Function Complete", but clearly > it could go either way. > > In either case, perhaps a clarification is needed as a separate point for > aborting tasks (essentially corresponding with the separate point described > in 10.5.5 to deal with tasks created by immediate commands): > > d) If the Referenced Task Tag does not identify an existing > task but if the CmdSN indicated by the RefCmdSN field in the > Task Management function request equals the CmdSN field in the > Task Management function request, then targets must return the > "xxxx" response. > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 004C8E92C2256E1F_= Content-Type: text/html; charset="US-ASCII"
Bob,

Sorry for not being able to answer earlier.
Strange how memory works. I recall a long discussion with Mallikarjun over this exact matter at a lunch table in a London restaurant.
We concluded that for an immediate command we should be silent (i.e., the standard text should not say anything explicit abut it).
Immediate commands have an "aura of uncertainty".
The target has no way of distinguishing if the initiator issued an immediate command with ITT=t and the command was lost or the the command was executed already or the command is still in flight (recall that immediate commands are not creating holes).

The initiator may eliminate the ambiguity (in flight or not) by issuing at least one non-immediate command between the immediate command and it's abort.

The target may answer with "function complete" only if it can unambiguously determine that the task with ITT=t was issued (if at all) prior to the abort (this was the reason for RefCmdSN=CmdSN).

Otherwise it should answer with "task does not exist".

I think that the text covers both cases but we may want to add the "unambiguous case" to 6.9 explicitly.

Regards,
Julo

 


"Mallikarjun C." <cbm@rose.hp.com>

17/01/2004 01:39

To
"Robert D. Russell" <rdr@io.iol.unh.edu>
cc
Julian Satran/Haifa/IBM@IBMIL, ips@ietf.org
Subject
Re: [Ips] ABORT of immediate commands





My recollection is that "Function Complete" was
meant to be returned for all "valid" abort requests
- "valid" being within the CmdSN window.  Clarifying
so would also be consistent with the last para in
section 6.9.  IIRC, the special casing for immediate commands
(RefCmdSN=CmdSN) was introduced a little later in
iSCSI's design thus leaving the original text incomplete.

My suggestion would be to provide two clarifications -

a) Add "(or Referenced Task Tag in the case of immediate
   commands)" to last para in 6.9 so it becomes:

"If the abort request is received and the original command is
missing, targets MUST consider the original command with that
RefCmdSN (or Referenced Task Tag in the case of immediate
commands) to be received and issue a Task Management response
with the response code: "Function Complete".  This response
concludes the task on both ends."

b) Add "or equal to" to the 10.6.1 bullet (b) so it in
   part becomes:

"....is within the valid CmdSN window and less than or
equal to the CmdSN of the Task Management function
request itself,...."
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com



Robert D. Russell wrote:
> Julian:
>
> I have a question about what Response code a target should send
> in the following situation.
>
> 1. An initiator sends an immediate command, with I=1, ITT=t,
>    and CmdSN = x.
>
> 2. At some later time, the initiator decides to abort that task,
>    so it sends a task management function request with I=1, ITT=u,
>    RTT=t, CmdSN = y and RefCmdSN = y (CmdSN = y = RefCmdSN in
>    order to refer to an immediate command as required by 10.5.5),
>    and y is within the valid CmdSN window.
>
> 3. The target receives the task management function request to abort
>    RTT = t, but it cannot find this task (either because it
>    never received it or because it already finished it or whatever...)
>    The 3 cases listed in 10.6.1 for the ABORT TASK function do not
>    seem to apply in this case, because:
>       a) the RTT does not identify a valid task
>       b) the RefCmdSN is not less than the CmdSN in the TM request
>       c) the RefCmdSN is not outside the valid CmdSN
>
> Since none of these 3 cases apply, should the target respond with
> "Function complete", by analogy with point b), or with
> "Task does not exist", by analogy with point c)?
>
> My preference would be point b), "Function Complete", but clearly
> it could go either way.
>
> In either case, perhaps a clarification is needed as a separate point for
> aborting tasks (essentially corresponding with the separate point described
> in 10.5.5 to deal with tasks created by immediate commands):
>
>    d) If the Referenced Task Tag does not identify an existing
>    task but if the CmdSN indicated by the RefCmdSN field in the
>    Task Management function request equals the CmdSN field in the
>    Task Management function request, then targets must return the
>    "xxxx" response.
>
> Thanks,
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 004C8E92C2256E1F_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 20 11:25:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09593 for ; Tue, 20 Jan 2004 11:25:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiygK-0006I8-Dm for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 11:24:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KGOmVa024178 for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 11:24:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiygK-0006Ht-5x for ips-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:24:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09557 for ; Tue, 20 Jan 2004 11:24:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiygJ-00033U-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 11:24:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiyfS-0002xP-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 11:23:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aiyek-0002r2-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 11:23:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiyeb-00066A-Bo; Tue, 20 Jan 2004 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiye6-00064y-0a for ips@optimus.ietf.org; Tue, 20 Jan 2004 11:22:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09393 for ; Tue, 20 Jan 2004 11:22:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiye4-0002nt-00 for ips@ietf.org; Tue, 20 Jan 2004 11:22:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiydA-0002kF-00 for ips@ietf.org; Tue, 20 Jan 2004 11:21:33 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AiycV-0002h4-00 for ips@ietf.org; Tue, 20 Jan 2004 11:20:52 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1Aiyaz-0000vq-00; Tue, 20 Jan 2004 16:19:17 +0000 From: "Ken Sandars" To: "'Mallikarjun C.'" , Subject: RE: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue Date: Tue, 20 Jan 2004 16:19:58 -0000 Message-ID: <000f01c3df71$54b655c0$7107a8c0@winminx> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <40088773.8030105@rose.hp.com> Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mallikarjun, I'm seeking a clarification on the effects of connection reinstatement at ERL 2 via CSM-I: > > - When the original text was written, the idea is that a > "connection reinstatement" is a _successful_ act of > replacing a connection with a new one where the new one > inherits all the open tasks. Do the open tasks on the CSM-C connection go into the non-allegiant state, or do they get treated as though each received an implicit TMF-"task reassign" to the new connection? Thanks, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 20 13:22:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15105 for ; Tue, 20 Jan 2004 13:22:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj0WG-0006cT-0R for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 13:22:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KIMVDd025441 for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 13:22:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj0WF-0006cG-Qu for ips-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 13:22:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15092 for ; Tue, 20 Jan 2004 13:22:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj0WD-00026f-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 13:22:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj0VH-00024e-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 13:21:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj0Ux-00022U-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 13:21:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj0Up-0006SA-W8; Tue, 20 Jan 2004 13:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj0UI-0006RD-Fo for ips@optimus.ietf.org; Tue, 20 Jan 2004 13:20:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15031 for ; Tue, 20 Jan 2004 13:20:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj0UG-00021T-00 for ips@ietf.org; Tue, 20 Jan 2004 13:20:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj0TL-0001zo-00 for ips@ietf.org; Tue, 20 Jan 2004 13:19:32 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1Aj0TD-0001xj-00 for ips@ietf.org; Tue, 20 Jan 2004 13:19:23 -0500 Received: from rosemail.rose.hp.com (postal.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id 40BED1C03550; Tue, 20 Jan 2004 10:19:14 -0800 (PST) Received: from rose.hp.com (pal2nai168045.nsr.hp.com [15.244.168.45]) by rosemail.rose.hp.com (Postfix) with ESMTP id 5F9E38005; Tue, 20 Jan 2004 10:15:23 -0800 (PST) Message-ID: <400D7102.80404@rose.hp.com> Date: Tue, 20 Jan 2004 10:18:42 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Sandars Cc: ips@ietf.org Subject: Re: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue References: <000f01c3df71$54b655c0$7107a8c0@winminx> In-Reply-To: <000f01c3df71$54b655c0$7107a8c0@winminx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ken, Thank you for pointing out a mis-statement, I meant the inheritance of the CID, not the open tasks. The open tasks can only be reassigned via explicit task reassigns (or be allowed to time out). BTW, this is also true for the explicit logout (CSM-E). Thanks. Mallikarjun Ken Sandars wrote: > Hi Mallikarjun, > > I'm seeking a clarification on the effects of connection > reinstatement at ERL 2 via CSM-I: > > >>- When the original text was written, the idea is that a >> "connection reinstatement" is a _successful_ act of >> replacing a connection with a new one where the new one >> inherits all the open tasks. > > > > Do the open tasks on the CSM-C connection go into the > non-allegiant state, or do they get treated as though each > received an implicit TMF-"task reassign" to the new connection? > > > Thanks, > Ken Sandars > Elipsan UK > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Jan 20 14:24:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16817 for ; Tue, 20 Jan 2004 14:24:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj1TK-0002Dh-Ml for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 14:23:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KJNY0V008530 for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 14:23:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj1TK-0002DL-F9 for ips-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 14:23:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16812 for ; Tue, 20 Jan 2004 14:23:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj1TH-0004Yx-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 14:23:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj1SP-0004Wf-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 14:22:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj1Rt-0004U3-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 14:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj1Rp-0001zr-J0; Tue, 20 Jan 2004 14:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj1RN-0001z7-Se for ips@optimus.ietf.org; Tue, 20 Jan 2004 14:21:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16736 for ; Tue, 20 Jan 2004 14:21:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj1RL-0004S1-00 for ips@ietf.org; Tue, 20 Jan 2004 14:21:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj1QL-0004Or-00 for ips@ietf.org; Tue, 20 Jan 2004 14:20:30 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 1Aj1PV-0004Li-00 for ips@ietf.org; Tue, 20 Jan 2004 14:19:37 -0500 Received: from rosemail.rose.hp.com (postal.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id 66FF61C01E94; Tue, 20 Jan 2004 11:19:37 -0800 (PST) Received: from rose.hp.com (pal2nai168045.nsr.hp.com [15.244.168.45]) by rosemail.rose.hp.com (Postfix) with ESMTP id 8265A8005; Tue, 20 Jan 2004 11:15:44 -0800 (PST) Message-ID: <400D7F3C.3070404@rose.hp.com> Date: Tue, 20 Jan 2004 11:19:24 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Satran Cc: ips@ietf.org, "Robert D. Russell" Subject: Re: [Ips] ABORT of immediate commands References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Julian, You may be correct in your recollection of our conversation. Let me state my current reasoning for the response I had below. As you say, immediate commands have an aura of uncertainty. So unless the target has a record with an ordered list of all the ITTs of the tasks it had executed, it cannot be certain about having ever received a RefTT (assuming the target doesn't currently have it executing). But then again, having the RefTT in its record is not a guarantee that the initiator is wanting to abort the same instance of that RefTT (RefTT could've been reused). It therefore seemed to me that the target would almost be forced to respond with a "task does not exist" if the task isn't currently executing, eventhough the odds of losing the immediate command (digest failures) are considerably small. Since this target behavior is different from that exhibited for non-immediate commands (for which "function complete" responses are the most likely), I suggested what I did. But perhaps the inherent ambiguity wrt immediate commands is reason enough to require a different behavior, I guess I personally don't see it that way. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Julian Satran wrote: > > Bob, > > Sorry for not being able to answer earlier. > Strange how memory works. I recall a long discussion with Mallikarjun > over this exact matter at a lunch table in a London restaurant. > We concluded that for an immediate command we should be silent (i.e., > the standard text should not say anything explicit abut it). > Immediate commands have an "aura of uncertainty". > The target has no way of distinguishing if the initiator issued an > immediate command with ITT=t and the command was lost or the the command > was executed already or the command is still in flight (recall that > immediate commands are not creating holes). > > The initiator may eliminate the ambiguity (in flight or not) by issuing > at least one non-immediate command between the immediate command and > it's abort. > > The target may answer with "function complete" only if it can > unambiguously determine that the task with ITT=t was issued (if at all) > prior to the abort (this was the reason for RefCmdSN=CmdSN). > > Otherwise it should answer with "task does not exist". > > I think that the text covers both cases but we may want to add the > "unambiguous case" to 6.9 explicitly. > > Regards, > Julo > > > > > "Mallikarjun C." > > 17/01/2004 01:39 > > > To > "Robert D. Russell" > cc > Julian Satran/Haifa/IBM@IBMIL, ips@ietf.org > Subject > Re: [Ips] ABORT of immediate commands > > > > > > > > > My recollection is that "Function Complete" was > meant to be returned for all "valid" abort requests > - "valid" being within the CmdSN window. Clarifying > so would also be consistent with the last para in > section 6.9. IIRC, the special casing for immediate commands > (RefCmdSN=CmdSN) was introduced a little later in > iSCSI's design thus leaving the original text incomplete. > > My suggestion would be to provide two clarifications - > > a) Add "(or Referenced Task Tag in the case of immediate > commands)" to last para in 6.9 so it becomes: > > "If the abort request is received and the original command is > missing, targets MUST consider the original command with that > RefCmdSN (or Referenced Task Tag in the case of immediate > commands) to be received and issue a Task Management response > with the response code: "Function Complete". This response > concludes the task on both ends." > > b) Add "or equal to" to the 10.6.1 bullet (b) so it in > part becomes: > > "....is within the valid CmdSN window and less than or > equal to the CmdSN of the Task Management function > request itself,...." > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > > Robert D. Russell wrote: > > Julian: > > > > I have a question about what Response code a target should send > > in the following situation. > > > > 1. An initiator sends an immediate command, with I=1, ITT=t, > > and CmdSN = x. > > > > 2. At some later time, the initiator decides to abort that task, > > so it sends a task management function request with I=1, ITT=u, > > RTT=t, CmdSN = y and RefCmdSN = y (CmdSN = y = RefCmdSN in > > order to refer to an immediate command as required by 10.5.5), > > and y is within the valid CmdSN window. > > > > 3. The target receives the task management function request to abort > > RTT = t, but it cannot find this task (either because it > > never received it or because it already finished it or whatever...) > > The 3 cases listed in 10.6.1 for the ABORT TASK function do not > > seem to apply in this case, because: > > a) the RTT does not identify a valid task > > b) the RefCmdSN is not less than the CmdSN in the TM request > > c) the RefCmdSN is not outside the valid CmdSN > > > > Since none of these 3 cases apply, should the target respond with > > "Function complete", by analogy with point b), or with > > "Task does not exist", by analogy with point c)? > > > > My preference would be point b), "Function Complete", but clearly > > it could go either way. > > > > In either case, perhaps a clarification is needed as a separate point for > > aborting tasks (essentially corresponding with the separate point > described > > in 10.5.5 to deal with tasks created by immediate commands): > > > > d) If the Referenced Task Tag does not identify an existing > > task but if the CmdSN indicated by the RefCmdSN field in the > > Task Management function request equals the CmdSN field in the > > Task Management function request, then targets must return the > > "xxxx" response. > > > > Thanks, > > > > Bob Russell > > InterOperability Lab > > University of New Hampshire > > rdr@iol.unh.edu > > 603-862-3774 > > > > _______________________________________________ > > 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 exim@www1.ietf.org Tue Jan 20 19:59:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04704 for ; Tue, 20 Jan 2004 19:59:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj6ho-0004Eg-5i for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 19:58:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L0wqfn016282 for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 19:58:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj6hn-0004EW-Ua for ips-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 19:58:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04701 for ; Tue, 20 Jan 2004 19:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj6hm-0003DA-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 19:58:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj6h1-00039q-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 19:58:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj6g3-00037N-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 19:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj6g1-0003zm-Do; Tue, 20 Jan 2004 19:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj6fn-0003wq-Dy for ips@optimus.ietf.org; Tue, 20 Jan 2004 19:56:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04598 for ; Tue, 20 Jan 2004 19:56:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj6fl-00035x-00 for ips@ietf.org; Tue, 20 Jan 2004 19:56:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj6eq-000317-00 for ips@ietf.org; Tue, 20 Jan 2004 19:55:49 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1Aj6e2-0002qE-00 for ips@ietf.org; Tue, 20 Jan 2004 19:54:58 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0L0sPJW118698; Wed, 21 Jan 2004 00:54:25 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0L0sNI2159660; Wed, 21 Jan 2004 01:54:25 +0100 In-Reply-To: <000f01c3df71$54b655c0$7107a8c0@winminx> To: "Ken Sandars" Cc: "'Mallikarjun C.'" , ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: RE: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 20 Jan 2004 16:54:22 -0800 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 21/01/2004 02:54:24, Serialize complete at 21/01/2004 02:54:24 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Reassignment has to be explict - Julo "Ken Sandars" Sent by: ips-admin@ietf.org 20/01/2004 08:19 To "'Mallikarjun C.'" , cc Subject RE: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue Hi Mallikarjun, I'm seeking a clarification on the effects of connection reinstatement at ERL 2 via CSM-I: > > - When the original text was written, the idea is that a > "connection reinstatement" is a _successful_ act of > replacing a connection with a new one where the new one > inherits all the open tasks. Do the open tasks on the CSM-C connection go into the non-allegiant state, or do they get treated as though each received an implicit TMF-"task reassign" to the new connection? Thanks, Ken Sandars Elipsan UK _______________________________________________ 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 exim@www1.ietf.org Tue Jan 20 22:27:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08337 for ; Tue, 20 Jan 2004 22:27:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj914-000446-RG for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 22:26:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L3QsQF015620 for ips-archive@odin.ietf.org; Tue, 20 Jan 2004 22:26:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj914-00043R-LY for ips-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 22:26:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08322 for ; Tue, 20 Jan 2004 22:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj911-00027e-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 22:26:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj909-00024d-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 22:25:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj8zJ-00021W-00 for ips-web-archive@ietf.org; Tue, 20 Jan 2004 22:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj8zH-0003lE-Ju; Tue, 20 Jan 2004 22:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj8z3-0003jL-GV for ips@optimus.ietf.org; Tue, 20 Jan 2004 22:24:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08270 for ; Tue, 20 Jan 2004 22:24:45 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj8z0-0001zu-00 for ips@ietf.org; Tue, 20 Jan 2004 22:24:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj8y4-0001xh-00 for ips@ietf.org; Tue, 20 Jan 2004 22:23:49 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Aj8xJ-0001tu-00 for ips@ietf.org; Tue, 20 Jan 2004 22:23:01 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 7B99740134; Tue, 20 Jan 2004 22:22:56 -0500 (EST) Date: Tue, 20 Jan 2004 19:18:38 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Mallikarjun C." Cc: Julian Satran , ips@ietf.org, "Robert D. Russell" Subject: Re: [Ips] ABORT of immediate commands In-Reply-To: <400D7F3C.3070404@rose.hp.com> Message-ID: References: <400D7F3C.3070404@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 20 Jan 2004, Mallikarjun C. wrote: > As you say, immediate commands have an aura of > uncertainty. So unless the target has a record > with an ordered list of all the ITTs of the tasks > it had executed, it cannot be certain about having > ever received a RefTT (assuming the target doesn't > currently have it executing). But then again, > having the RefTT in its record is not a guarantee > that the initiator is wanting to abort the same > instance of that RefTT (RefTT could've been reused). > > It therefore seemed to me that the target would > almost be forced to respond with a "task does not > exist" if the task isn't currently executing, eventhough > the odds of losing the immediate command (digest > failures) are considerably small. > > Since this target behavior is different from that > exhibited for non-immediate commands (for which "function > complete" responses are the most likely), I suggested > what I did. But perhaps the inherent ambiguity wrt > immediate commands is reason enough to require a > different behavior, I guess I personally don't see > it that way. I realize I'm chiming in much after the initial discussions, but I'd like to vote for a difference in behavior, based on the difference in underlying command behavior between immediate and non-immediate commands. For an unreceived non-immediate command, "Function complete" makes sense as we can remember the task has been aborted even though we haven't received it yet. Either way, it's aborted. :-) Immediate commands, though, as you note, can't really do that. So I think just returning "Task does not exist" seems best. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 21 01:14:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11864 for ; Wed, 21 Jan 2004 01:14:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBcc-0003pk-Hc for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 01:13:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L6DoSk014730 for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 01:13:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBcc-0003pV-CZ for ips-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 01:13:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11859 for ; Wed, 21 Jan 2004 01:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjBcZ-0000w6-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 01:13:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjBbc-0000uv-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 01:12:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjBau-0000tc-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 01:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBar-0003js-FK; Wed, 21 Jan 2004 01:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBaf-0003jZ-Kj for ips@optimus.ietf.org; Wed, 21 Jan 2004 01:11:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11839 for ; Wed, 21 Jan 2004 01:11:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjBac-0000sz-00 for ips@ietf.org; Wed, 21 Jan 2004 01:11:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjBZe-0000rR-00 for ips@ietf.org; Wed, 21 Jan 2004 01:10:47 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1AjBYi-0000p0-00 for ips@ietf.org; Wed, 21 Jan 2004 01:09:48 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0L69IHI051968; Wed, 21 Jan 2004 06:09:18 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0L69GZe266530; Wed, 21 Jan 2004 07:09:17 +0100 In-Reply-To: <400D7F3C.3070404@rose.hp.com> To: "Mallikarjun C." Cc: ips@ietf.org, "Robert D. Russell" MIME-Version: 1.0 Subject: Re: [Ips] ABORT of immediate commands X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 20 Jan 2004 22:09:11 -0800 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 21/01/2004 08:09:16, Serialize complete at 21/01/2004 08:09:16 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Mallikarjun, Our conclusion at the time was that the target should answer based on what it has. If it doesn't have the task it should respond that it doesn't have it. If the initiator wants more guarantees it should not send immediate commands that may need aborting. I don't see anything to justify revisiting this item. Regards, Julo "Mallikarjun C." 20/01/2004 11:19 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org, "Robert D. Russell" Subject Re: [Ips] ABORT of immediate commands Julian, You may be correct in your recollection of our conversation. Let me state my current reasoning for the response I had below. As you say, immediate commands have an aura of uncertainty. So unless the target has a record with an ordered list of all the ITTs of the tasks it had executed, it cannot be certain about having ever received a RefTT (assuming the target doesn't currently have it executing). But then again, having the RefTT in its record is not a guarantee that the initiator is wanting to abort the same instance of that RefTT (RefTT could've been reused). It therefore seemed to me that the target would almost be forced to respond with a "task does not exist" if the task isn't currently executing, eventhough the odds of losing the immediate command (digest failures) are considerably small. Since this target behavior is different from that exhibited for non-immediate commands (for which "function complete" responses are the most likely), I suggested what I did. But perhaps the inherent ambiguity wrt immediate commands is reason enough to require a different behavior, I guess I personally don't see it that way. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Julian Satran wrote: > > Bob, > > Sorry for not being able to answer earlier. > Strange how memory works. I recall a long discussion with Mallikarjun > over this exact matter at a lunch table in a London restaurant. > We concluded that for an immediate command we should be silent (i.e., > the standard text should not say anything explicit abut it). > Immediate commands have an "aura of uncertainty". > The target has no way of distinguishing if the initiator issued an > immediate command with ITT=t and the command was lost or the the command > was executed already or the command is still in flight (recall that > immediate commands are not creating holes). > > The initiator may eliminate the ambiguity (in flight or not) by issuing > at least one non-immediate command between the immediate command and > it's abort. > > The target may answer with "function complete" only if it can > unambiguously determine that the task with ITT=t was issued (if at all) > prior to the abort (this was the reason for RefCmdSN=CmdSN). > > Otherwise it should answer with "task does not exist". > > I think that the text covers both cases but we may want to add the > "unambiguous case" to 6.9 explicitly. > > Regards, > Julo > > > > > "Mallikarjun C." > > 17/01/2004 01:39 > > > To > "Robert D. Russell" > cc > Julian Satran/Haifa/IBM@IBMIL, ips@ietf.org > Subject > Re: [Ips] ABORT of immediate commands > > > > > > > > > My recollection is that "Function Complete" was > meant to be returned for all "valid" abort requests > - "valid" being within the CmdSN window. Clarifying > so would also be consistent with the last para in > section 6.9. IIRC, the special casing for immediate commands > (RefCmdSN=CmdSN) was introduced a little later in > iSCSI's design thus leaving the original text incomplete. > > My suggestion would be to provide two clarifications - > > a) Add "(or Referenced Task Tag in the case of immediate > commands)" to last para in 6.9 so it becomes: > > "If the abort request is received and the original command is > missing, targets MUST consider the original command with that > RefCmdSN (or Referenced Task Tag in the case of immediate > commands) to be received and issue a Task Management response > with the response code: "Function Complete". This response > concludes the task on both ends." > > b) Add "or equal to" to the 10.6.1 bullet (b) so it in > part becomes: > > "....is within the valid CmdSN window and less than or > equal to the CmdSN of the Task Management function > request itself,...." > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > > Robert D. Russell wrote: > > Julian: > > > > I have a question about what Response code a target should send > > in the following situation. > > > > 1. An initiator sends an immediate command, with I=1, ITT=t, > > and CmdSN = x. > > > > 2. At some later time, the initiator decides to abort that task, > > so it sends a task management function request with I=1, ITT=u, > > RTT=t, CmdSN = y and RefCmdSN = y (CmdSN = y = RefCmdSN in > > order to refer to an immediate command as required by 10.5.5), > > and y is within the valid CmdSN window. > > > > 3. The target receives the task management function request to abort > > RTT = t, but it cannot find this task (either because it > > never received it or because it already finished it or whatever...) > > The 3 cases listed in 10.6.1 for the ABORT TASK function do not > > seem to apply in this case, because: > > a) the RTT does not identify a valid task > > b) the RefCmdSN is not less than the CmdSN in the TM request > > c) the RefCmdSN is not outside the valid CmdSN > > > > Since none of these 3 cases apply, should the target respond with > > "Function complete", by analogy with point b), or with > > "Task does not exist", by analogy with point c)? > > > > My preference would be point b), "Function Complete", but clearly > > it could go either way. > > > > In either case, perhaps a clarification is needed as a separate point for > > aborting tasks (essentially corresponding with the separate point > described > > in 10.5.5 to deal with tasks created by immediate commands): > > > > d) If the Referenced Task Tag does not identify an existing > > task but if the CmdSN indicated by the RefCmdSN field in the > > Task Management function request equals the CmdSN field in the > > Task Management function request, then targets must return the > > "xxxx" response. > > > > Thanks, > > > > Bob Russell > > InterOperability Lab > > University of New Hampshire > > rdr@iol.unh.edu > > 603-862-3774 > > > > _______________________________________________ > > 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 exim@www1.ietf.org Wed Jan 21 14:29:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04359 for ; Wed, 21 Jan 2004 14:29:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO2S-0005eh-9Q for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 14:29:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LJTKMJ021735 for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 14:29:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO2R-0005eT-V9 for ips-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 14:29:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04355 for ; Wed, 21 Jan 2004 14:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjO2P-0005V3-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 14:29:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjO1S-0005TT-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 14:28:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjO1I-0005Rk-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 14:28:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO1B-0005XM-9x; Wed, 21 Jan 2004 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO0S-0005SU-RE for ips@optimus.ietf.org; Wed, 21 Jan 2004 14:27:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04309 for ; Wed, 21 Jan 2004 14:27:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjO0Q-0005R9-00 for ips@ietf.org; Wed, 21 Jan 2004 14:27:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjNzV-0005Pd-00 for ips@ietf.org; Wed, 21 Jan 2004 14:26:18 -0500 Received: from ns.equallogic.com ([66.155.203.134] helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1AjNzD-0005Nv-00 for ips@ietf.org; Wed, 21 Jan 2004 14:26:00 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i0LJPT6a013683 for ; Wed, 21 Jan 2004 14:25:29 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i0LJPSIg013678; Wed, 21 Jan 2004 14:25:28 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id i0LJPRB05278; Wed, 21 Jan 2004 14:25:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16398.53799.597067.275608@gargle.gargle.HOWL> Date: Wed, 21 Jan 2004 14:25:27 -0500 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: cbm@rose.hp.com, ips@ietf.org, rdr@io.iol.unh.edu Subject: Re: [Ips] ABORT of immediate commands References: <400D7F3C.3070404@rose.hp.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Julian" == Julian Satran writes: Julian> Mallikarjun, Our conclusion at the time was that the target Julian> should answer based on what it has. If it doesn't have the Julian> task it should respond that it doesn't have it. If the Julian> initiator wants more guarantees it should not send immediate Julian> commands that may need aborting. I don't see anything to Julian> justify revisiting this item. I agree with that reasoning. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 21 16:28:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09641 for ; Wed, 21 Jan 2004 16:28:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPtd-0005kx-NP for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 16:28:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LLSLbj022123 for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 16:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPtd-0005kk-JT for ips-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:28:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09609 for ; Wed, 21 Jan 2004 16:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPtb-0002Q6-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 16:28:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPsg-0002OA-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 16:27:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPsP-0002Mf-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 16:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPsL-0005Jk-Ts; Wed, 21 Jan 2004 16:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPrn-0005IE-8G for ips@optimus.ietf.org; Wed, 21 Jan 2004 16:26:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09453; Wed, 21 Jan 2004 16:26:24 -0500 (EST) Message-Id: <200401212126.QAA09453@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 21 Jan 2004 16:26:24 -0500 Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-name-ext-01.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : NAA naming format for iSCSI Node Names Author(s) : M. Krueger, M. Chadalapaka, R. Elliott Filename : draft-ietf-ips-iscsi-name-ext-01.txt Pages : 6 Date : 2004-1-21 iSCSI is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the 'Network Address Authority' (NAA) world wide naming format used by ANSI T11 Fibre Channel (FC) protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-ext-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-iscsi-name-ext-01.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-iscsi-name-ext-01.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: <2004-1-21164210.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-name-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-name-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-21164210.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 21 16:28:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09658 for ; Wed, 21 Jan 2004 16:28:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPte-0005lH-DN for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 16:28:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LLSMTG022141 for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 16:28:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPte-0005l2-9n for ips-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:28:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09613 for ; Wed, 21 Jan 2004 16:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPtc-0002QB-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 16:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPsg-0002OI-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 16:27:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPsP-0002Mg-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 16:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPsM-0005K5-Md; Wed, 21 Jan 2004 16:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPrr-0005IJ-Uf for ips@optimus.ietf.org; Wed, 21 Jan 2004 16:26:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09469; Wed, 21 Jan 2004 16:26:29 -0500 (EST) Message-Id: <200401212126.QAA09469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 21 Jan 2004 16:26:28 -0500 Subject: [Ips] I-D ACTION:draft-ietf-ips-command-ordering-02.txt,.pdf Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : SCSI Command Ordering Considerations with iSCSI Author(s) : M. Chadalapaka, R. Elliott Filename : draft-ietf-ips-command-ordering-02.txt,.pdf Pages : 20 Date : 2004-1-21 iSCSI is a SCSI transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the SCSI I_T nexus, and the iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-command-ordering-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-command-ordering-02.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-command-ordering-02.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: <2004-1-21164223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-command-ordering-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-command-ordering-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-21164223.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 21 21:00:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21417 for ; Wed, 21 Jan 2004 21:00:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjU90-0008VZ-Oo for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 21:00:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M20UJu032705 for ips-archive@odin.ietf.org; Wed, 21 Jan 2004 21:00:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjU90-0008VQ-J5 for ips-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 21:00:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21408 for ; Wed, 21 Jan 2004 21:00:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjU8y-0000XS-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 21:00:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjU85-0000Vf-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 20:59:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjU7f-0000Ta-00 for ips-web-archive@ietf.org; Wed, 21 Jan 2004 20:59:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjU7Z-0008Ji-Oj; Wed, 21 Jan 2004 20:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjU71-0008Ij-SM for ips@optimus.ietf.org; Wed, 21 Jan 2004 20:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21336 for ; Wed, 21 Jan 2004 20:58:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjU6z-0000Rh-00 for ips@ietf.org; Wed, 21 Jan 2004 20:58:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjU69-0000Pw-00 for ips@ietf.org; Wed, 21 Jan 2004 20:57:34 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1AjU5M-0000L9-00; Wed, 21 Jan 2004 20:56:44 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0M1uDRT132288; Thu, 22 Jan 2004 01:56:13 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0M1uChp243070; Thu, 22 Jan 2004 02:56:13 +0100 In-Reply-To: To: wrstuden@wasabisystems.com Cc: "Mallikarjun C." , ips@ietf.org, ips-admin@ietf.org, "Robert D. Russell" MIME-Version: 1.0 Subject: Re: [Ips] ABORT of immediate commands X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Thu, 22 Jan 2004 03:56:10 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 22/01/2004 03:56:12, Serialize complete at 22/01/2004 03:56:12 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 That is what the spec says today. Julo wrstuden@wasabisystems.com Sent by: ips-admin@ietf.org 20/01/2004 19:18 To "Mallikarjun C." cc Julian Satran/Haifa/IBM@IBMIL, ips@ietf.org, "Robert D. Russell" Subject Re: [Ips] ABORT of immediate commands On Tue, 20 Jan 2004, Mallikarjun C. wrote: > As you say, immediate commands have an aura of > uncertainty. So unless the target has a record > with an ordered list of all the ITTs of the tasks > it had executed, it cannot be certain about having > ever received a RefTT (assuming the target doesn't > currently have it executing). But then again, > having the RefTT in its record is not a guarantee > that the initiator is wanting to abort the same > instance of that RefTT (RefTT could've been reused). > > It therefore seemed to me that the target would > almost be forced to respond with a "task does not > exist" if the task isn't currently executing, eventhough > the odds of losing the immediate command (digest > failures) are considerably small. > > Since this target behavior is different from that > exhibited for non-immediate commands (for which "function > complete" responses are the most likely), I suggested > what I did. But perhaps the inherent ambiguity wrt > immediate commands is reason enough to require a > different behavior, I guess I personally don't see > it that way. I realize I'm chiming in much after the initial discussions, but I'd like to vote for a difference in behavior, based on the difference in underlying command behavior between immediate and non-immediate commands. For an unreceived non-immediate command, "Function complete" makes sense as we can remember the task has been aborted even though we haven't received it yet. Either way, it's aborted. :-) Immediate commands, though, as you note, can't really do that. So I think just returning "Task does not exist" seems best. Take care, 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 exim@www1.ietf.org Thu Jan 22 12:41:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00811 for ; Thu, 22 Jan 2004 12:41:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjipS-0001TD-LR for ips-archive@odin.ietf.org; Thu, 22 Jan 2004 12:41:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MHfIH8005647 for ips-archive@odin.ietf.org; Thu, 22 Jan 2004 12:41:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjipS-0001T0-GK for ips-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 12:41:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00785 for ; Thu, 22 Jan 2004 12:41:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjipL-000076-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 12:41:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajilh-0007hh-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 12:37:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajihr-0007Sk-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 12:33:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjihR-0000av-Cd; Thu, 22 Jan 2004 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajigs-0000a8-GR for ips@optimus.ietf.org; Thu, 22 Jan 2004 12:32:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00458 for ; Thu, 22 Jan 2004 12:32:17 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajigg-0007Qd-00 for ips@ietf.org; Thu, 22 Jan 2004 12:32:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjidW-0007Et-00 for ips@ietf.org; Thu, 22 Jan 2004 12:28:59 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AjiZT-00071S-00 for ips@ietf.org; Thu, 22 Jan 2004 12:24:47 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 5557040135; Thu, 22 Jan 2004 12:24:22 -0500 (EST) Date: Thu, 22 Jan 2004 09:20:02 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: ips@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ips] iSNS SLP service type Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 In reviewing the iSNS draft, I noticed it indicates you can use SLP to locate the iSNS server. There was, however, no discussion of _how_ to use SLP to locate the iSNS server. At least none I saw. So how should we create SLP URLs for iSNS servers? While not terribly complicated, it's important we are consistent. Otherwise the clients won't find the server. :-) Do we want to use, "service:isns"? Or "service:isns:server", to leave room for iSNS inter-server functionality? For reference, for iSCSI, we use "service:iscsi:target". Also, the iSNS heartbeat packet can list primary and backup servers. Do we want to have an attribute with the service registration to indicate that server's position in the failover order? Otherwise SLP-using services won't necessarily know which server to talk to. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 22 12:47:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01377 for ; Thu, 22 Jan 2004 12:47:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajiv3-00024h-63 for ips-archive@odin.ietf.org; Thu, 22 Jan 2004 12:47:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MHl5gO007969 for ips-archive@odin.ietf.org; Thu, 22 Jan 2004 12:47:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajiv3-00024S-1f for ips-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 12:47:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01269 for ; Thu, 22 Jan 2004 12:47:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajiv1-0000dT-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 12:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajiu4-0000X4-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 12:46:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajit6-0000QC-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 12:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajit5-0001pH-OH; Thu, 22 Jan 2004 12:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjisN-0001iX-Le for ips@optimus.ietf.org; Thu, 22 Jan 2004 12:44:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00998 for ; Thu, 22 Jan 2004 12:44:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjisL-0000LD-00 for ips@ietf.org; Thu, 22 Jan 2004 12:44:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjiqY-0000Ag-00 for ips@ietf.org; Thu, 22 Jan 2004 12:42:26 -0500 Received: from [65.174.117.136] (helo=morpheus.corp.iready.com) by ietf-mx with esmtp (Exim 4.12) id 1Ajimg-0007iN-00 for ips@ietf.org; Thu, 22 Jan 2004 12:38:26 -0500 Received: by morpheus.corp.iready.com with Internet Mail Service (5.5.2655.55) id ; Thu, 22 Jan 2004 09:37:31 -0800 Message-ID: From: Andy Currid To: "'wrstuden@wasabisystems.com'" , ips@ietf.org Subject: RE: [Ips] iSNS SLP service type Date: Thu, 22 Jan 2004 09:37:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E10E.19784890" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 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_01C3E10E.19784890 Content-Type: text/plain; charset="iso-8859-1" I thought this was covered in the iSCSI SLP draft, which defines "service:iscsi:sms" for discovery of storage management services. The template for that service includes a protocol field which may be set to "isns" to indicate an iSNS server. Andy -- Andy Currid Phone: 408 330 4507 iReady Corporation Fax: 408 330 4521 andy@iready.com http://www.iready.com > -----Original Message----- > From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] > Sent: Thursday, January 22, 2004 09:20 > To: ips@ietf.org > Subject: [Ips] iSNS SLP service type > > > In reviewing the iSNS draft, I noticed it indicates you can use SLP to > locate the iSNS server. There was, however, no discussion of > _how_ to use > SLP to locate the iSNS server. At least none I saw. > > So how should we create SLP URLs for iSNS servers? While not terribly > complicated, it's important we are consistent. Otherwise the > clients won't > find the server. :-) > > Do we want to use, "service:isns"? Or "service:isns:server", > to leave room > for iSNS inter-server functionality? For reference, for iSCSI, we use > "service:iscsi:target". > > Also, the iSNS heartbeat packet can list primary and backup > servers. Do we > want to have an attribute with the service registration to > indicate that > server's position in the failover order? Otherwise SLP-using services > won't necessarily know which server to talk to. > > Take care, > > Bill > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > ------_=_NextPart_001_01C3E10E.19784890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ips] iSNS SLP service type

I thought this was covered in the iSCSI SLP = draft,
which defines "service:iscsi:sms" for = discovery of
storage management services. The template for = that
service includes a protocol field which may be = set
to "isns" to indicate an iSNS = server.

Andy
--
Andy = Currid           =       Phone: 408 330 4507
iReady = Corporation          &= nbsp; Fax: 408 330 4521
andy@iready.com        =    http://www.iready.com
   

> -----Original Message-----
> From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems= .com]
> Sent: Thursday, January 22, 2004 09:20
> To: ips@ietf.org
> Subject: [Ips] iSNS SLP service type
>
>
> In reviewing the iSNS draft, I noticed it = indicates you can use SLP to
> locate the iSNS server. There was, however, no = discussion of
> _how_ to use
> SLP to locate the iSNS server. At least none I = saw.
>
> So how should we create SLP URLs for iSNS = servers? While not terribly
> complicated, it's important we are consistent. = Otherwise the
> clients won't
> find the server. :-)
>
> Do we want to use, "service:isns"? Or = "service:isns:server",
> to leave room
> for iSNS inter-server functionality? For = reference, for iSCSI, we use
> "service:iscsi:target".
>
> Also, the iSNS heartbeat packet can list = primary and backup
> servers. Do we
> want to have an attribute with the service = registration to
> indicate that
> server's position in the failover order? = Otherwise SLP-using services
> won't necessarily know which server to talk = to.
>
> Take care,
>
> Bill
>
> = _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>

------_=_NextPart_001_01C3E10E.19784890-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 22 13:12:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02229 for ; Thu, 22 Jan 2004 13:12:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjJY-0004eY-UM for ips-archive@odin.ietf.org; Thu, 22 Jan 2004 13:12:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MICO8c017880 for ips-archive@odin.ietf.org; Thu, 22 Jan 2004 13:12:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjJY-0004eJ-Oz for ips-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 13:12:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02216 for ; Thu, 22 Jan 2004 13:12:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjjJR-0001hr-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 13:12:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjFv-0001Y1-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 13:08:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjjDa-0001Qh-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 13:06:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjDO-0003Ue-4A; Thu, 22 Jan 2004 13:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjCn-0003Pw-Nm for ips@optimus.ietf.org; Thu, 22 Jan 2004 13:05:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01997 for ; Thu, 22 Jan 2004 13:05:16 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjjCb-0001OB-00 for ips@ietf.org; Thu, 22 Jan 2004 13:05:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjA7-0001Hy-00 for ips@ietf.org; Thu, 22 Jan 2004 13:02:40 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Ajj7u-0001D6-00 for ips@ietf.org; Thu, 22 Jan 2004 13:00:22 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 0223340135; Thu, 22 Jan 2004 13:00:12 -0500 (EST) Date: Thu, 22 Jan 2004 09:55:52 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Andy Currid Cc: ips@ietf.org Subject: RE: [Ips] iSNS SLP service type In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Thu, 22 Jan 2004, Andy Currid wrote: > I thought this was covered in the iSCSI SLP draft, > which defines "service:iscsi:sms" for discovery of > storage management services. The template for that > service includes a protocol field which may be set > to "isns" to indicate an iSNS server. Ahhh... That's possible. To be honest, I was not really sure what the "sms" server was good for when I read the iSCSI-SLP draft; it seemed rather vague and not immediately relevant. Now that you mention it, I notice that the iSCSI-SLP draft is mentioned in the iSNS references section. However no part of the document actualy uses that references. Is it too late for iSNS draft comments? If not, I'd like to request/ comment that section 2.5.1 should mention that iSCSI-SLP offers the service template for using SLP to locate iSNS servers. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 22 13:36:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03086 for ; Thu, 22 Jan 2004 13:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjgT-0006T4-Rk for ips-archive@odin.ietf.org; Thu, 22 Jan 2004 13:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MIa5lj024862 for ips-archive@odin.ietf.org; Thu, 22 Jan 2004 13:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjgT-0006Sv-Nk for ips-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 13:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03057 for ; Thu, 22 Jan 2004 13:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjjgR-00032U-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 13:36:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjfT-0002y7-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 13:35:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajjee-0002sQ-00 for ips-web-archive@ietf.org; Thu, 22 Jan 2004 13:34:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjeT-0006Av-2K; Thu, 22 Jan 2004 13:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajjdz-00062n-C7 for ips@optimus.ietf.org; Thu, 22 Jan 2004 13:33:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02886 for ; Thu, 22 Jan 2004 13:33:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajjdn-0002qR-00 for ips@ietf.org; Thu, 22 Jan 2004 13:33:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjbU-0002jc-00 for ips@ietf.org; Thu, 22 Jan 2004 13:30:56 -0500 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1AjjYL-0002YR-00 for ips@ietf.org; Thu, 22 Jan 2004 13:27:41 -0500 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jan 2004 11:26:46 -0700 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Thu, 22 Jan 2004 11:26:45 -0700 Received: from SNEXCH01.mcdata.com ([172.19.161.12]) by MC4EXCH03.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jan 2004 11:26:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] iSNS SLP service type Date: Thu, 22 Jan 2004 10:26:32 -0800 Message-ID: <501EA67E9359C645A10C42EB5B52480DAD0F2C@SNEXCH01.mcdata.com> Thread-Topic: [Ips] iSNS SLP service type Thread-Index: AcPhEm/lRF6nhAVdT9yn9N+eQJmqyQAArNQw From: "Joshua Tseng" To: , "Andy Currid" Cc: X-OriginalArrivalTime: 22 Jan 2004 18:26:45.0185 (UTC) FILETIME=[4A31DB10:01C3E115] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for the note. The reference to the iSCSI-SLP draft will be incorporated into the next iSNS draft. Josh Tseng -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]=20 Sent: Thursday, January 22, 2004 9:56 AM To: Andy Currid Cc: ips@ietf.org Subject: RE: [Ips] iSNS SLP service type On Thu, 22 Jan 2004, Andy Currid wrote: > I thought this was covered in the iSCSI SLP draft, > which defines "service:iscsi:sms" for discovery of > storage management services. The template for that > service includes a protocol field which may be set > to "isns" to indicate an iSNS server. Ahhh... That's possible. To be honest, I was not really sure what the "sms" server was good for when I read the iSCSI-SLP draft; it seemed rather vague and not immediately relevant. Now that you mention it, I notice that the iSCSI-SLP draft is mentioned in the iSNS references section. However no part of the document actualy uses that references. Is it too late for iSNS draft comments? If not, I'd like to request/ comment that section 2.5.1 should mention that iSCSI-SLP offers the service template for using SLP to locate iSNS servers. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent=20 responsible for delivering the message to the intended recipient, you are hereby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY=20 PROHIBITED. Anyone who receives confidential and privileged information in error should= =20 notify us immediately by telephone and mail the original message to us at= the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions=20 apply to that information. (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 23 06:01:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24235 for ; Fri, 23 Jan 2004 06:01:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajz3v-00078G-Iu for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 06:01:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NB1J2X027411 for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 06:01:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajz3v-000782-E9 for ips-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 06:01:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24225 for ; Fri, 23 Jan 2004 06:01:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajz3m-0005k1-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 06:01:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajz1J-0005hM-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 05:58:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajz0m-0005fb-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 05:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajz0j-0006wa-9r; Fri, 23 Jan 2004 05:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajz0L-0006vJ-06 for ips@optimus.ietf.org; Fri, 23 Jan 2004 05:57:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24172 for ; Fri, 23 Jan 2004 05:57:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajz0H-0005eB-00 for ips@ietf.org; Fri, 23 Jan 2004 05:57:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjyzN-0005cw-00 for ips@ietf.org; Fri, 23 Jan 2004 05:56:37 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AjyyX-0005b5-00 for ips@ietf.org; Fri, 23 Jan 2004 05:55:45 -0500 Received: from [192.168.70.180] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1AjyxC-0003Ob-00 for ips@ietf.org; Fri, 23 Jan 2004 10:54:22 +0000 From: "Ken Sandars" To: Subject: [Ips] iSCSI: Retransmitting R2T pdus Date: Fri, 23 Jan 2004 10:55:07 -0000 Message-ID: <000501c3e19f$6fb68c70$b446a8c0@winminx> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi everyone, When can/should a target resend an R2T rather than use a recovery R2T? I suspect the answer is only in response to a R2T SNACK request. However section 6.8 talks about proactive retransmission of R2T's by the target, so I'm not clear on this. TIA, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 23 08:26:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29578 for ; Fri, 23 Jan 2004 08:26:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1Jx-0003AM-GM for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 08:26:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NDQ1Fo012162 for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 08:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1Jx-0003A3-Ag for ips-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 08:26:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29561 for ; Fri, 23 Jan 2004 08:25:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1Jr-0005EY-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 08:25:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1HI-00055e-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 08:23:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak1DO-0004wz-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 08:19:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1DA-0002fh-RE; Fri, 23 Jan 2004 08:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1CI-0002c6-Eo for ips@optimus.ietf.org; Fri, 23 Jan 2004 08:18:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29446 for ; Fri, 23 Jan 2004 08:18:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1CC-0004sS-00 for ips@ietf.org; Fri, 23 Jan 2004 08:18:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak17u-0004kJ-00 for ips@ietf.org; Fri, 23 Jan 2004 08:13:34 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak15F-0004ZV-00 for ips@ietf.org; Fri, 23 Jan 2004 08:10:50 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1Ak13J-00026i-00 for ips@ietf.org; Fri, 23 Jan 2004 13:08:49 +0000 From: "Ken Sandars" To: Subject: [Ips] iSCSI: Handling R2T SNACK requests Date: Fri, 23 Jan 2004 13:09:33 -0000 Message-ID: <000601c3e1b2$39fee420$b446a8c0@winminx> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, Curly scenario #27468: A session is established with no unsolicited data allowed, ErrorRecoveryLevel=1, MaxOutstandingR2T=1, MaxBurstLength=64KB. The target has declared MaxPDUDataSegmentLength=32KB Here's a sequence attempting to process a single task: I->T SCSI WRITE Command for 256KB T->I R2T TTT=180 R2TSN=0 offset=0 len=64KB I->T DATA-OUT TTT=80 DataSN=0 offset=0 len=32KB F=0 I->T DATA-OUT TTT=80 DataSN=1 offset=32KB len=32KB F=1 T->I R2T TTT=190 R2TSN=1 offset=64KB len=64KB I->T DATA-OUT TTT=190 DataSN=2 offset=64KB len=32KB F=0 I->T DATA-OUT TTT=190 DataSN=3 offset=92KB len=32KB F=1 T->I R2T TTT=200 R2TSN=2 offset=128KB len=64KB I->T DATA-OUT TTT=200 DataSN=4 offset=128KB len=32KB F=0 I->T DATA-OUT TTT=200 DataSN=5 offset=160KB len=32KB F=1 (lost at target) Some time later, a receive sequence timer pops at the target and a recovery R2T is issued for this task: T->I R2T TTT=210 R2TSN=3 offset=160KB len=32KB In the meantime, the initiator ignores the 'SHOULD' in the 2nd last paragraph of section 6.4.4.1 and sends an R2T SNACK for the command with BegRun of 2 and RunLength 0. 1. Should the target send: (a) reject (because the BegRun value asks for a non-existent task) (b) Copy of R2T with R2TSN=2 (because it must obey the MaxOutstandingR2T limit) (c) Copy of R2T with R2TSN=2 and the recovery R2T with R2TSN=3 (d) Copy of R2T with R2TSN=3 (because it considers the R2TSN=2 task as terminated) or do something else? 2. Is this a contrived question? A sane initiator would never send a SNACK in this situation, and if it did it would use BegRun=0 and RunLength=0 to get whatever it can. As always, all replies thanked for in advance Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 23 09:33:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02361 for ; Fri, 23 Jan 2004 09:33:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2MV-0008J2-VD for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 09:32:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NEWhga031922 for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 09:32:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2MV-0008In-RB for ips-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 09:32:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02346 for ; Fri, 23 Jan 2004 09:32:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2MT-0000fE-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 09:32:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2La-0000d6-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 09:31:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak2Kx-0000bB-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 09:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2Ks-00089Q-Sy; Fri, 23 Jan 2004 09:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2KX-000866-Ge for ips@optimus.ietf.org; Fri, 23 Jan 2004 09:30:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02258 for ; Fri, 23 Jan 2004 09:30:38 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2KV-0000Zv-00 for ips@ietf.org; Fri, 23 Jan 2004 09:30:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2Jc-0000Z7-00 for ips@ietf.org; Fri, 23 Jan 2004 09:29:44 -0500 Received: from srexchimc2.lss.emc.com ([168.159.100.11] helo=srexchimc2.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak2JP-0000Xi-00 for ips@ietf.org; Fri, 23 Jan 2004 09:29:31 -0500 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by srexchimc2.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D24Q8NGW; Fri, 23 Jan 2004 09:28:56 -0500 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Jan 2004 09:28:56 -0500 Message-ID: X-Sybari-Trust: 26755233 b1a25add 4fc75ff0 0000013d To: wrstuden@wasabisystems.com Cc: ips@ietf.org Subject: RE: [Ips] iSNS SLP service type Date: Fri, 23 Jan 2004 09:28:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Unless there are objections, this will go into the iSNS draft. It looks like a useful clarification. 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-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of wrstuden@wasabisystems.com > Sent: Thursday, January 22, 2004 12:56 PM > To: Andy Currid > Cc: ips@ietf.org > Subject: RE: [Ips] iSNS SLP service type > > > On Thu, 22 Jan 2004, Andy Currid wrote: > > > I thought this was covered in the iSCSI SLP draft, > > which defines "service:iscsi:sms" for discovery of > > storage management services. The template for that > > service includes a protocol field which may be set > > to "isns" to indicate an iSNS server. > > Ahhh... That's possible. To be honest, I was not really sure what the > "sms" server was good for when I read the iSCSI-SLP draft; it seemed > rather vague and not immediately relevant. > > Now that you mention it, I notice that the iSCSI-SLP draft is > mentioned in > the iSNS references section. However no part of the document > actualy uses > that references. > > Is it too late for iSNS draft comments? If not, I'd like to request/ > comment that section 2.5.1 should mention that iSCSI-SLP offers the > service template for using SLP to locate iSNS servers. > > Take care, > > 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 exim@www1.ietf.org Fri Jan 23 10:26:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05171 for ; Fri, 23 Jan 2004 10:26:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Bv-00085v-G0 for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 10:25:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NFPpPS031115 for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 10:25:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Bv-00085m-CI for ips-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 10:25:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05120 for ; Fri, 23 Jan 2004 10:25:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Bt-0002pS-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 10:25:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3B7-0002mW-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 10:25:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak3AK-0002im-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 10:24:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3A9-0007RS-TP; Fri, 23 Jan 2004 10:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak39J-0007Ke-S2 for ips@optimus.ietf.org; Fri, 23 Jan 2004 10:23:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04703; Fri, 23 Jan 2004 10:23:05 -0500 (EST) Message-Id: <200401231523.KAA04703@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 23 Jan 2004 10:23:05 -0500 Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-name-ext-02.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : NAA naming format for iSCSI Node Names Author(s) : R. Elliott, M. Krueger, M. Chadalapaka Filename : draft-ietf-ips-iscsi-name-ext-02.txt Pages : 6 Date : 2004-1-22 iSCSI is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the 'Network Address Authority' (NAA) world wide naming format used by ANSI T11 Fibre Channel (FC) protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-ext-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-iscsi-name-ext-02.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-iscsi-name-ext-02.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: <2004-1-23104703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-name-ext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-name-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-23104703.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 23 13:26:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14995 for ; Fri, 23 Jan 2004 13:26:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak60A-0008VV-SA for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 13:25:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NIPs0i032697 for ips-archive@odin.ietf.org; Fri, 23 Jan 2004 13:25:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak60A-0008VI-Nt for ips-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14979 for ; Fri, 23 Jan 2004 13:25:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak608-0005eI-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 13:25:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5zE-0005cN-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 13:24:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak5yQ-0005Zy-00 for ips-web-archive@ietf.org; Fri, 23 Jan 2004 13:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5yK-0008Lv-GY; Fri, 23 Jan 2004 13:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5yH-0008LR-Kx for ips@optimus.ietf.org; Fri, 23 Jan 2004 13:23:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14884 for ; Fri, 23 Jan 2004 13:23:53 -0500 (EST) From: elizabeth.rodriguez@dothill.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5yF-0005Yy-00 for ips@ietf.org; Fri, 23 Jan 2004 13:23:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5xS-0005Vg-00 for ips@ietf.org; Fri, 23 Jan 2004 13:23:06 -0500 Received: from mail.dothill.com ([155.254.128.7] helo=dothill.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak5wa-0005S1-00 for ips@ietf.org; Fri, 23 Jan 2004 13:22:12 -0500 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id i0NIJYvD011126 for ; Fri, 23 Jan 2004 10:19:35 -0800 (PST) Received: by exchange.artecon.com with Internet Mail Service (5.5.2653.19) id <42RV6K2D>; Fri, 23 Jan 2004 10:17:29 -0800 Message-ID: <6E76A781C4D7D511A0C000105A209B59058B171C@exchange.artecon.com> To: ips@ietf.org Date: Fri, 23 Jan 2004 10:17:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ips] IPS WG last call on iSCSI Name Extension Draft Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Hello all, David and I would like to announce IPS working group last call on the iSCSI Name Extension Draft. This draft defines a new iSCSI node name type using the "Network Address Authority" (NAA) format used by Fibre Channel for World Wide Names. The last call period will last two weeks, concluding on Monday, February 9th at 8am EST. Please post technical comments to the mailing list. Editorial comments may be posted to the mailing list or directed to the authors, with a copy to the chairs. Summary information: Draft: NAA naming format for iSCSI Node Names URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-ext-02.txt Authors: Marjorie Krueger (marjorie.krueger@hp.com) Mallikarjun Chadalapaka (cbm@rose.hp.com) Rob Elliott (elliott@hp.com) Last Call Ends: February 9th at 8am EST Thank you, Elizabeth Rodriguez and David Black IPS co-chairs -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, January 23, 2004 7:23 AM Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-name-ext-02.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 : NAA naming format for iSCSI Node Names Author(s) : R. Elliott, M. Krueger, M. Chadalapaka Filename : draft-ietf-ips-iscsi-name-ext-02.txt Pages : 6 Date : 2004-1-22 iSCSI is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the 'Network Address Authority' (NAA) world wide naming format used by ANSI T11 Fibre Channel (FC) protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-ext-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-iscsi-name-ext-02.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-iscsi-name-ext-02.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. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Jan 24 22:46:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04796 for ; Sat, 24 Jan 2004 22:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkbDh-0000LG-2Z for ips-archive@odin.ietf.org; Sat, 24 Jan 2004 22:45:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0P3jvP6001310 for ips-archive@odin.ietf.org; Sat, 24 Jan 2004 22:45:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkbDg-0000L3-Qo for ips-web-archive@optimus.ietf.org; Sat, 24 Jan 2004 22:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04789 for ; Sat, 24 Jan 2004 22:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkbDd-000591-00 for ips-web-archive@ietf.org; Sat, 24 Jan 2004 22:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkbCj-00056b-00 for ips-web-archive@ietf.org; Sat, 24 Jan 2004 22:44:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkbBu-00053u-00 for ips-web-archive@ietf.org; Sat, 24 Jan 2004 22:44:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkbBp-000077-Fq; Sat, 24 Jan 2004 22:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkbAr-00005r-8D for ips@optimus.ietf.org; Sat, 24 Jan 2004 22:43:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04713 for ; Sat, 24 Jan 2004 22:42:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkbAn-0004ze-00 for ips@ietf.org; Sat, 24 Jan 2004 22:42:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Akb9t-0004wi-00 for ips@ietf.org; Sat, 24 Jan 2004 22:42:01 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx with esmtp (Exim 4.12) id 1Akb9P-0004sX-00; Sat, 24 Jan 2004 22:41:31 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i0P3etZ3119822; Sun, 25 Jan 2004 03:40:55 GMT Received: from d10ml001.telaviv.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0P3eswk055482; Sun, 25 Jan 2004 03:40:55 GMT In-Reply-To: <000501c3e19f$6fb68c70$b446a8c0@winminx> To: "Ken Sandars" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: Retransmitting R2T pdus X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Sun, 25 Jan 2004 05:40:51 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 25/01/2004 05:40:54, Serialize complete at 25/01/2004 05:40:54 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 ips-admin@ietf.org wrote on 23/01/2004 02:55:07: > Hi everyone, > > When can/should a target resend an R2T rather than use a recovery R2T? > > I suspect the answer is only in response to a R2T SNACK request. However > section 6.8 talks about proactive retransmission of R2T's by the target, > so I'm not clear on this. > Correct - in response to a SNACK. Recovery R2T are meant to recover outgoing data. > > TIA, > Ken Sandars > Elipsan UK > > > > _______________________________________________ > 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 exim@www1.ietf.org Sat Jan 24 22:46:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04798 for ; Sat, 24 Jan 2004 22:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkbDh-0000La-KO for ips-archive@odin.ietf.org; Sat, 24 Jan 2004 22:45:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0P3jvb5001328 for ips-archive@odin.ietf.org; Sat, 24 Jan 2004 22:45:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkbDh-0000LL-F4 for ips-web-archive@optimus.ietf.org; Sat, 24 Jan 2004 22:45:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04792 for ; Sat, 24 Jan 2004 22:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkbDe-000596-00 for ips-web-archive@ietf.org; Sat, 24 Jan 2004 22:45:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkbCk-00056k-00 for ips-web-archive@ietf.org; Sat, 24 Jan 2004 22:44:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkbBu-00053v-00 for ips-web-archive@ietf.org; Sat, 24 Jan 2004 22:44:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkbBq-00007H-65; Sat, 24 Jan 2004 22:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkbAs-000067-IU for ips@optimus.ietf.org; Sat, 24 Jan 2004 22:43:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04719 for ; Sat, 24 Jan 2004 22:42:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkbAp-0004zp-00 for ips@ietf.org; Sat, 24 Jan 2004 22:42:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Akb9u-0004wy-00 for ips@ietf.org; Sat, 24 Jan 2004 22:42:02 -0500 Received: from mtagate5.uk.ibm.com ([195.212.29.138]) by ietf-mx with esmtp (Exim 4.12) id 1Akb9Q-0004sZ-00; Sat, 24 Jan 2004 22:41:32 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate5.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i0P3evWH058220; Sun, 25 Jan 2004 03:40:57 GMT Received: from d10ml001.telaviv.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0P3euG4052052; Sun, 25 Jan 2004 03:40:57 GMT In-Reply-To: <000601c3e1b2$39fee420$b446a8c0@winminx> To: "Ken Sandars" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: Handling R2T SNACK requests X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Sun, 25 Jan 2004 05:40:53 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 25/01/2004 05:40:56, Serialize complete at 25/01/2004 05:40:56 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 ips-admin@ietf.org wrote on 23/01/2004 05:09:33: > Hi all, > > Curly scenario #27468: > > A session is established with no unsolicited data allowed, > ErrorRecoveryLevel=1, MaxOutstandingR2T=1, MaxBurstLength=64KB. The > target has declared MaxPDUDataSegmentLength=32KB > > Here's a sequence attempting to process a single task: > > I->T SCSI WRITE Command for 256KB > > T->I R2T TTT=180 R2TSN=0 offset=0 len=64KB > I->T DATA-OUT TTT=80 DataSN=0 offset=0 len=32KB F=0 > I->T DATA-OUT TTT=80 DataSN=1 offset=32KB len=32KB F=1 > > T->I R2T TTT=190 R2TSN=1 offset=64KB len=64KB > I->T DATA-OUT TTT=190 DataSN=2 offset=64KB len=32KB F=0 > I->T DATA-OUT TTT=190 DataSN=3 offset=92KB len=32KB F=1 > > T->I R2T TTT=200 R2TSN=2 offset=128KB len=64KB > I->T DATA-OUT TTT=200 DataSN=4 offset=128KB len=32KB F=0 > I->T DATA-OUT TTT=200 DataSN=5 offset=160KB len=32KB F=1 (lost at > target) > > Some time later, a receive sequence timer pops at the target and a > recovery R2T is issued for this task: > > T->I R2T TTT=210 R2TSN=3 offset=160KB len=32KB > > In the meantime, the initiator ignores the 'SHOULD' in the 2nd last > paragraph of section 6.4.4.1 and sends an R2T SNACK for the command > with BegRun of 2 and RunLength 0. > > > 1. Should the target send: > (a) reject (because the BegRun value asks for a non-existent task) the task exists :-) > (b) Copy of R2T with R2TSN=2 (because it must obey the MaxOutstandingR2T > limit) That's what the initiator is asking for! If it was not sent yet you can reject it or better ignore it untill you send the real thing > (c) Copy of R2T with R2TSN=2 and the recovery R2T with R2TSN=3 > (d) Copy of R2T with R2TSN=3 (because it considers the R2TSN=2 task as > terminated) > or do something else? > > 2. Is this a contrived question? A sane initiator would never send a > SNACK in this situation, and if it did it would use BegRun=0 and > RunLength=0 to get whatever it can. > > > As always, all replies thanked for in advance > Ken Sandars > Elipsan UK > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Jan 27 04:53:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27166 for ; Tue, 27 Jan 2004 04:53:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPtj-00066S-0m for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 04:52:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R9qgKr023456 for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 04:52:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPth-000669-Cv for ips-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 04:52:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27161 for ; Tue, 27 Jan 2004 04:52:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlPte-0003vK-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 04:52:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlPsh-0003sP-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 04:51:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlPsL-0003q5-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 04:51:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPs8-0005vR-Lo; Tue, 27 Jan 2004 04:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPrh-0005sk-2J for ips@optimus.ietf.org; Tue, 27 Jan 2004 04:50:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27127 for ; Tue, 27 Jan 2004 04:50:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlPre-0003pC-00 for ips@ietf.org; Tue, 27 Jan 2004 04:50:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlPqj-0003nU-00 for ips@ietf.org; Tue, 27 Jan 2004 04:49:37 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AlPqS-0003lV-00 for ips@ietf.org; Tue, 27 Jan 2004 04:49:21 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1AlPp1-0007id-00 for ips@ietf.org; Tue, 27 Jan 2004 09:47:51 +0000 From: "Ken Sandars" To: Subject: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Date: Tue, 27 Jan 2004 09:48:31 -0000 Message-ID: <000001c3e4ba$ce95a730$7107a8c0@winminx> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi people, Does section 10.4.8 which clearly states that ExpDataSN is "the number of Data-In (read) PDUs the target has sent for the command" hold for bidirectional commands? i.e. It's not the number of Data-In and R2T PDUs sent for the command is it? Thanks again, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 27 11:50:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12779 for ; Tue, 27 Jan 2004 11:50:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWPN-0001Oo-2n for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 11:49:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RGnnUP005374 for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 11:49:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWPM-0001Ob-Q2 for ips-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 11:49:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12758 for ; Tue, 27 Jan 2004 11:49:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWPL-0005rB-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 11:49:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWNe-0005ln-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 11:48:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlWMo-0005hd-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 11:47:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWMf-00018W-7L; Tue, 27 Jan 2004 11:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWMU-00018A-Le for ips@optimus.ietf.org; Tue, 27 Jan 2004 11:46:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12694 for ; Tue, 27 Jan 2004 11:46:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWMS-0005gK-00 for ips@ietf.org; Tue, 27 Jan 2004 11:46:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWLW-0005dd-00 for ips@ietf.org; Tue, 27 Jan 2004 11:45:51 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1AlWKt-0005YR-00 for ips@ietf.org; Tue, 27 Jan 2004 11:45:11 -0500 Received: from ivvt2dxrc11 (c-66-177-51-158.se.client2.attbi.com[66.177.51.158]) by comcast.net (sccrmhc12) with SMTP id <20040127164438012003a479e> (Authid: esquicksall); Tue, 27 Jan 2004 16:44:38 +0000 Message-ID: <002001c3e4f4$df46d420$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Tue, 27 Jan 2004 11:44:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C3E4CA.F60A1B10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Ips] iSCSI: Terminating active tasks Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C3E4CA.F60A1B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Suppose an active task is terminated due to a lost connection (item b = below). When the connection is re-instated, should the active tasks get = a check condition? Note that there appeared to be a clarification added to draft 20+errata = but that didn't make it into the final draft (as I remember, there were = other objections to the errata). I don't know if the new wording is = incorrect or if it is implied by draft 20's wording and therefore not = necessary. Can someone please give me your interpretation of the following? draft 20: If the tasks terminated in the above cases a), b, c) and d)are SCSI tasks, they must be internally terminated as if with CHECK CONDITION status. This status is only meaningful for appropriately handling the internal SCSI state and SCSI side effects with respect to ordering because this status is never communicated back as a terminating status to the initiator. However additional actions may have to be taken at SCSI level depending on the SCSI context as defined by the SCSI standards (e.g., queued commands and ACA, UA for the next command on the I_T nexus in cases a), b), and c) etc. - see [SAM] and [SPC3]). draft 20+errata: [--same as above to here--] (e.g., queued commands and ACA, in cases a), b), and c), after the tasks are terminated, the target MUST report a unit attention condition on the next command processed on any connection for each affected I_T_L nexus etc. - see [SAM] and [SPC3]). Eddy ------=_NextPart_000_001D_01C3E4CA.F60A1B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Suppose an active task is terminated due to a = lost=20 connection (item b below). When the connection is re-instated, should = the active=20 tasks get a check condition?
 
Note that there appeared to = be a clarification=20 added to draft 20+errata but that didn't make it into the = final draft=20 (as I remember, there were other objections to the errata). I don't know = if the new wording is incorrect or if it is implied by draft = 20's=20 wording and therefore not necessary.
 
Can someone please give me your interpretation of = the=20 following?
 
draft 20:
 
If the tasks terminated in = the above=20 cases a), b, c) and d)are SCSI
tasks, they must be = internally=20 terminated as if with CHECK CONDITION
status. This status is = only meaningful=20 for appropriately handling
the internal SCSI state = and SCSI side=20 effects with respect to
ordering because this = status is never=20 communicated back as a
terminating status to the = initiator.=20 However additional actions may
have to be taken at SCSI = level depending=20 on the SCSI context as
defined by the SCSI = standards (e.g.,=20 queued commands and ACA, UA for
the next command on the = I_T nexus in=20 cases a), b), and c) etc. - see
[SAM] and = [SPC3]).
 
draft = 20+errata:
 
[--same as above to = here--] (e.g.,=20 queued commands and ACA, in
cases a), b), and c), = after the tasks=20 are terminated, the target
MUST report a unit = attention condition=20 on the next command processed
on any connection for each = affected=20 I_T_L nexus etc. - see [SAM] and
[SPC3]).
 
Eddy
 
------=_NextPart_000_001D_01C3E4CA.F60A1B10-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 27 13:51:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18053 for ; Tue, 27 Jan 2004 13:51:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYIk-0002lL-Li for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 13:51:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RIp6Fm010613 for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 13:51:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYIk-0002l6-Gi for ips-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 13:51:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18025 for ; Tue, 27 Jan 2004 13:51:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYIi-0006ez-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 13:51:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYHm-0006Zk-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 13:50:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlYGn-0006V6-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 13:49:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYGj-0002ai-1B; Tue, 27 Jan 2004 13:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYGc-0002a6-68 for ips@optimus.ietf.org; Tue, 27 Jan 2004 13:48:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17933 for ; Tue, 27 Jan 2004 13:48:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYGZ-0006Su-00 for ips@ietf.org; Tue, 27 Jan 2004 13:48:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYFb-0006OJ-00 for ips@ietf.org; Tue, 27 Jan 2004 13:47:51 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1AlYEf-0006K8-00 for ips@ietf.org; Tue, 27 Jan 2004 13:46:53 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id 147451C026BF; Tue, 27 Jan 2004 13:46:53 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bea179.rose.hp.com [15.23.140.179]) by rosemail.rose.hp.com (Postfix) with ESMTP id A28C0800C; Tue, 27 Jan 2004 10:42:31 -0800 (PST) Message-ID: <4016B213.1050203@rose.hp.com> Date: Tue, 27 Jan 2004 10:46:43 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Sandars Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands References: <000001c3e4ba$ce95a730$7107a8c0@winminx> In-Reply-To: <000001c3e4ba$ce95a730$7107a8c0@winminx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ken Sandars wrote: > Hi people, > > Does section 10.4.8 which clearly states that ExpDataSN is "the number > of Data-In (read) PDUs the target has sent for the command" hold for > bidirectional commands? Yes. > > i.e. It's not the number of Data-In and R2T PDUs sent for the command is > it? No. I believe an ExpDataSN mismatch at the initiator is always interpreted as lost Data-In PDU(s), and could trigger within-command recovery (appendix E.2.2). -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 27 13:58:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18275 for ; Tue, 27 Jan 2004 13:58:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYPO-0003XS-66 for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 13:57:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RIvwWl013596 for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 13:57:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYPO-0003XD-19 for ips-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 13:57:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18254 for ; Tue, 27 Jan 2004 13:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYPL-00075o-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 13:57:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYOU-00071e-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 13:57:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlYNU-0006xy-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 13:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYNV-0003G0-BH; Tue, 27 Jan 2004 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYNO-0003CR-QO for ips@optimus.ietf.org; Tue, 27 Jan 2004 13:55:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18188 for ; Tue, 27 Jan 2004 13:55:51 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYNM-0006wV-00 for ips@ietf.org; Tue, 27 Jan 2004 13:55:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYMQ-0006tN-00 for ips@ietf.org; Tue, 27 Jan 2004 13:54:55 -0500 Received: from msgbas2x.cos.agilent.com ([192.25.240.37]) by ietf-mx with esmtp (Exim 4.12) id 1AlYLW-0006pZ-00; Tue, 27 Jan 2004 13:53:58 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 2AAC76EB0; Tue, 27 Jan 2004 11:53:53 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 0D611257; Tue, 27 Jan 2004 11:53:53 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Jan 2004 11:53:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSCSI: Handling R2T SNACK requests Date: Tue, 27 Jan 2004 11:53:52 -0700 Message-ID: Thread-Topic: [Ips] iSCSI: Handling R2T SNACK requests Thread-Index: AcPi9aUE9jldlktnSNy3Uz8ps3arbQCDY+RQ To: , Cc: , X-OriginalArrivalTime: 27 Jan 2004 18:53:52.0813 (UTC) FILETIME=[E866EDD0:01C3E506] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Julian and Ken, To answer Ken's last question first, this does seem to be a very odd = scenario. The initiator obviously received the R2T because it responded = by sending data and then it SNACKs the R2T. 10.16 says:=20 Any SNACK that requests a numbered-response, Data, or R2T that was not sent by the target or was already acknowledged by the initiator, MUST be rejected with a reason code of "Protocol error". 3.2.2.3 says: Data and R2T PDUs are implicity acknowledged by status for the command. There doesn't seem to be a description of the exact event that triggers = the implicit acknowlegement for an R2T.=20 Is the R2T acknowledge when one receives the first Data-out in response = to it? If so, then R2TSN=3D2 was already acknowledged and the target = should reject the SNACK with reason code of Protocol error. This seems a = reasonable interpretation since the initial Data-Out demonstrates that = the initiator received the R2T. Is the R2T acknowledged only by the Data-out response to it with F=3D1? = One could interpret that only the final Data-out PDU changes the status = of the command and therefore acknowledges the R2T. If this is the case, = then SNACK should cause retransmission R2TSN 2 and R2TSN 3. (Run length = of zero requested retransmission of R2Ts starting with the initial and = it doesn't matter that R2TSN was a recovery R2T.) So it should be either a or c. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, January 24, 2004 7:41 PM To: Ken Sandars Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] iSCSI: Handling R2T SNACK requests ips-admin@ietf.org wrote on 23/01/2004 05:09:33: > Hi all, >=20 > Curly scenario #27468: >=20 > A session is established with no unsolicited data allowed, > ErrorRecoveryLevel=3D1, MaxOutstandingR2T=3D1, MaxBurstLength=3D64KB. = The > target has declared MaxPDUDataSegmentLength=3D32KB >=20 > Here's a sequence attempting to process a single task: >=20 > I->T SCSI WRITE Command for 256KB >=20 > T->I R2T TTT=3D180 R2TSN=3D0 offset=3D0 len=3D64KB > I->T DATA-OUT TTT=3D80 DataSN=3D0 offset=3D0 len=3D32KB F=3D0 > I->T DATA-OUT TTT=3D80 DataSN=3D1 offset=3D32KB len=3D32KB F=3D1 >=20 > T->I R2T TTT=3D190 R2TSN=3D1 offset=3D64KB len=3D64KB > I->T DATA-OUT TTT=3D190 DataSN=3D2 offset=3D64KB len=3D32KB F=3D0 > I->T DATA-OUT TTT=3D190 DataSN=3D3 offset=3D92KB len=3D32KB F=3D1 >=20 > T->I R2T TTT=3D200 R2TSN=3D2 offset=3D128KB len=3D64KB > I->T DATA-OUT TTT=3D200 DataSN=3D4 offset=3D128KB len=3D32KB F=3D0 > I->T DATA-OUT TTT=3D200 DataSN=3D5 offset=3D160KB len=3D32KB F=3D1 = (lost at > target) >=20 > Some time later, a receive sequence timer pops at the target and a > recovery R2T is issued for this task: >=20 > T->I R2T TTT=3D210 R2TSN=3D3 offset=3D160KB len=3D32KB >=20 > In the meantime, the initiator ignores the 'SHOULD' in the 2nd last=20 > paragraph of section 6.4.4.1 and sends an R2T SNACK for the command > with BegRun of 2 and RunLength 0. >=20 >=20 > 1. Should the target send: > (a) reject (because the BegRun value asks for a non-existent task) the task exists :-) > (b) Copy of R2T with R2TSN=3D2 (because it must obey the = MaxOutstandingR2T > limit) That's what the initiator is asking for! If it was not sent yet you can=20 reject it or better ignore it untill you send the real thing > (c) Copy of R2T with R2TSN=3D2 and the recovery R2T with R2TSN=3D3 > (d) Copy of R2T with R2TSN=3D3 (because it considers the R2TSN=3D2 = task as > terminated) > or do something else? >=20 > 2. Is this a contrived question? A sane initiator would never send a > SNACK in this situation, and if it did it would use BegRun=3D0 and > RunLength=3D0 to get whatever it can. >=20 >=20 > As always, all replies thanked for in advance > Ken Sandars > Elipsan UK >=20 >=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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 27 14:29:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19153 for ; Tue, 27 Jan 2004 14:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYtR-0005tu-SG for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 14:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RJT1sC022682 for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 14:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYtR-0005tl-NZ for ips-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 14:29:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19134 for ; Tue, 27 Jan 2004 14:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYtK-0000xx-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 14:28:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYqi-0000pF-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 14:26:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlYoo-0000hQ-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 14:24:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYob-0005bq-D2; Tue, 27 Jan 2004 14:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYoY-0005bd-5k for ips@optimus.ietf.org; Tue, 27 Jan 2004 14:23:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19036 for ; Tue, 27 Jan 2004 14:23:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYoQ-0000fF-00 for ips@ietf.org; Tue, 27 Jan 2004 14:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYle-0000Z5-00 for ips@ietf.org; Tue, 27 Jan 2004 14:20:59 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AlYkA-0000TR-00 for ips@ietf.org; Tue, 27 Jan 2004 14:19:26 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id A46D71C0229D; Tue, 27 Jan 2004 11:18:52 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bea179.rose.hp.com [15.23.140.179]) by rosemail.rose.hp.com (Postfix) with ESMTP id 687428097; Tue, 27 Jan 2004 11:14:31 -0800 (PST) Message-ID: <4016B993.1080203@rose.hp.com> Date: Tue, 27 Jan 2004 11:18:43 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: Terminating active tasks References: <002001c3e4f4$df46d420$0303a8c0@ivvt2dxrc11> In-Reply-To: <002001c3e4f4$df46d420$0303a8c0@ivvt2dxrc11> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddy, Check the -02 revision of the command ordering draft, section 5 "connection failure considerations". The "affected I_T_L nexus" as used in that draft is each I_T_L nexus for LUs that the iSCSI session can get to. Yes, there's a requirement for a UA. But note that the requirement is not related to connection reinstatement per se. And not all active tasks get check conditions either. Only the first task on each I_T_L nexus is affected. Hope that helps. Mallikarjun Eddy Quicksall wrote: > Suppose an active task is terminated due to a lost connection (item b > below). When the connection is re-instated, should the active tasks get > a check condition? > > Note that there appeared to be a clarification added to draft 20+errata > but that didn't make it into the final draft (as I remember, there were > other objections to the errata). I don't know if the new wording is > incorrect or if it is implied by draft 20's wording and therefore not > necessary. > > Can someone please give me your interpretation of the following? > > draft 20: > > If the tasks terminated in the above cases a), b, c) and d)are SCSI > tasks, they must be internally terminated as if with CHECK CONDITION > status. This status is only meaningful for appropriately handling > the internal SCSI state and SCSI side effects with respect to > ordering because this status is never communicated back as a > terminating status to the initiator. However additional actions may > have to be taken at SCSI level depending on the SCSI context as > defined by the SCSI standards (e.g., queued commands and ACA, UA for > the next command on the I_T nexus in cases a), b), and c) etc. - see > [SAM] and [SPC3]). > > draft 20+errata: > > [--same as above to here--] (e.g., queued commands and ACA, in > cases a), b), and c), after the tasks are terminated, the target > MUST report a unit attention condition on the next command processed > on any connection for each affected I_T_L nexus etc. - see [SAM] and > [SPC3]). > > Eddy > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 27 19:27:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04641 for ; Tue, 27 Jan 2004 19:27:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldXd-00069i-Bw for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 19:26:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0QnaV023648 for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 19:26:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald8j-0006zu-Tu for ips-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:01:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01454 for ; Tue, 27 Jan 2004 19:00:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ald8R-0004U7-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 19:00:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ald6k-00047H-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 18:59:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ald5N-0003sO-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 18:57:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald56-0005Km-1L; Tue, 27 Jan 2004 18:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al8ax-00067e-1a for ips@optimus.ietf.org; Mon, 26 Jan 2004 10:24:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09509 for ; Mon, 26 Jan 2004 10:24:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al8au-0002q9-00 for ips@ietf.org; Mon, 26 Jan 2004 10:24:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al8Zs-0002n3-00 for ips@ietf.org; Mon, 26 Jan 2004 10:23:05 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1Al8Z2-0002kP-00 for ips@ietf.org; Mon, 26 Jan 2004 10:22:12 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1Al8Xc-0005WU-00 for ips@ietf.org; Mon, 26 Jan 2004 15:20:44 +0000 From: "Ken Sandars" To: Subject: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Date: Mon, 26 Jan 2004 15:21:26 -0000 Message-ID: <000201c3e420$264b47a0$7107a8c0@winminx> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi people, Does section 10.4.8 which clearly states that ExpDataSN is "the number of Data-In (read) PDUs the target has sent for the command" hold for bidirectional commands? i.e. It's not the number of Data-In and R2T PDUs sent for the command is it? Thanks again, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Jan 27 19:39:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05852 for ; Tue, 27 Jan 2004 19:39:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldjA-0007JL-Lb for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 19:38:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0ciri028090 for ips-archive@odin.ietf.org; Tue, 27 Jan 2004 19:38:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldj9-0007Is-4l for ips-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:38:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05664 for ; Tue, 27 Jan 2004 19:38:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aldj7-0002eZ-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 19:38:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aldfx-0001sZ-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 19:35:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Alddb-0001I7-00 for ips-web-archive@ietf.org; Tue, 27 Jan 2004 19:32:59 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldRO-00065C-CN for ips-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldKs-00032S-2t; Tue, 27 Jan 2004 19:13:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlFac-0005Qh-4k for ips@optimus.ietf.org; Mon, 26 Jan 2004 17:52:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22657 for ; Mon, 26 Jan 2004 17:52:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlFaZ-0001Ah-00 for ips@ietf.org; Mon, 26 Jan 2004 17:52:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlFZf-00017J-00 for ips@ietf.org; Mon, 26 Jan 2004 17:51:20 -0500 Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx with esmtp (Exim 4.12) id 1AlFYv-00011V-00 for ips@ietf.org; Mon, 26 Jan 2004 17:50:33 -0500 Received: from ivvt2dxrc11 (c-66-177-51-158.se.client2.attbi.com[66.177.51.158]) by comcast.net (rwcrmhc13) with SMTP id <2004012622500201500kfbcee> (Authid: esquicksall); Mon, 26 Jan 2004 22:50:02 +0000 Message-ID: <001201c3e45e$bbc1e0d0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Mon, 26 Jan 2004 17:50:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C3E434.D2008E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Ips] iSCSI: Terminating active tasks Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C3E434.D2008E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Suppose an active task is terminated due to a lost connection (item b = below). When the connection is re-instated, should the active tasks get = a check condition? Note that there appeared to be a clarification added to draft 20+errata = but that didn't make it into the final draft (as I remember, there were = other objections to the errata). I don't know if the new wording is = incorrect or if it is implied by draft 20's wording and therefore not = necessary. Can someone please give me your interpretation of the following? draft 20: If the tasks terminated in the above cases a), b, c) and d)are SCSI tasks, they must be internally terminated as if with CHECK CONDITION status. This status is only meaningful for appropriately handling the internal SCSI state and SCSI side effects with respect to ordering because this status is never communicated back as a terminating status to the initiator. However additional actions may have to be taken at SCSI level depending on the SCSI context as defined by the SCSI standards (e.g., queued commands and ACA, UA for the next command on the I_T nexus in cases a), b), and c) etc. - see [SAM] and [SPC3]). draft 20+errata: [--same as above to here--] (e.g., queued commands and ACA, in cases a), b), and c), after the tasks are terminated, the target MUST report a unit attention condition on the next command processed on any connection for each affected I_T_L nexus etc. - see [SAM] and [SPC3]). Eddy ------=_NextPart_000_000F_01C3E434.D2008E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Suppose an active task is terminated due to a = lost=20 connection (item b below). When the connection is re-instated, should = the active=20 tasks get a check condition?
 
Note that there appeared to = be a clarification=20 added to draft 20+errata but that didn't make it into the = final draft=20 (as I remember, there were other objections to the errata). I don't know = if the new wording is incorrect or if it is implied by draft = 20's=20 wording and therefore not necessary.
 
Can someone please give me your interpretation of = the=20 following?
 
draft 20:
 
If the tasks terminated in = the above=20 cases a), b, c) and d)are SCSI
tasks, they must be = internally=20 terminated as if with CHECK CONDITION
status. This status is = only meaningful=20 for appropriately handling
the internal SCSI state = and SCSI side=20 effects with respect to
ordering because this = status is never=20 communicated back as a
terminating status to the = initiator.=20 However additional actions may
have to be taken at SCSI = level depending=20 on the SCSI context as
defined by the SCSI = standards (e.g.,=20 queued commands and ACA, UA for
the next command on the = I_T nexus in=20 cases a), b), and c) etc. - see
[SAM] and = [SPC3]).
 
draft = 20+errata:
 
[--same as above to = here--] (e.g.,=20 queued commands and ACA, in
cases a), b), and c), = after the tasks=20 are terminated, the target
MUST report a unit = attention condition=20 on the next command processed
on any connection for each = affected=20 I_T_L nexus etc. - see [SAM] and
[SPC3]).
 
Eddy
 ------=_NextPart_000_000F_01C3E434.D2008E70-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 28 02:29:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15491 for ; Wed, 28 Jan 2004 02:29:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alk8Z-0004j3-7x for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 02:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S7TNlb018157 for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 02:29:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alk8X-0004iY-Rf for ips-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 02:29:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15141 for ; Wed, 28 Jan 2004 02:29:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alk8U-00013J-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 02:29:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alk7X-000107-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 02:28:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alk7O-0000ww-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 02:28:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alk7H-0004Om-F6; Wed, 28 Jan 2004 02:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alk6Y-0004FJ-MB for ips@optimus.ietf.org; Wed, 28 Jan 2004 02:27:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13596 for ; Wed, 28 Jan 2004 02:27:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alk6V-0000va-00 for ips@ietf.org; Wed, 28 Jan 2004 02:27:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alk5W-0000rs-00 for ips@ietf.org; Wed, 28 Jan 2004 02:26:15 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx with esmtp (Exim 4.12) id 1Alk4Z-0000lv-00; Wed, 28 Jan 2004 02:25:15 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i0S7OTBT096320; Wed, 28 Jan 2004 07:24:29 GMT Received: from d10ml001.telaviv.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0S7OR5J041062; Wed, 28 Jan 2004 07:24:28 GMT In-Reply-To: <001201c3e45e$bbc1e0d0$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: Terminating active tasks X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Wed, 28 Jan 2004 09:24:26 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 28/01/2004 09:24:27, Serialize complete at 28/01/2004 09:24:27 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Eddy, ips-admin@ietf.org wrote on 27/01/2004 00:50:00: > Suppose an active task is terminated due to a lost connection (item b > below). When the connection is re-instated, should the active tasks > get a check condition? > > Note that there appeared to be a clarification added to draft > 20+errata but that didn't make it into the final draft (as I remember, > there were other objections to the errata). I don't know if the new > wording is incorrect or if it is implied by draft 20's wording and > therefore not necessary. > > Can someone please give me your interpretation of the following? > > draft 20: > > If the tasks terminated in the above cases a), b, c) and d)are SCSI > tasks, they must be internally terminated as if with CHECK CONDITION > status. This status is only meaningful for appropriately handling > the internal SCSI state and SCSI side effects with respect to > ordering because this status is never communicated back as a > terminating status to the initiator. However additional actions may > have to be taken at SCSI level depending on the SCSI context as > defined by the SCSI standards (e.g., queued commands and ACA, UA for > the next command on the I_T nexus in cases a), b), and c) etc. - see > [SAM] and [SPC3]). > > draft 20+errata: > > [--same as above to here--] (e.g., queued commands and ACA, in > cases a), b), and c), after the tasks are terminated, the target > MUST report a unit attention condition on the next command processed > on any connection for each affected I_T_L nexus etc. - see [SAM] and > [SPC3]). > > Eddy The text you quote refers to the target (that has no chance to communicate any status). The change that appears in the errata is that the UA is now mandatory when the connection is reinstated and you get new commands. Julo _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 28 09:19:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01581 for ; Wed, 28 Jan 2004 09:19:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqWZ-000101-Dt for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 09:18:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SEIZjX003837 for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 09:18:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqWZ-0000zo-8n for ips-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 09:18:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01568 for ; Wed, 28 Jan 2004 09:18:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlqWX-0004sZ-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 09:18:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlqVc-0004oW-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 09:17:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlqV9-0004k3-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 09:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqV3-0000rs-8T; Wed, 28 Jan 2004 09:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlqUb-0000rC-MK for ips@optimus.ietf.org; Wed, 28 Jan 2004 09:16:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01526 for ; Wed, 28 Jan 2004 09:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlqUa-0004in-00 for ips@ietf.org; Wed, 28 Jan 2004 09:16:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlqTj-0004en-00 for ips@ietf.org; Wed, 28 Jan 2004 09:15:40 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AlqTB-0004ZC-00 for ips@ietf.org; Wed, 28 Jan 2004 09:15:05 -0500 Received: from ivvt2dxrc11 (c-66-177-51-158.se.client2.attbi.com[66.177.51.158]) by comcast.net (sccrmhc11) with SMTP id <2004012814143501100jahgge> (Authid: esquicksall); Wed, 28 Jan 2004 14:14:35 +0000 Message-ID: <000401c3e5a9$0e7861f0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Mallikarjun C." Cc: References: <002001c3e4f4$df46d420$0303a8c0@ivvt2dxrc11> <4016B993.1080203@rose.hp.com> Subject: Re: [Ips] iSCSI: Terminating active tasks Date: Wed, 28 Jan 2004 09:14:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks, that clears it up. But I see an implementation issue in regards to a SCSI target layer that interfaces to more than one type of transport. If that layer is going to give this UA, then it wouldn't apply to future transports that also have a similar connection issue. Wouldn't it be better if the UA was more generic? Perhaps eliminating the word "ISCSI". ("SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT"). Eddy ----- Original Message ----- From: "Mallikarjun C." To: "Eddy Quicksall" Cc: Sent: Tuesday, January 27, 2004 2:18 PM Subject: Re: [Ips] iSCSI: Terminating active tasks > Eddy, > > Check the -02 revision of the command ordering draft, > section 5 "connection failure considerations". The > "affected I_T_L nexus" as used in that draft is each > I_T_L nexus for LUs that the iSCSI session can get to. > > Yes, there's a requirement for a UA. But note that > the requirement is not related to connection reinstatement > per se. And not all active tasks get check conditions > either. Only the first task on each I_T_L nexus is > affected. > > Hope that helps. > > Mallikarjun > > > Eddy Quicksall wrote: > > > Suppose an active task is terminated due to a lost connection (item b > > below). When the connection is re-instated, should the active tasks get > > a check condition? > > > > Note that there appeared to be a clarification added to draft 20+errata > > but that didn't make it into the final draft (as I remember, there were > > other objections to the errata). I don't know if the new wording is > > incorrect or if it is implied by draft 20's wording and therefore not > > necessary. > > > > Can someone please give me your interpretation of the following? > > > > draft 20: > > > > If the tasks terminated in the above cases a), b, c) and d)are SCSI > > tasks, they must be internally terminated as if with CHECK CONDITION > > status. This status is only meaningful for appropriately handling > > the internal SCSI state and SCSI side effects with respect to > > ordering because this status is never communicated back as a > > terminating status to the initiator. However additional actions may > > have to be taken at SCSI level depending on the SCSI context as > > defined by the SCSI standards (e.g., queued commands and ACA, UA for > > the next command on the I_T nexus in cases a), b), and c) etc. - see > > [SAM] and [SPC3]). > > > > draft 20+errata: > > > > [--same as above to here--] (e.g., queued commands and ACA, in > > cases a), b), and c), after the tasks are terminated, the target > > MUST report a unit attention condition on the next command processed > > on any connection for each affected I_T_L nexus etc. - see [SAM] and > > [SPC3]). > > > > Eddy > > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Jan 28 13:07:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17456 for ; Wed, 28 Jan 2004 13:07:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu5P-0003Zn-Lx for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 13:06:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SI6lTO013747 for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 13:06:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu5P-0003Ze-IL for ips-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:06:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17428 for ; Wed, 28 Jan 2004 13:06:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alu5N-0007CG-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 13:06:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alu4Q-00075B-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 13:05:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alu3q-0006zr-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 13:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu3i-0003Bc-Hg; Wed, 28 Jan 2004 13:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu3N-00034C-Es for ips@optimus.ietf.org; Wed, 28 Jan 2004 13:04:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17355 for ; Wed, 28 Jan 2004 13:04:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alu3L-0006z5-00 for ips@ietf.org; Wed, 28 Jan 2004 13:04:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alu2S-0006us-00 for ips@ietf.org; Wed, 28 Jan 2004 13:03:45 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1Alu26-0006q3-00 for ips@ietf.org; Wed, 28 Jan 2004 13:03:27 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel9.hp.com (Postfix) with ESMTP id 252BE1C01AB4; Wed, 28 Jan 2004 13:03:17 -0500 (EST) Received: from rose.hp.com (pal2nai172036.nsr.hp.com [15.244.172.36]) by rosemail.rose.hp.com (Postfix) with ESMTP id 312B08091; Wed, 28 Jan 2004 09:58:51 -0800 (PST) Message-ID: <4017F95C.3010100@rose.hp.com> Date: Wed, 28 Jan 2004 10:03:08 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: Terminating active tasks References: <002001c3e4f4$df46d420$0303a8c0@ivvt2dxrc11> <4016B993.1080203@rose.hp.com> <000401c3e5a9$0e7861f0$0303a8c0@ivvt2dxrc11> In-Reply-To: <000401c3e5a9$0e7861f0$0303a8c0@ivvt2dxrc11> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddy Quicksall wrote: > Thanks, that clears it up. > > But I see an implementation issue in regards to a SCSI target layer that > interfaces to more than one type of transport. If that layer is going to > give this UA, then it wouldn't apply to future transports that also have a > similar connection issue. > > Wouldn't it be better if the UA was more generic? Perhaps eliminating the > word "ISCSI". ("SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT"). That would have been my preference as well. OTOH, I don't believe this is an issue per se for implementations - transport is specifying SCSI's return values on conditions unique to the transport (so does FCP), implementations should take that into account. Mallikarjun > > Eddy > > ----- Original Message ----- > From: "Mallikarjun C." > To: "Eddy Quicksall" > Cc: > Sent: Tuesday, January 27, 2004 2:18 PM > Subject: Re: [Ips] iSCSI: Terminating active tasks > > > >>Eddy, >> >>Check the -02 revision of the command ordering draft, >>section 5 "connection failure considerations". The >>"affected I_T_L nexus" as used in that draft is each >>I_T_L nexus for LUs that the iSCSI session can get to. >> >>Yes, there's a requirement for a UA. But note that >>the requirement is not related to connection reinstatement >>per se. And not all active tasks get check conditions >>either. Only the first task on each I_T_L nexus is >>affected. >> >>Hope that helps. >> >>Mallikarjun >> >> >>Eddy Quicksall wrote: >> >> >>>Suppose an active task is terminated due to a lost connection (item b >>>below). When the connection is re-instated, should the active tasks get >>>a check condition? >>> >>>Note that there appeared to be a clarification added to draft 20+errata >>>but that didn't make it into the final draft (as I remember, there were >>>other objections to the errata). I don't know if the new wording is >>>incorrect or if it is implied by draft 20's wording and therefore not >>>necessary. >>> >>>Can someone please give me your interpretation of the following? >>> >>>draft 20: >>> >>>If the tasks terminated in the above cases a), b, c) and d)are SCSI >>>tasks, they must be internally terminated as if with CHECK CONDITION >>>status. This status is only meaningful for appropriately handling >>>the internal SCSI state and SCSI side effects with respect to >>>ordering because this status is never communicated back as a >>>terminating status to the initiator. However additional actions may >>>have to be taken at SCSI level depending on the SCSI context as >>>defined by the SCSI standards (e.g., queued commands and ACA, UA for >>>the next command on the I_T nexus in cases a), b), and c) etc. - see >>>[SAM] and [SPC3]). >>> >>>draft 20+errata: >>> >>>[--same as above to here--] (e.g., queued commands and ACA, in >>>cases a), b), and c), after the tasks are terminated, the target >>>MUST report a unit attention condition on the next command processed >>>on any connection for each affected I_T_L nexus etc. - see [SAM] and >>>[SPC3]). >>> >>>Eddy >>> _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 28 16:44:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01625 for ; Wed, 28 Jan 2004 16:44:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlxTO-0003gC-85 for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 16:43:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SLhk0Q014144 for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 16:43:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlxTN-0003g3-Vn for ips-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 16:43:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01589 for ; Wed, 28 Jan 2004 16:43:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlxTM-0000i5-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 16:43:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlxSQ-0000dK-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 16:42:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlxRj-0000Yu-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 16:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlxRg-0003Wp-Lp; Wed, 28 Jan 2004 16:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlxRW-0003W1-3F for ips@optimus.ietf.org; Wed, 28 Jan 2004 16:41:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01564 for ; Wed, 28 Jan 2004 16:41:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlxRU-0000Y8-00 for ips@ietf.org; Wed, 28 Jan 2004 16:41:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlxQX-0000TH-00 for ips@ietf.org; Wed, 28 Jan 2004 16:40:50 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1AlxPk-0000Ji-00 for ips@ietf.org; Wed, 28 Jan 2004 16:40:00 -0500 Received: from ivvt2dxrc11 (c-66-177-51-158.se.client2.attbi.com[66.177.51.158]) by comcast.net (sccrmhc12) with SMTP id <2004012821393001200253b7e> (Authid: esquicksall); Wed, 28 Jan 2004 21:39:30 +0000 Message-ID: <003d01c3e5e7$36150860$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Wed, 28 Jan 2004 16:39:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C3E5BD.4CD25BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Ips] iSCSI: abort task set Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C3E5BD.4CD25BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've always wondered about the following paragraph but never asked. 10.6.2 says: The target: a) Receives the ABORT TASK SET/CLEAR TASK SET request. b) Waits for all target transfer tags to be responded to and for all affected tasks in the task set to be received. How can the target determine that all affected tasks in the task set = have been received? Does this simply mean that the target must sequence = the TMF just as any other command even if the TMF is immediate? What about if TST is 000b? How do I determine when some other initiator = has sent all affected tasks? Eddy ------=_NextPart_000_003A_01C3E5BD.4CD25BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've always wondered about the following paragraph but never = asked.
 
10.6.2 says:

The target:

a) Receives the ABORT TASK SET/CLEAR TASK SET = request.

b) Waits for all target transfer tags to be responded = to

and for all affected tasks in the task set to be

received.

 
How can the target determine that all affected tasks in the task = set have=20 been received? Does this simply mean that the target must sequence the = TMF just=20 as any other command even if the TMF is immediate?
 
What about if TST is 000b? How do I determine when = some other=20 initiator has sent all affected tasks?
 
Eddy
------=_NextPart_000_003A_01C3E5BD.4CD25BE0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Jan 28 23:17:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17536 for ; Wed, 28 Jan 2004 23:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am3bq-0007oC-Qa for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 23:16:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T4GsJD030010 for ips-archive@odin.ietf.org; Wed, 28 Jan 2004 23:16:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am3bq-0007nx-KS for ips-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 23:16:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17356 for ; Wed, 28 Jan 2004 23:16:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am3bo-0001Cd-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 23:16:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am3aY-0000wc-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 23:15:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Am3ZG-0000lk-00 for ips-web-archive@ietf.org; Wed, 28 Jan 2004 23:14:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Am3OV-0002Ip-5D for ips-web-archive@ietf.org; Wed, 28 Jan 2004 23:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am3OR-0006nY-Uc; Wed, 28 Jan 2004 23:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am3Nb-0006jF-PG for ips@optimus.ietf.org; Wed, 28 Jan 2004 23:02:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16831 for ; Wed, 28 Jan 2004 23:02:07 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am3NY-0007VD-00 for ips@ietf.org; Wed, 28 Jan 2004 23:02:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am3MA-0007Aj-00 for ips@ietf.org; Wed, 28 Jan 2004 23:00:42 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Am3Ki-0006rH-00 for ips@ietf.org; Wed, 28 Jan 2004 22:59:12 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 0F68C40141; Wed, 28 Jan 2004 22:59:08 -0500 (EST) Date: Wed, 28 Jan 2004 19:58:58 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: ips@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ips] Finding iSNS using SLP Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 I have some more questions about using SLP to find iSNS servers. 1) How do I tell if a given iSNS server URL is using UDP or TCP? iSNS supports both, but doesn't expose that in the URL. The SLP draft notes transport as an attribute for iSCSI targets, but not for SMS servers (of which iSNS is a subset). 2) iSNS heartbeat messages have the concept of server priority (primary, secondary, etc.). The SLP attributes (for SMS servers) don't support this, just if the server's iSNS or something else. I think it would be useful for server priority to be reflected in the SLP bindings if possible. Thoughts? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 10:19:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23222 for ; Thu, 29 Jan 2004 10:19:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDwD-00058G-B7 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 10:18:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFIbND019723 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 10:18:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDwD-00057x-5w for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 10:18:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23174 for ; Thu, 29 Jan 2004 10:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDwA-0001lM-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 10:18:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDvH-0001eO-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 10:17:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmDuo-0001WH-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 10:17:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDuf-0004Vz-RB; Thu, 29 Jan 2004 10:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDu3-0004Hs-27 for ips@optimus.ietf.org; Thu, 29 Jan 2004 10:16:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22877 for ; Thu, 29 Jan 2004 10:16:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDu0-0001Uk-00 for ips@ietf.org; Thu, 29 Jan 2004 10:16:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDt9-0001OP-00 for ips@ietf.org; Thu, 29 Jan 2004 10:15:27 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx with esmtp (Exim 4.12) id 1AmDsH-0001B8-00; Thu, 29 Jan 2004 10:14:33 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i0TFE0ZP156906; Thu, 29 Jan 2004 15:14:00 GMT Received: from d10ml001.telaviv.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0TFDxTN082012; Thu, 29 Jan 2004 15:13:59 GMT In-Reply-To: <000001c3e4ba$ce95a730$7107a8c0@winminx> To: "Ken Sandars" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Thu, 29 Jan 2004 17:13:57 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 29/01/2004 17:13:57, Serialize complete at 29/01/2004 17:13:57 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 It is in fact the Data-In + R2T - Julo "Ken Sandars" Sent by: ips-admin@ietf.org 27/01/2004 11:48 To cc Subject [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Hi people, Does section 10.4.8 which clearly states that ExpDataSN is "the number of Data-In (read) PDUs the target has sent for the command" hold for bidirectional commands? i.e. It's not the number of Data-In and R2T PDUs sent for the command is it? Thanks again, Ken Sandars Elipsan UK _______________________________________________ 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 exim@www1.ietf.org Thu Jan 29 13:33:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06796 for ; Thu, 29 Jan 2004 13:33:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGym-0003po-Aq for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 13:33:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TIXSpO014736 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 13:33:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGym-0003pb-6w for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 13:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06690 for ; Thu, 29 Jan 2004 13:33:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmGyk-000526-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 13:33:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmGxP-0004le-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 13:32:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmGwQ-0004Zy-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 13:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGwP-0003gw-SG; Thu, 29 Jan 2004 13:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGvv-0003fd-0Y for ips@optimus.ietf.org; Thu, 29 Jan 2004 13:30:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06513 for ; Thu, 29 Jan 2004 13:30:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmGvs-0004XT-00 for ips@ietf.org; Thu, 29 Jan 2004 13:30:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmGv1-0004RN-00 for ips@ietf.org; Thu, 29 Jan 2004 13:29:36 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1AmGuI-0004LC-00 for ips@ietf.org; Thu, 29 Jan 2004 13:28:50 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id 3C6301C0292E for ; Thu, 29 Jan 2004 10:28:49 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 67A1F809B for ; Thu, 29 Jan 2004 10:24:19 -0800 (PST) Message-ID: <401950D8.6060701@rose.hp.com> Date: Thu, 29 Jan 2004 10:28:40 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Not sure why the initiator needs to be reported on the total # of R2Ts in the final response....I presume any mismatch in R2Ts is already factored into the status. _If_ we indeed want to include R2Ts, I think it would be necessary to make changes (10.4.8, E.2.2, and perhaps 6) because I believe the current spec semantics are clear that R2Ts are not included. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Julian Satran wrote: > It is in fact the Data-In + R2T - Julo > > > > "Ken Sandars" > Sent by: ips-admin@ietf.org > 27/01/2004 11:48 > > To > > cc > > Subject > [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands > > > > > > > Hi people, > > Does section 10.4.8 which clearly states that ExpDataSN is "the number > of Data-In (read) PDUs the target has sent for the command" hold for > bidirectional commands? > > i.e. It's not the number of Data-In and R2T PDUs sent for the command is > it? > > > Thanks again, > Ken Sandars > Elipsan UK > > > > _______________________________________________ > 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 From exim@www1.ietf.org Thu Jan 29 14:38:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11313 for ; Thu, 29 Jan 2004 14:38:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHz2-0007nH-Fl for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 14:37:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TJbmGg029953 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 14:37:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHz2-0007mu-6O for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 14:37:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11279 for ; Thu, 29 Jan 2004 14:37:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmHyz-0005pU-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 14:37:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmHyB-0005hX-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 14:36:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmHxM-0005Yp-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 14:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHxM-0007SG-2I; Thu, 29 Jan 2004 14:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHx6-0007QV-Lc for ips@optimus.ietf.org; Thu, 29 Jan 2004 14:35:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11094 for ; Thu, 29 Jan 2004 14:35:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmHx3-0005XC-00 for ips@ietf.org; Thu, 29 Jan 2004 14:35:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmHwA-0005P7-00 for ips@ietf.org; Thu, 29 Jan 2004 14:34:51 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AmHvT-0005EU-00 for ips@ietf.org; Thu, 29 Jan 2004 14:34:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E69E.A9B6322F" Date: Thu, 29 Jan 2004 11:32:42 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF29057179F@mail1irv.inside.istor.com> Thread-Topic: iSCSI Digest Clarification Thread-Index: AcPmnqm9M0hxpo/rSIaGdwtGIMmczg== X-Priority: 1 Priority: Urgent Importance: high From: "Ramesh Mangamuri" To: Subject: [Ips] iSCSI Digest Clarification Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,HTML_MESSAGE, PRIORITY_NO_NAME,X_PRIORITY_HIGH autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E69E.A9B6322F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 If initiator had negotiated for Header & Data Digest during discovery session, is there still an explicit need for it to negotiate these digests during Normal session? =20 Thanks, Ramesh Mangamuri ------_=_NextPart_001_01C3E69E.A9B6322F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

If initiator had negotiated for Header & Data = Digest during discovery session, is there still an explicit need for it to negotiate = these digests during Normal = session?

 

Thanks,

Ramesh = Mangamuri

=00 ------_=_NextPart_001_01C3E69E.A9B6322F-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 14:54:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12501 for ; Thu, 29 Jan 2004 14:54:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmIER-0000L4-Ut for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 14:53:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TJrhJQ001301 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 14:53:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmIER-0000Ku-QE for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 14:53:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12454 for ; Thu, 29 Jan 2004 14:53:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmIEO-00007n-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 14:53:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmIDR-00000O-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 14:52:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmICl-0007gE-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 14:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmICm-00008Y-JM; Thu, 29 Jan 2004 14:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmICL-00007V-OX for ips@optimus.ietf.org; Thu, 29 Jan 2004 14:51:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12303 for ; Thu, 29 Jan 2004 14:51:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmICI-0007eC-00 for ips@ietf.org; Thu, 29 Jan 2004 14:51:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmIBL-0007WI-00 for ips@ietf.org; Thu, 29 Jan 2004 14:50:32 -0500 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 1AmIAS-0007I8-00 for ips@ietf.org; Thu, 29 Jan 2004 14:49:36 -0500 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id CC67C1145D; Thu, 29 Jan 2004 11:48:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 74143EB2F; Thu, 29 Jan 2004 11:55:07 -0800 (PST) Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.6) id 22877-47707972; Thu, 29 Jan 2004 11:55:07 -0800 Received: from carlos.silverbacksystems.com (carlos.corp.silverbacksystems.com [10.0.16.197]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1C0A7356F4; Thu, 29 Jan 2004 11:55:07 -0800 (PST) Message-Id: <6.0.0.22.2.20040129114625.027efd90@pop.silverbacksystems.com> X-Sender: crimola@pop.silverbacksystems.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 29 Jan 2004 11:48:56 -0800 To: "Ramesh Mangamuri" , From: Carlos Rimola Subject: Re: [Ips] iSCSI Digest Clarification In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF29057179F@mail1irv.inside.ist or.com> References: <7D036BD3216A084DB1BD9D62BCEAF29057179F@mail1irv.inside.istor.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.23.0.3; VDF: 6.23.0.52; host: ns.silverbacksystems.com) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_20_30,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.60 At 11:32 AM 1/29/2004, Ramesh Mangamuri wrote:
Hi Folks,
 
If initiator had negotiated for Header & Data Digest during discovery session, is there still an explicit need for it to negotiate these digests during Normal session?
 
Thanks,
Ramesh Mangamuri


Yes - the Header and Data digests that were negotiated during the discovery session only apply to that session and not to sub-sequent sessions.  Moreover, if I am not mistaken, this are connection specific parameters so you must re-negotiate them per connection if you are using multiple connections.

Carlos Rimola
crimola@silverbacksystems.com
Member of Technical Staff
Silverback Systems
www.silverbacksystems.com
408-376-1293 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 17:50:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25499 for ; Thu, 29 Jan 2004 17:50:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKyj-0000RY-Gu for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 17:49:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TMnf85001646 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 17:49:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKyj-0000QT-56 for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 17:49:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25472 for ; Thu, 29 Jan 2004 17:49:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmKyg-0001ma-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 17:49:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmKxl-0001fH-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 17:48:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmKx8-0001Yv-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 17:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKx7-0000BM-3X; Thu, 29 Jan 2004 17:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKwl-0000AT-5E for ips@optimus.ietf.org; Thu, 29 Jan 2004 17:47:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25387 for ; Thu, 29 Jan 2004 17:47:35 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmKwi-0001Vr-00 for ips@ietf.org; Thu, 29 Jan 2004 17:47:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmKvn-0001Oc-00 for ips@ietf.org; Thu, 29 Jan 2004 17:46:40 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AmKuv-0001Gs-00 for ips@ietf.org; Thu, 29 Jan 2004 17:45:45 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 62BA640138; Thu, 29 Jan 2004 17:45:40 -0500 (EST) Date: Thu, 29 Jan 2004 14:45:30 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Mallikarjun C." Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands In-Reply-To: <401950D8.6060701@rose.hp.com> Message-ID: References: <401950D8.6060701@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Thu, 29 Jan 2004, Mallikarjun C. wrote: > Not sure why the initiator needs to be reported on the > total # of R2Ts in the final response....I presume > any mismatch in R2Ts is already factored into the status. > > _If_ we indeed want to include R2Ts, I think it would be > necessary to make changes (10.4.8, E.2.2, and perhaps 6) > because I believe the current spec semantics are clear > that R2Ts are not included. While I'll be honest that I don't understand _why_ R2Ts are factored into the DataSN space along with Data-In PDUs, I've understood they were comingled for over a year. I think it was about 16 months ago I asked about this (before draft 20), and Julian explained that they shared the same space. So I don't think it's supposed to be something new. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 17:51:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25566 for ; Thu, 29 Jan 2004 17:51:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKzn-0000VG-9v for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 17:50:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TMolr0001928 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 17:50:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKzn-0000V1-4q for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 17:50:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25545 for ; Thu, 29 Jan 2004 17:50:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmKzk-0001zR-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 17:50:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmKys-0001oE-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 17:49:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmKy3-0001gm-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 17:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKy5-0000JS-55; Thu, 29 Jan 2004 17:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmKxl-0000He-BV for ips@optimus.ietf.org; Thu, 29 Jan 2004 17:48:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25437 for ; Thu, 29 Jan 2004 17:48:37 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmKxi-0001ej-00 for ips@ietf.org; Thu, 29 Jan 2004 17:48:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmKwt-0001YT-00 for ips@ietf.org; Thu, 29 Jan 2004 17:47:48 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AmKw6-0001Qk-00 for ips@ietf.org; Thu, 29 Jan 2004 17:46:58 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id D27BC40138; Thu, 29 Jan 2004 17:46:58 -0500 (EST) Date: Thu, 29 Jan 2004 14:46:48 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Carlos Rimola Cc: Ramesh Mangamuri , ips@ietf.org Subject: Re: [Ips] iSCSI Digest Clarification In-Reply-To: <6.0.0.22.2.20040129114625.027efd90@pop.silverbacksystems.com> Message-ID: References: <7D036BD3216A084DB1BD9D62BCEAF29057179F@mail1irv.inside.istor.com> <6.0.0.22.2.20040129114625.027efd90@pop.silverbacksystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Thu, 29 Jan 2004, Carlos Rimola wrote: > At 11:32 AM 1/29/2004, Ramesh Mangamuri wrote: > Hi Folks, > > If initiator had negotiated for Header & Data Digest during > discovery session, is there still an explicit need for it to > negotiate these digests during Normal session? [snip] > Yes - the Header and Data digests that were negotiated during the > discovery session only apply to that session and not to sub-sequent > sessions. Moreover, if I am not mistaken, this are connection specific > parameters so you must re-negotiate them per connection if you are using > multiple connections. Yes, they and markers are per-connection. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 18:10:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27334 for ; Thu, 29 Jan 2004 18:10:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmLIF-0005qV-AD for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 18:09:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TN9pmW022464 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 18:09:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmLIF-0005qF-5m for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 18:09:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27230 for ; Thu, 29 Jan 2004 18:09:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmLIC-0004p7-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 18:09:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmLHG-0004eA-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 18:08:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmLGT-0004VW-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 18:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmLGU-0005Fc-Bz; Thu, 29 Jan 2004 18:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmLG7-00054L-Kt for ips@optimus.ietf.org; Thu, 29 Jan 2004 18:07:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26886 for ; Thu, 29 Jan 2004 18:07:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmLG4-0004R9-00 for ips@ietf.org; Thu, 29 Jan 2004 18:07:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmLF5-0004Hg-00 for ips@ietf.org; Thu, 29 Jan 2004 18:06:35 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AmLE7-00042g-00 for ips@ietf.org; Thu, 29 Jan 2004 18:05:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E6BC.34DE5D09" Date: Thu, 29 Jan 2004 15:04:11 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717A0@mail1irv.inside.istor.com> Thread-Topic: Max iSCSI Sessions supported Thread-Index: AcPmvDT0Aa9UtkhuTcaJniMWJZl+ag== X-Priority: 1 Priority: Urgent Importance: high From: "Ramesh Mangamuri" To: Subject: [Ips] Max iSCSI Sessions supported Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,HTML_MESSAGE, PRIORITY_NO_NAME,X_PRIORITY_HIGH autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E6BC.34DE5D09 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 I understand that there is possibility that there can be multiple connections in an iSCSI session. But, Can an iSCSI initiator have more than one active iSCSI session simultaneously with a given target.=20 =20 -Ramesh ------_=_NextPart_001_01C3E6BC.34DE5D09 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I understand that there is possibility that there can = be multiple connections in an iSCSI session. = But, Can an iSCSI initiator have more than one active = iSCSI session simultaneously with a given target. =

 

-Ramesh

=00 ------_=_NextPart_001_01C3E6BC.34DE5D09-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 19:21:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02538 for ; Thu, 29 Jan 2004 19:21:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMOm-0004oJ-2T for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 19:20:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U0KeDb018491 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 19:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMOl-0004oA-Tc for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 19:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02510 for ; Thu, 29 Jan 2004 19:20:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMOk-0000d5-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 19:20:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMNo-0000XY-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 19:19:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmMNC-0000SI-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 19:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMNB-0004fO-DN; Thu, 29 Jan 2004 19:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMMp-0004fA-OS for ips@optimus.ietf.org; Thu, 29 Jan 2004 19:18:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02487 for ; Thu, 29 Jan 2004 19:18:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMMo-0000Re-00 for ips@ietf.org; Thu, 29 Jan 2004 19:18:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMLq-0000LP-00 for ips@ietf.org; Thu, 29 Jan 2004 19:17:39 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AmMKw-0000GK-00 for ips@ietf.org; Thu, 29 Jan 2004 19:16:42 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id 312A11C009D7 for ; Thu, 29 Jan 2004 16:16:42 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 4FE287FFF for ; Thu, 29 Jan 2004 16:12:11 -0800 (PST) Message-ID: <4019A260.6050005@rose.hp.com> Date: Thu, 29 Jan 2004 16:16:32 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands References: <401950D8.6060701@rose.hp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry, I must have missed that thread. I wish you had suggested the clarification to be put into the spec. The spec/appendix is clearly saying something different (which I am fine with). -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com wrstuden@wasabisystems.com wrote: > On Thu, 29 Jan 2004, Mallikarjun C. wrote: > > >>Not sure why the initiator needs to be reported on the >>total # of R2Ts in the final response....I presume >>any mismatch in R2Ts is already factored into the status. >> >>_If_ we indeed want to include R2Ts, I think it would be >>necessary to make changes (10.4.8, E.2.2, and perhaps 6) >>because I believe the current spec semantics are clear >>that R2Ts are not included. > > > While I'll be honest that I don't understand _why_ R2Ts are factored into > the DataSN space along with Data-In PDUs, I've understood they were > comingled for over a year. I think it was about 16 months ago I asked > about this (before draft 20), and Julian explained that they shared the > same space. > > So I don't think it's supposed to be something new. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 20:24:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04509 for ; Thu, 29 Jan 2004 20:24:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNNs-0000iz-Ug for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 20:23:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U1Nm9Z002781 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 20:23:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNNs-0000im-Nm for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 20:23:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04488 for ; Thu, 29 Jan 2004 20:23:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNNq-00001F-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 20:23:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNMs-0007iN-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 20:22:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmNMB-0007b8-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 20:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNM9-0000bG-KM; Thu, 29 Jan 2004 20:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNM4-0000au-I9 for ips@optimus.ietf.org; Thu, 29 Jan 2004 20:21:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04454 for ; Thu, 29 Jan 2004 20:21:54 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNM2-0007ag-00 for ips@ietf.org; Thu, 29 Jan 2004 20:21:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNKy-0007UY-00 for ips@ietf.org; Thu, 29 Jan 2004 20:20:49 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AmNKV-0007O8-00 for ips@ietf.org; Thu, 29 Jan 2004 20:20:19 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 5C3C34014F; Thu, 29 Jan 2004 20:20:15 -0500 (EST) Date: Thu, 29 Jan 2004 17:20:05 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Ramesh Mangamuri Cc: ips@ietf.org Subject: Re: [Ips] Max iSCSI Sessions supported In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A0@mail1irv.inside.istor.com> Message-ID: References: <7D036BD3216A084DB1BD9D62BCEAF2905717A0@mail1irv.inside.istor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Thu, 29 Jan 2004, Ramesh Mangamuri wrote: > Folks, > > I understand that there is possibility that there can be multiple > connections in an iSCSI session. But, Can an iSCSI initiator have more > than one active iSCSI session simultaneously with a given target. Yes and no. Strictly speaking, no. Any attempt to open a second session with the target by a given initiator would trigger session reinstatement. This represents the fact that there can be only one I_T nexus. However since the identifier for an initiator is both the initiator name and the ISID, the same initiator name can be used on different sessions if they have different ISIDs. This situation, though, can be dangerous and should be avoided; the target would appear as two different SCSI devices to the initiator's OS. Most OSs won't deal well with that situation. For instance Microsoft Windows's auto-mounting of partitions could cause the partitions on the disk to be mounted twice. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 20:30:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04687 for ; Thu, 29 Jan 2004 20:30:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNTa-00014Q-P1 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 20:29:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U1Tgwt004108 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 20:29:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNTa-00014B-KX for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 20:29:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04660 for ; Thu, 29 Jan 2004 20:29:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNTY-0000g3-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 20:29:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNSd-0000aB-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 20:28:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmNRw-0000Uc-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 20:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNRx-0000vR-SK; Thu, 29 Jan 2004 20:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNRf-0000uj-JE for ips@optimus.ietf.org; Thu, 29 Jan 2004 20:27:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04608 for ; Thu, 29 Jan 2004 20:27:41 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNRd-0000TQ-00 for ips@ietf.org; Thu, 29 Jan 2004 20:27:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNQl-0000N5-00 for ips@ietf.org; Thu, 29 Jan 2004 20:26:48 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1AmNPz-0000H3-00 for ips@ietf.org; Thu, 29 Jan 2004 20:25:59 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id AFF142433D; Thu, 29 Jan 2004 18:25:59 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 93E21661; Thu, 29 Jan 2004 18:25:59 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Jan 2004 18:25:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Date: Thu, 29 Jan 2004 18:25:58 -0700 Message-ID: Thread-Topic: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Thread-Index: AcPmugfNen924IeNQAaCAI5VvlaeoQABzYqA To: , Cc: X-OriginalArrivalTime: 30 Jan 2004 01:25:59.0448 (UTC) FILETIME=[04320980:01C3E6D0] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I also don't think the current spec is clear and I think the combination = of the behavior described in 10.4.8 and that described in 3.2.2 is = broken for bidirectional commands. The reason for reporting ExpDataSN in = the SCSI Response is to allow the initiator to check that it received = all the Data-In PDUs associated with the command and to send a SNACK if = it didn't. For example, one could have the following in response to a bidirectional = command: DataSN PDU 0 1st Data-In 1 1st R2T 2 2nd R2T 3 2nd Data-In 4 3rd Data-In 5 4th Data-In 6 3rd R2T If the ExpDataSN to be reported in the SCSI Response was truly the = number of Data-In PDUs as 10.4.8 says, its value would be 4. Note that = the above is consistent with the text of 3.2.2.3 which says that DataSN = and R2TSN for bidirectional commands form one continuous = undifferentiated series but it is not consistent with the example in = B.3. The example shows a PDU with R2TSN =3D 0 followed by a PDU with = DataSN =3D 0. This is broken because the initiator could not compare the value = received in ExpDataSN to its copy of ExpDataSN to determine whether it = had gotten all the Data-In PDUs. If the behavior in 10.4.8 is = maintained, an initiator will have to keep a count of the Data-In PDUs = it has received for bidirectional commands in addition to keeping the = ExpDataSN value. The target would also have to keep two separate = counters during processing of bidirectional commands (both named = ExpDataSN by the draft) - one of how many Data-In PDUs it has sent so it = can put it in the Response and one of the value of ExpDataSN indicating = the DataSN to put in the next Data-In or R2T PDU it sends for the = command. There is no reason to define the protocol such that keeping two values = is necessary here. It appears that the reason to say that DataSN and = R2TSN form one sequence for bidirectional commands is to allow the = command to maintain one count for DataIn and R2T PDUs rather than having = two counters. If we were willing to forgo that optimization, then DataSN = and R2TSN should have been kept separate.=20 In any case, it is incorrect to have two variables for the same context = with the same name. One can correct the problem by changing 10.4.8 to say that for = bidirectional commands ExpDataSN is the number of DataIn and R2T PDUs = that were sent, then one can maintain one value. One should also correct = the example in B.3. One could also correct the problem by changing 3.2.2 so that DataSN was = kept separate from R2TSN in bidirectional commands. In some senses, this = would have been cleaner because it avoids having one variable with two = names but it would require more context per command and it is probably a = bigger change for existing implementations. The code in E.2.2 seems ambiguous - it just says if (expDataSN does not = match) but it doesn't define what is considered a match. Neither the = target code nor the initiator code in E.2 seems to address how the value = of ExpDataSN for response PDUs and the compare to response PDUs is = derived. Therefore it would be consistent with either choice. Regards, Pat -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of wrstuden@wasabisystems.com Sent: Thursday, January 29, 2004 2:46 PM To: Mallikarjun C. Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands On Thu, 29 Jan 2004, Mallikarjun C. wrote: > Not sure why the initiator needs to be reported on the > total # of R2Ts in the final response....I presume > any mismatch in R2Ts is already factored into the status. > > _If_ we indeed want to include R2Ts, I think it would be > necessary to make changes (10.4.8, E.2.2, and perhaps 6) > because I believe the current spec semantics are clear > that R2Ts are not included. While I'll be honest that I don't understand _why_ R2Ts are factored = into the DataSN space along with Data-In PDUs, I've understood they were comingled for over a year. I think it was about 16 months ago I asked about this (before draft 20), and Julian explained that they shared the same space. So I don't think it's supposed to be something new. Take care, 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 exim@www1.ietf.org Thu Jan 29 20:49:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05413 for ; Thu, 29 Jan 2004 20:49:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNm2-00033j-Bg for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 20:48:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U1mk82011753 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 20:48:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNm2-00033U-7n for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 20:48:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05401 for ; Thu, 29 Jan 2004 20:48:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNlz-0002vw-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 20:48:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNl4-0002px-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 20:47:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmNkK-0002j0-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 20:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNkL-0002wa-Qm; Thu, 29 Jan 2004 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNk8-0002vw-B6 for ips@optimus.ietf.org; Thu, 29 Jan 2004 20:46:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05368 for ; Thu, 29 Jan 2004 20:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNk6-0002hx-00 for ips@ietf.org; Thu, 29 Jan 2004 20:46:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNjF-0002bu-00 for ips@ietf.org; Thu, 29 Jan 2004 20:45:53 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AmNiZ-0002Sq-00 for ips@ietf.org; Thu, 29 Jan 2004 20:45:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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] Max iSCSI Sessions supported Date: Thu, 29 Jan 2004 17:43:46 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717A1@mail1irv.inside.istor.com> Thread-Topic: [Ips] Max iSCSI Sessions supported Thread-Index: AcPmzxjUloL1p9x2QOK11f5tt/9KMAAAonKQ X-Priority: 1 Priority: Urgent Importance: high From: "Ramesh Mangamuri" To: Cc: Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,PRIORITY_NO_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here are some questions again. 1) What if we have multi-pathing software installed on the Host OS(Initiator) ?=20 2) How can we generate different ISIDs from the same initiator.? Is this one configurable value? More later ..., Ramesh -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]=20 Sent: Thursday, January 29, 2004 5:20 PM To: Ramesh Mangamuri Cc: ips@ietf.org Subject: Re: [Ips] Max iSCSI Sessions supported On Thu, 29 Jan 2004, Ramesh Mangamuri wrote: > Folks, > > I understand that there is possibility that there can be multiple > connections in an iSCSI session. But, Can an iSCSI initiator have more > than one active iSCSI session simultaneously with a given target. Yes and no. Strictly speaking, no. Any attempt to open a second session with the target by a given initiator would trigger session reinstatement. This represents the fact that there can be only one I_T nexus. However since the identifier for an initiator is both the initiator name and the ISID, the same initiator name can be used on different sessions if they have different ISIDs. This situation, though, can be dangerous and should be avoided; the target would appear as two different SCSI devices to the initiator's OS. Most OSs won't deal well with that situation. For instance Microsoft Windows's auto-mounting of partitions could cause the partitions on the disk to be mounted twice. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 21:03:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05925 for ; Thu, 29 Jan 2004 21:03:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNzZ-000416-Gx for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 21:02:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U22jS4015434 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 21:02:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNzZ-00040r-BZ for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 21:02:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05909 for ; Thu, 29 Jan 2004 21:02:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNzW-0004aJ-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:02:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNyZ-0004TL-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:01:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmNxt-0004Np-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNxu-0003mx-QN; Thu, 29 Jan 2004 21:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNxd-0003lz-7l for ips@optimus.ietf.org; Thu, 29 Jan 2004 21:00:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05868 for ; Thu, 29 Jan 2004 21:00:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNxa-0004N9-00 for ips@ietf.org; Thu, 29 Jan 2004 21:00:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNwf-0004HB-00 for ips@ietf.org; Thu, 29 Jan 2004 20:59:46 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AmNvm-00044k-00; Thu, 29 Jan 2004 20:58:50 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0U1wK5B500722; Thu, 29 Jan 2004 20:58:20 -0500 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0U1wJQ2111304; Thu, 29 Jan 2004 18:58:20 -0700 In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A1@mail1irv.inside.istor.com> To: "Ramesh Mangamuri" Cc: ips@ietf.org, ips-admin@ietf.org, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: [Ips] Max iSCSI Sessions supported X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: John Hufferd Message-ID: Date: Thu, 29 Jan 2004 17:58:14 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/29/2004 18:58:19, Serialize complete at 01/29/2004 18:58:19 Content-Type: multipart/alternative; boundary="=_alternative 000ACFB788256E2B_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 000ACFB788256E2B_= Content-Type: text/plain; charset="US-ASCII" If you change the ISID, even with the same Initiator node name, it is a different initiator. You can make that work as if it is a single initiator with what we call a wedge driver, or what you are calling multipathing software. The ISIDs can have been given a number of ways to be specified, one of the ways is to use the OUI, that represents the Vendor ID, and then you may use your own technique to modify the rest of the bits in the ISID any way you wish, which makes the Total name (including the Node Name) unique within the world. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Ramesh Mangamuri" Sent by: ips-admin@ietf.org 01/29/2004 05:43 PM To cc Subject RE: [Ips] Max iSCSI Sessions supported Here are some questions again. 1) What if we have multi-pathing software installed on the Host OS(Initiator) ? 2) How can we generate different ISIDs from the same initiator.? Is this one configurable value? More later ..., Ramesh -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] Sent: Thursday, January 29, 2004 5:20 PM To: Ramesh Mangamuri Cc: ips@ietf.org Subject: Re: [Ips] Max iSCSI Sessions supported On Thu, 29 Jan 2004, Ramesh Mangamuri wrote: > Folks, > > I understand that there is possibility that there can be multiple > connections in an iSCSI session. But, Can an iSCSI initiator have more > than one active iSCSI session simultaneously with a given target. Yes and no. Strictly speaking, no. Any attempt to open a second session with the target by a given initiator would trigger session reinstatement. This represents the fact that there can be only one I_T nexus. However since the identifier for an initiator is both the initiator name and the ISID, the same initiator name can be used on different sessions if they have different ISIDs. This situation, though, can be dangerous and should be avoided; the target would appear as two different SCSI devices to the initiator's OS. Most OSs won't deal well with that situation. For instance Microsoft Windows's auto-mounting of partitions could cause the partitions on the disk to be mounted twice. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 000ACFB788256E2B_= Content-Type: text/html; charset="US-ASCII"
If you change the ISID, even with the same Initiator node name, it is a different initiator.  You can make that work as if it is a single initiator with what we call a wedge driver, or what you are calling multipathing software.  

The ISIDs can have been given a number of ways to be specified, one of the ways is to use the OUI, that represents the Vendor ID, and then you may use your own technique to modify the rest of the bits in the ISID any way you wish, which makes the Total name (including the Node Name) unique within the world.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


"Ramesh Mangamuri" <rmangamuri@istor.com>
Sent by: ips-admin@ietf.org

01/29/2004 05:43 PM

To
<wrstuden@wasabisystems.com>
cc
<ips@ietf.org>
Subject
RE: [Ips] Max iSCSI Sessions supported





Here are some questions again.

1) What if we have multi-pathing software installed on the Host
OS(Initiator) ?
2) How can we generate different ISIDs from the same initiator.? Is this
one configurable value?

More later ...,
Ramesh

-----Original Message-----
From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]
Sent: Thursday, January 29, 2004 5:20 PM
To: Ramesh Mangamuri
Cc: ips@ietf.org
Subject: Re: [Ips] Max iSCSI Sessions supported

On Thu, 29 Jan 2004, Ramesh Mangamuri wrote:

> Folks,
>
> I understand that there is possibility that there can be multiple
> connections in an iSCSI session. But, Can an iSCSI initiator have more
> than one active iSCSI session simultaneously with a given target.

Yes and no.

Strictly speaking, no. Any attempt to open a second session with the
target by a given initiator would trigger session reinstatement. This
represents the fact that there can be only one I_T nexus.

However since the identifier for an initiator is both the initiator name
and the ISID, the same initiator name can be used on different sessions
if
they have different ISIDs. This situation, though, can be dangerous and
should be avoided; the target would appear as two different SCSI devices
to the initiator's OS. Most OSs won't deal well with that situation. For
instance Microsoft Windows's auto-mounting of partitions could cause the
partitions on the disk to be mounted twice.

Take care,

Bill

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 000ACFB788256E2B_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 21:04:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05994 for ; Thu, 29 Jan 2004 21:04:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmO0a-000452-UB for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 21:03:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U23m8n015678 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 21:03:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmO0a-00044n-P3 for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 21:03:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05965 for ; Thu, 29 Jan 2004 21:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmO0Y-0004i7-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:03:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNzd-0004bD-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:02:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmNyq-0004Tx-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNyr-0003uK-Ug; Thu, 29 Jan 2004 21:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNyb-0003td-Bz for ips@optimus.ietf.org; Thu, 29 Jan 2004 21:01:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05892 for ; Thu, 29 Jan 2004 21:01:42 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNyY-0004T7-00 for ips@ietf.org; Thu, 29 Jan 2004 21:01:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNxc-0004Ne-00 for ips@ietf.org; Thu, 29 Jan 2004 21:00:45 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AmNx5-0004I4-00 for ips@ietf.org; Thu, 29 Jan 2004 21:00:11 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 5001440146; Thu, 29 Jan 2004 21:00:12 -0500 (EST) Date: Thu, 29 Jan 2004 18:00:01 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Ramesh Mangamuri Cc: ips@ietf.org Subject: RE: [Ips] Max iSCSI Sessions supported In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A1@mail1irv.inside.istor.com> Message-ID: References: <7D036BD3216A084DB1BD9D62BCEAF2905717A1@mail1irv.inside.istor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Thu, 29 Jan 2004, Ramesh Mangamuri wrote: > Here are some questions again. > > 1) What if we have multi-pathing software installed on the Host > OS(Initiator) ? What does that have to do with multiple sessions? > 2) How can we generate different ISIDs from the same initiator.? Is this > one configurable value? Since the ISID is part of what identifies the initiator in iSCSI, your question doesn't make sense; if you change the ISID, you have a different initiator. What do you think an initiator is? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 21:06:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06101 for ; Thu, 29 Jan 2004 21:06:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmO2T-0004IU-18 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 21:05:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U25j0N016512 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 21:05:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmO2S-0004IF-SD for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 21:05:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06075 for ; Thu, 29 Jan 2004 21:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmO2Q-0004w5-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:05:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmO1X-0004pq-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:04:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmO0k-0004jk-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:03:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmO0m-00045q-KH; Thu, 29 Jan 2004 21:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmO0Z-00044i-8Y for ips@optimus.ietf.org; Thu, 29 Jan 2004 21:03:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05962 for ; Thu, 29 Jan 2004 21:03:44 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmO0W-0004hu-00 for ips@ietf.org; Thu, 29 Jan 2004 21:03:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNzc-0004b5-00 for ips@ietf.org; Thu, 29 Jan 2004 21:02:49 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AmNym-0004Tv-00 for ips@ietf.org; Thu, 29 Jan 2004 21:01:56 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 7FA0840146; Thu, 29 Jan 2004 21:01:57 -0500 (EST) Date: Thu, 29 Jan 2004 18:01:47 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Mallikarjun C." Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands In-Reply-To: <4019A260.6050005@rose.hp.com> Message-ID: References: <401950D8.6060701@rose.hp.com> <4019A260.6050005@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Thu, 29 Jan 2004, Mallikarjun C. wrote: > Sorry, I must have missed that thread. > > I wish you had suggested the clarification > to be put into the spec. The spec/appendix > is clearly saying something different (which > I am fine with). Sorry, I haven't paid much attention to BiDi commands, and I expected the spec was clearer. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 21:19:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06613 for ; Thu, 29 Jan 2004 21:19:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmOFA-0005RQ-6s for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 21:18:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U2Iqpe020910 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 21:18:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmOFA-0005RB-1K for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 21:18:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06564 for ; Thu, 29 Jan 2004 21:18:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmOF7-0006UX-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:18:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmOE8-0006NI-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:17:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmODL-0006G5-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 21:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmODN-0005Il-Eh; Thu, 29 Jan 2004 21:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmOD6-0005I4-QQ for ips@optimus.ietf.org; Thu, 29 Jan 2004 21:16:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06461 for ; Thu, 29 Jan 2004 21:16:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmOD4-0006Ev-00 for ips@ietf.org; Thu, 29 Jan 2004 21:16:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmOC5-00068I-00 for ips@ietf.org; Thu, 29 Jan 2004 21:15:43 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AmOB7-0005wS-00; Thu, 29 Jan 2004 21:14:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E6D6.9C165843" Subject: RE: [Ips] Max iSCSI Sessions supported Date: Thu, 29 Jan 2004 18:13:11 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717A2@mail1irv.inside.istor.com> Thread-Topic: [Ips] Max iSCSI Sessions supported Thread-Index: AcPm1H1OKacbCVIXRZe3e9VEM7zZNAAAKQQA From: "Ramesh Mangamuri" To: "John Hufferd" Cc: , , Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E6D6.9C165843 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on this I understandd that if you use two different vendor HBAs on a single Host(initiator), their ISIDs also would be different. For example if I use two HBAs from the same vendor on a single host, will they have the same ISID, or different ISIDs??? =20 Also I wasn't clear that whether this ISID is modifiable from an end user perpective, or it is driven by iSCSI Drivers???? -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com]=20 Sent: Thursday, January 29, 2004 5:58 PM To: Ramesh Mangamuri Cc: ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com Subject: RE: [Ips] Max iSCSI Sessions supported =20 If you change the ISID, even with the same Initiator node name, it is a different initiator. You can make that work as if it is a single initiator with what we call a wedge driver, or what you are calling multipathing software. =20 The ISIDs can have been given a number of ways to be specified, one of the ways is to use the OUI, that represents the Vendor ID, and then you may use your own technique to modify the rest of the bits in the ISID any way you wish, which makes the Total name (including the Node Name) unique within the world.=20 . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com=20 "Ramesh Mangamuri" =20 Sent by: ips-admin@ietf.org=20 01/29/2004 05:43 PM=20 To =20 cc =20 Subject RE: [Ips] Max iSCSI Sessions supported =20 =20 =20 Here are some questions again. 1) What if we have multi-pathing software installed on the Host OS(Initiator) ?=20 2) How can we generate different ISIDs from the same initiator.? Is this one configurable value? More later ..., Ramesh -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]=20 Sent: Thursday, January 29, 2004 5:20 PM To: Ramesh Mangamuri Cc: ips@ietf.org Subject: Re: [Ips] Max iSCSI Sessions supported On Thu, 29 Jan 2004, Ramesh Mangamuri wrote: > Folks, > > I understand that there is possibility that there can be multiple > connections in an iSCSI session. But, Can an iSCSI initiator have more > than one active iSCSI session simultaneously with a given target. Yes and no. Strictly speaking, no. Any attempt to open a second session with the target by a given initiator would trigger session reinstatement. This represents the fact that there can be only one I_T nexus. However since the identifier for an initiator is both the initiator name and the ISID, the same initiator name can be used on different sessions if they have different ISIDs. This situation, though, can be dangerous and should be avoided; the target would appear as two different SCSI devices to the initiator's OS. Most OSs won't deal well with that situation. For instance Microsoft Windows's auto-mounting of partitions could cause the partitions on the disk to be mounted twice. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C3E6D6.9C165843 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on this I understandd that if you use two different vendor HBAs on = a single Host(initiator), their ISIDs also would be different.

For example if I use two HBAs from the same vendor on a single host, will = they have the same ISID, or different ISIDs???

 

Also I wasn’t clear that = whether this ISID is modifiable from an end user perpective, or it is driven by iSCSI = Drivers????

-----Original = Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Thursday, January 29, 2004 = 5:58 PM
To: Ramesh Mangamuri
Cc: ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com
Subject: RE: [Ips] Max = iSCSI Sessions supported

 


If you change the ISID, even with the same = Initiator node name, it is a different initiator.  You can make that work as = if it is a single initiator with what we call a wedge driver, or what you are = calling multipathing software.  

The ISIDs can have been given a number of ways to be specified, one of the = ways is to use the OUI, that represents the Vendor ID, and then you may use your = own technique to modify the rest of the bits in the ISID any way you wish, = which makes the Total name (including the Node Name) unique within the = world.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose = CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com

"Ramesh = Mangamuri" <rmangamuri@istor.com>
Sent by: ips-admin@ietf.org

01/29/2004= = 05:43 PM =

To

<wrstuden@wasabisystems.com>

cc

<ips@ietf.org> =

Subject

RE: [Ips] Max iSCSI Sessions = supported

 

 

 




Here are some questions again.

1) What if we have multi-pathing software installed on the Host
OS(Initiator) ?
2) How can we generate different ISIDs = from the same initiator.? Is this
one configurable value?

More later ...,
Ramesh

-----Original = Message-----
From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]
Sent: Thursday, January 29, = 2004 = 5:20 PM
To: Ramesh Mangamuri
Cc: ips@ietf.org
Subject: Re: [Ips] Max iSCSI Sessions = supported

On Thu, = 29 Jan = 2004, Ramesh = Mangamuri wrote:

> Folks,
>
> I understand that there is = possibility that there can be multiple
> connections in an iSCSI session. = But, Can an iSCSI initiator have more
> than one active iSCSI session = simultaneously with a given target.

Yes and no.

Strictly speaking, no. Any attempt to = open a second session with the
target by a given initiator would trigger = session reinstatement. This
represents the fact that there can be = only one I_T nexus.

However since the identifier for an = initiator is both the initiator name
and the ISID, the same initiator name can = be used on different sessions
if
they have different ISIDs. This = situation, though, can be dangerous and
should be avoided; the target would = appear as two different SCSI devices
to the initiator's OS. Most = OSs<= tt> won't = deal well with that situation. For
instance Microsoft Windows's = auto-mounting of partitions could cause the
partitions on the disk to be mounted = twice.

Take care,

Bill

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

=00 ------_=_NextPart_001_01C3E6D6.9C165843-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Jan 29 23:57:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12386 for ; Thu, 29 Jan 2004 23:57:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmQi7-00088C-03 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 23:56:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U4usuY031257 for ips-archive@odin.ietf.org; Thu, 29 Jan 2004 23:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmQi6-000884-PF for ips-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 23:56:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12318 for ; Thu, 29 Jan 2004 23:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmQi4-0002DM-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 23:56:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmQhA-00024R-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 23:55:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmQgM-0001wX-00 for ips-web-archive@ietf.org; Thu, 29 Jan 2004 23:55:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmQgI-0007wV-As; Thu, 29 Jan 2004 23:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmQfX-0007v5-6R for ips@optimus.ietf.org; Thu, 29 Jan 2004 23:54:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12114 for ; Thu, 29 Jan 2004 23:54:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmQfU-0001mf-00 for ips@ietf.org; Thu, 29 Jan 2004 23:54:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmQeZ-0001d1-00 for ips@ietf.org; Thu, 29 Jan 2004 23:53:16 -0500 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1AmQdm-0001O8-00 for ips@ietf.org; Thu, 29 Jan 2004 23:52:26 -0500 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Jan 2004 21:51:52 -0700 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Thu, 29 Jan 2004 21:51:51 -0700 Received: from SNEXCH01.mcdata.com ([172.19.161.12]) by MC4EXCH03.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Jan 2004 21:51:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] Finding iSNS using SLP Date: Thu, 29 Jan 2004 20:51:49 -0800 Message-ID: <501EA67E9359C645A10C42EB5B52480DAD0F8F@SNEXCH01.mcdata.com> Thread-Topic: [Ips] Finding iSNS using SLP Thread-Index: AcPmHN4VtKy33GZ2TFSmVggd1LmUQAAzexOg From: "Joshua Tseng" To: Cc: X-OriginalArrivalTime: 30 Jan 2004 04:51:51.0201 (UTC) FILETIME=[C669F910:01C3E6EC] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Bill, See below >=20 > I have some more questions about using SLP to find iSNS servers. >=20 > 1) How do I tell if a given iSNS server URL is using UDP or TCP? iSNS > supports both, but doesn't expose that in the URL. The SLP draft notes > transport as an attribute for iSCSI targets, but not for SMS servers > (of which iSNS is a subset). This is a good point, and should be a comment against the iSCSI-SLP draft. I would request that the author include transport as an attribute in the sms template, just as it is in the iSCSI template. Furthermore, the first sentence of the second-to-last paragraph should read: A storage management server's URL contains the domain name or IP address and TCP or UDP port number. (add "or UDP" after TCP) >=20 > 2) iSNS heartbeat messages have the concept of server priority (primary, > secondary, etc.). The SLP attributes (for SMS servers) don't support this, > just if the server's iSNS or something else. I think it would be useful > for server priority to be reflected in the SLP bindings if possible. I would think this can be logically handled by only having the primary active iSNS server broadcast its service advertisements. Backup servers that are passively standing by should not advertise their service unless they detect failure of the primary iSNS server. The failed server's service advertisement will stop when the service lifetime eventually expires. Thanks, Josh Tseng >=20 > Thoughts? >=20 > Take care, >=20 > Bill >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent=20 responsible for delivering the message to the intended recipient, you are hereby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY=20 PROHIBITED. Anyone who receives confidential and privileged information in error should= =20 notify us immediately by telephone and mail the original message to us at= the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions=20 apply to that information. (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 01:27:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15311 for ; Fri, 30 Jan 2004 01:27:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmS7E-0005zr-G9 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 01:26:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U6Quh1023045 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 01:26:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmS7E-0005zc-9y for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 01:26:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15303 for ; Fri, 30 Jan 2004 01:26:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmS7B-0004oT-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 01:26:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmS6D-0004iE-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 01:25:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmS5R-0004cN-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 01:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmS5P-0005cB-G1; Fri, 30 Jan 2004 01:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmS4P-0005W7-2g for ips@optimus.ietf.org; Fri, 30 Jan 2004 01:24:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15226 for ; Fri, 30 Jan 2004 01:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmS4L-0004VF-00 for ips@ietf.org; Fri, 30 Jan 2004 01:23:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmS3P-0004Og-00 for ips@ietf.org; Fri, 30 Jan 2004 01:23:00 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1AmS2k-0004DA-00; Fri, 30 Jan 2004 01:22:18 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0U6Lnk2665578; Fri, 30 Jan 2004 01:21:49 -0500 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0U6LlQ2123388; Thu, 29 Jan 2004 23:21:48 -0700 In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A2@mail1irv.inside.istor.com> To: "Ramesh Mangamuri" Cc: ips@ietf.org, ips-admin@ietf.org, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: [Ips] Max iSCSI Sessions supported X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: John Hufferd Message-ID: Date: Thu, 29 Jan 2004 22:21:41 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 01/29/2004 23:21:48, Serialize complete at 01/29/2004 23:21:48 Content-Type: multipart/alternative; boundary="=_alternative 0022EDED88256E2B_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 0022EDED88256E2B_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlIElTSUQgaGFzIGJpdHMgcmVzZXJ2ZWQgZm9yIHRoZSB2ZW5kb3IgdG8gbWFrZSBlYWNoIG9m IHRoZWlyIEhCQXMgDQp1bmlxdWUuICBBbGwgSW5pdGlhdG9ycyBuYW1lcyBoYXZlIGEgTm9kZSBO YW1lIGFuZCBhIHVuaXF1ZSBJU0lEcywgd2l0aGluIA0KdGhhdCBOT0RFLiBGdXJ0aGVyIGFsbCBJ bml0aWF0b3JzIHdpdGhpbiBhbiBJbml0aWF0b3IgTm9kZSwgc2hvdWxkIGhhdmUgDQp0aGUgc2Ft ZSBOT0RFIE5hbWUuICBUaGUgZm9ybWF0IG9mIHRoZSBJU0lEIHBlcm1pdHMgYSBzdHJhaWdodCBm b3J3YXJkIA0KaW1wbGVtZW50YXRpb24gdGhhdCBlbnN1cmVzIHRoYXQgZWFjaCBJU0lEcyBpcyB1 bmlxdWUgd2l0aGluIGEgbm9kZS4gIEFsbCANCnRoaXMgaXMgaW4gdGhlIHNwZWNpZmljYXRpb24u ICBSZWZlciB0byAxMC4xMi41LCBhbmQgZm9ybWF0cyAwMGIgYW5kIDAxYi4gDQpBbmQgeWVzIHRo ZSBzcGVjaWZpY2F0aW9uIHN0YXRlcyB0aGF0IHRoZSBub2RlIG5hbWUgbXVzdCBiZSBhZG1pbiAN CmNvbmZpZ3VyYWJsZSwgYW5kIHRoZSBJU0lEIG11c3QgYWxzbyBiZSBjb25maWd1cmFibGUgZm9y IG11bHRpcGxlIEhCQXMgDQooc2VlIDkuMS4yKS4gIFRoZXJlIGlzIGFsc28gaW1wb3J0YW50IGlu Zm9ybWF0aW9uIGluIHNlY3Rpb24gMy40LjMuIA0KLg0KLg0KSm9obiBMLiBIdWZmZXJkDQpTZW5p b3IgVGVjaG5pY2FsIFN0YWZmIE1lbWJlciAoU1RTTSkNCklCTS9TeXN0ZW0gR3JvdXAsIFNhbiBK b3NlIENBDQpNYWluIE9mZmljZTogKDQwOCkgMjU2LTA0MDMsIFRpZTogMjc2LTA0MDMsIGVGYXg6 ICg0MDgpIDkwNC00Njg4DQpBbHQgT2ZmaWNlOiAoNDA4KSA5OTctNjEzNiwgQ2VsbDogKDQwOCkg NDk5LTk3MDINCkludGVybmV0IEFkZHJlc3M6IGh1ZmZlcmRAdXMuaWJtLmNvbQ0KDQoNCg0KIlJh bWVzaCBNYW5nYW11cmkiIDxybWFuZ2FtdXJpQGlzdG9yLmNvbT4gDQowMS8yOS8yMDA0IDA2OjEz IFBNDQoNClRvDQpKb2huIEh1ZmZlcmQvU2FuIEpvc2UvSUJNQElCTVVTDQpjYw0KPGlwc0BpZXRm Lm9yZz4sIDxpcHMtYWRtaW5AaWV0Zi5vcmc+LCA8d3JzdHVkZW5Ad2FzYWJpc3lzdGVtcy5jb20+ DQpTdWJqZWN0DQpSRTogW0lwc10gTWF4IGlTQ1NJIFNlc3Npb25zIHN1cHBvcnRlZA0KDQoNCg0K DQoNCg0KQmFzZWQgb24gdGhpcyBJIHVuZGVyc3RhbmRkIHRoYXQgaWYgeW91IHVzZSB0d28gZGlm ZmVyZW50IHZlbmRvciBIQkFzIG9uIGEgDQpzaW5nbGUgSG9zdChpbml0aWF0b3IpLCB0aGVpciBJ U0lEcyBhbHNvIHdvdWxkIGJlIGRpZmZlcmVudC4NCkZvciBleGFtcGxlIGlmIEkgdXNlIHR3byBI QkFzIGZyb20gdGhlIHNhbWUgdmVuZG9yIG9uIGEgc2luZ2xlIGhvc3QsIHdpbGwgDQp0aGV5IGhh dmUgdGhlIHNhbWUgSVNJRCwgb3IgZGlmZmVyZW50IElTSURzPz8/DQogDQpBbHNvIEkgd2FzbuKA mXQgY2xlYXIgdGhhdCB3aGV0aGVyIHRoaXMgSVNJRCBpcyBtb2RpZmlhYmxlIGZyb20gYW4gZW5k IHVzZXIgDQpwZXJwZWN0aXZlLCBvciBpdCBpcyBkcml2ZW4gYnkgaVNDU0kgRHJpdmVycz8/Pz8N Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIEh1ZmZlcmQgW21haWx0bzpo dWZmZXJkQHVzLmlibS5jb21dIA0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjksIDIwMDQgNTo1 OCBQTQ0KVG86IFJhbWVzaCBNYW5nYW11cmkNCkNjOiBpcHNAaWV0Zi5vcmc7IGlwcy1hZG1pbkBp ZXRmLm9yZzsgd3JzdHVkZW5Ad2FzYWJpc3lzdGVtcy5jb20NClN1YmplY3Q6IFJFOiBbSXBzXSBN YXggaVNDU0kgU2Vzc2lvbnMgc3VwcG9ydGVkDQogDQoNCklmIHlvdSBjaGFuZ2UgdGhlIElTSUQs IGV2ZW4gd2l0aCB0aGUgc2FtZSBJbml0aWF0b3Igbm9kZSBuYW1lLCBpdCBpcyBhIA0KZGlmZmVy ZW50IGluaXRpYXRvci4gIFlvdSBjYW4gbWFrZSB0aGF0IHdvcmsgYXMgaWYgaXQgaXMgYSBzaW5n bGUgDQppbml0aWF0b3Igd2l0aCB3aGF0IHdlIGNhbGwgYSB3ZWRnZSBkcml2ZXIsIG9yIHdoYXQg eW91IGFyZSBjYWxsaW5nIA0KbXVsdGlwYXRoaW5nIHNvZnR3YXJlLiAgIA0KDQpUaGUgSVNJRHMg Y2FuIGhhdmUgYmVlbiBnaXZlbiBhIG51bWJlciBvZiB3YXlzIHRvIGJlIHNwZWNpZmllZCwgb25l IG9mIHRoZSANCndheXMgaXMgdG8gdXNlIHRoZSBPVUksIHRoYXQgcmVwcmVzZW50cyB0aGUgVmVu ZG9yIElELCBhbmQgdGhlbiB5b3UgbWF5IA0KdXNlIHlvdXIgb3duIHRlY2huaXF1ZSB0byBtb2Rp ZnkgdGhlIHJlc3Qgb2YgdGhlIGJpdHMgaW4gdGhlIElTSUQgYW55IHdheSANCnlvdSB3aXNoLCB3 aGljaCBtYWtlcyB0aGUgVG90YWwgbmFtZSAoaW5jbHVkaW5nIHRoZSBOb2RlIE5hbWUpIHVuaXF1 ZSANCndpdGhpbiB0aGUgd29ybGQuIA0KLg0KLg0KSm9obiBMLiBIdWZmZXJkDQpTZW5pb3IgVGVj aG5pY2FsIFN0YWZmIE1lbWJlciAoU1RTTSkNCklCTS9TeXN0ZW0gR3JvdXAsIFNhbiBKb3NlIENB DQpNYWluIE9mZmljZTogKDQwOCkgMjU2LTA0MDMsIFRpZTogMjc2LTA0MDMsIGVGYXg6ICg0MDgp IDkwNC00Njg4DQpBbHQgT2ZmaWNlOiAoNDA4KSA5OTctNjEzNiwgQ2VsbDogKDQwOCkgNDk5LTk3 MDINCkludGVybmV0IEFkZHJlc3M6IGh1ZmZlcmRAdXMuaWJtLmNvbSANCg0KDQoiUmFtZXNoIE1h bmdhbXVyaSIgPHJtYW5nYW11cmlAaXN0b3IuY29tPiANClNlbnQgYnk6IGlwcy1hZG1pbkBpZXRm Lm9yZyANCjAxLzI5LzIwMDQgMDU6NDMgUE0gDQoNCg0KVG8NCjx3cnN0dWRlbkB3YXNhYmlzeXN0 ZW1zLmNvbT4gDQpjYw0KPGlwc0BpZXRmLm9yZz4gDQpTdWJqZWN0DQpSRTogW0lwc10gTWF4IGlT Q1NJIFNlc3Npb25zIHN1cHBvcnRlZA0KIA0KDQoNCiANCiANCg0KDQoNCg0KSGVyZSBhcmUgc29t ZSBxdWVzdGlvbnMgYWdhaW4uDQoNCjEpIFdoYXQgaWYgd2UgaGF2ZSBtdWx0aS1wYXRoaW5nIHNv ZnR3YXJlIGluc3RhbGxlZCBvbiB0aGUgSG9zdA0KT1MoSW5pdGlhdG9yKSA/IA0KMikgSG93IGNh biB3ZSBnZW5lcmF0ZSBkaWZmZXJlbnQgSVNJRHMgZnJvbSB0aGUgc2FtZSBpbml0aWF0b3IuPyBJ cyB0aGlzDQpvbmUgY29uZmlndXJhYmxlIHZhbHVlPw0KDQpNb3JlIGxhdGVyIC4uLiwNClJhbWVz aA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogd3JzdHVkZW5Ad2FzYWJpc3lz dGVtcy5jb20gW21haWx0bzp3cnN0dWRlbkB3YXNhYmlzeXN0ZW1zLmNvbV0gDQpTZW50OiBUaHVy c2RheSwgSmFudWFyeSAyOSwgMjAwNCA1OjIwIFBNDQpUbzogUmFtZXNoIE1hbmdhbXVyaQ0KQ2M6 IGlwc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJcHNdIE1heCBpU0NTSSBTZXNzaW9ucyBzdXBw b3J0ZWQNCg0KT24gVGh1LCAyOSBKYW4gMjAwNCwgUmFtZXNoIE1hbmdhbXVyaSB3cm90ZToNCg0K PiBGb2xrcywNCj4NCj4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgaXMgcG9zc2liaWxpdHkgdGhh dCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUNCj4gY29ubmVjdGlvbnMgaW4gYW4gaVNDU0kgc2Vzc2lv bi4gQnV0LCBDYW4gYW4gaVNDU0kgaW5pdGlhdG9yIGhhdmUgbW9yZQ0KPiB0aGFuIG9uZSBhY3Rp dmUgaVNDU0kgc2Vzc2lvbiBzaW11bHRhbmVvdXNseSB3aXRoIGEgZ2l2ZW4gdGFyZ2V0Lg0KDQpZ ZXMgYW5kIG5vLg0KDQpTdHJpY3RseSBzcGVha2luZywgbm8uIEFueSBhdHRlbXB0IHRvIG9wZW4g YSBzZWNvbmQgc2Vzc2lvbiB3aXRoIHRoZQ0KdGFyZ2V0IGJ5IGEgZ2l2ZW4gaW5pdGlhdG9yIHdv dWxkIHRyaWdnZXIgc2Vzc2lvbiByZWluc3RhdGVtZW50LiBUaGlzDQpyZXByZXNlbnRzIHRoZSBm YWN0IHRoYXQgdGhlcmUgY2FuIGJlIG9ubHkgb25lIElfVCBuZXh1cy4NCg0KSG93ZXZlciBzaW5j ZSB0aGUgaWRlbnRpZmllciBmb3IgYW4gaW5pdGlhdG9yIGlzIGJvdGggdGhlIGluaXRpYXRvciBu YW1lDQphbmQgdGhlIElTSUQsIHRoZSBzYW1lIGluaXRpYXRvciBuYW1lIGNhbiBiZSB1c2VkIG9u IGRpZmZlcmVudCBzZXNzaW9ucw0KaWYNCnRoZXkgaGF2ZSBkaWZmZXJlbnQgSVNJRHMuIFRoaXMg c2l0dWF0aW9uLCB0aG91Z2gsIGNhbiBiZSBkYW5nZXJvdXMgYW5kDQpzaG91bGQgYmUgYXZvaWRl ZDsgdGhlIHRhcmdldCB3b3VsZCBhcHBlYXIgYXMgdHdvIGRpZmZlcmVudCBTQ1NJIGRldmljZXMN CnRvIHRoZSBpbml0aWF0b3IncyBPUy4gTW9zdCBPU3Mgd29uJ3QgZGVhbCB3ZWxsIHdpdGggdGhh dCBzaXR1YXRpb24uIEZvcg0KaW5zdGFuY2UgTWljcm9zb2Z0IFdpbmRvd3MncyBhdXRvLW1vdW50 aW5nIG9mIHBhcnRpdGlvbnMgY291bGQgY2F1c2UgdGhlDQpwYXJ0aXRpb25zIG9uIHRoZSBkaXNr IHRvIGJlIG1vdW50ZWQgdHdpY2UuDQoNClRha2UgY2FyZSwNCg0KQmlsbA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSXBzIG1haWxpbmcgbGlzdA0K SXBzQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHMN Cg0K --=_alternative 0022EDED88256E2B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBJU0lEIGhhcyBiaXRzIHJl c2VydmVkIGZvciB0aGUgdmVuZG9yDQp0byBtYWtlIGVhY2ggb2YgdGhlaXIgSEJBcyB1bmlxdWUu ICZuYnNwO0FsbCBJbml0aWF0b3JzIG5hbWVzIGhhdmUgYSBOb2RlDQpOYW1lIGFuZCBhIHVuaXF1 ZSBJU0lEcywgd2l0aGluIHRoYXQgTk9ERS4gRnVydGhlciBhbGwgSW5pdGlhdG9ycyB3aXRoaW4N CmFuIEluaXRpYXRvciBOb2RlLCBzaG91bGQgaGF2ZSB0aGUgc2FtZSBOT0RFIE5hbWUuICZuYnNw O1RoZSBmb3JtYXQgb2YNCnRoZSBJU0lEIHBlcm1pdHMgYSBzdHJhaWdodCBmb3J3YXJkIGltcGxl bWVudGF0aW9uIHRoYXQgZW5zdXJlcyB0aGF0IGVhY2gNCklTSURzIGlzIHVuaXF1ZSB3aXRoaW4g YSBub2RlLiAmbmJzcDtBbGwgdGhpcyBpcyBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NCiZuYnNwO1Jl ZmVyIHRvIDEwLjEyLjUsIGFuZCBmb3JtYXRzIDAwYiBhbmQgMDFiLiAmbmJzcDtBbmQgeWVzIHRo ZSBzcGVjaWZpY2F0aW9uDQpzdGF0ZXMgdGhhdCB0aGUgbm9kZSBuYW1lIG11c3QgYmUgYWRtaW4g Y29uZmlndXJhYmxlLCBhbmQgdGhlIElTSUQgbXVzdA0KYWxzbyBiZSBjb25maWd1cmFibGUgZm9y IG11bHRpcGxlIEhCQXMgKHNlZSA5LjEuMikuICZuYnNwO1RoZXJlIGlzIGFsc28NCmltcG9ydGFu dCBpbmZvcm1hdGlvbiBpbiBzZWN0aW9uIDMuNC4zLiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi48YnI+DQouPGJyPg0KSm9obiBMLiBIdWZmZXJkPGJy Pg0KU2VuaW9yIFRlY2huaWNhbCBTdGFmZiBNZW1iZXIgKFNUU00pPGJyPg0KSUJNL1N5c3RlbSBH cm91cCwgU2FuIEpvc2UgQ0E8YnI+DQpNYWluIE9mZmljZTogKDQwOCkgMjU2LTA0MDMsIFRpZTog Mjc2LTA0MDMsIGVGYXg6ICg0MDgpIDkwNC00Njg4PGJyPg0KQWx0IE9mZmljZTogKDQwOCkgOTk3 LTYxMzYsIENlbGw6ICg0MDgpIDQ5OS05NzAyPGJyPg0KSW50ZXJuZXQgQWRkcmVzczogaHVmZmVy ZEB1cy5pYm0uY29tPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPiZxdW90O1JhbWVzaCBNYW5nYW11cmkmcXVvdDsNCiZsdDtybWFuZ2FtdXJpQGlz dG9yLmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4wMS8yOS8yMDA0IDA2OjEzIFBNPC9mb250Pg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Sm9obiBIdWZmZXJkL1NhbiBKb3NlL0lCTUBJQk1VUzwvZm9udD4N Cjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZsdDtpcHNAaWV0Zi5vcmcmZ3Q7LCAmbHQ7aXBzLWFkbWluQGlldGYub3JnJmd0 OywNCiZsdDt3cnN0dWRlbkB3YXNhYmlzeXN0ZW1zLmNvbSZndDs8L2ZvbnQ+DQo8dHI+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0 PC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlJFOiBbSXBzXSBNYXggaVNDU0kgU2Vzc2lvbnMNCnN1cHBvcnRlZDwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZh Y2U9IkFyaWFsIj5CYXNlZCBvbiB0aGlzIEkgdW5kZXJzdGFuZGQNCnRoYXQgaWYgeW91IHVzZSB0 d28gZGlmZmVyZW50IHZlbmRvciBIQkFzIG9uIGEgc2luZ2xlIEhvc3QoaW5pdGlhdG9yKSwNCnRo ZWlyIElTSURzIGFsc28gd291bGQgYmUgZGlmZmVyZW50LjwvZm9udD4NCjxwPjxmb250IHNpemU9 MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5Gb3IgZXhhbXBsZSBpZiBJIHVzZSB0d28gSEJB cw0KZnJvbSB0aGUgc2FtZSB2ZW5kb3Igb24gYSBzaW5nbGUgaG9zdCwgd2lsbCB0aGV5IGhhdmUg dGhlIHNhbWUgSVNJRCwgb3INCmRpZmZlcmVudCBJU0lEcz8/PzwvZm9udD4NCjxwPjxmb250IHNp emU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+QWxzbyBJIHdhc27igJl0IGNsZWFyIHRo YXQgd2hldGhlcg0KdGhpcyBJU0lEIGlzIG1vZGlmaWFibGUgZnJvbSBhbiBlbmQgdXNlciBwZXJw ZWN0aXZlLCBvciBpdCBpcyBkcml2ZW4gYnkNCmlTQ1NJIERyaXZlcnM/Pz8/PC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08Yj48 YnI+DQpGcm9tOjwvYj4gSm9obiBIdWZmZXJkIFttYWlsdG86aHVmZmVyZEB1cy5pYm0uY29tXSA8 Yj48YnI+DQpTZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMjksIDIwMDQgNTo1OCBQTTxiPjxi cj4NClRvOjwvYj4gUmFtZXNoIE1hbmdhbXVyaTxiPjxicj4NCkNjOjwvYj4gaXBzQGlldGYub3Jn OyBpcHMtYWRtaW5AaWV0Zi5vcmc7IHdyc3R1ZGVuQHdhc2FiaXN5c3RlbXMuY29tPGI+PGJyPg0K U3ViamVjdDo8L2I+IFJFOiBbSXBzXSBNYXggaVNDU0kgU2Vzc2lvbnMgc3VwcG9ydGVkPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCklmIHlvdSBjaGFuZ2UgdGhl IElTSUQsIGV2ZW4gd2l0aCB0aGUgc2FtZSBJbml0aWF0b3Igbm9kZSBuYW1lLCBpdCBpcyBhDQpk aWZmZXJlbnQgaW5pdGlhdG9yLiAmbmJzcDtZb3UgY2FuIG1ha2UgdGhhdCB3b3JrIGFzIGlmIGl0 IGlzIGEgc2luZ2xlDQppbml0aWF0b3Igd2l0aCB3aGF0IHdlIGNhbGwgYSB3ZWRnZSBkcml2ZXIs IG9yIHdoYXQgeW91IGFyZSBjYWxsaW5nIG11bHRpcGF0aGluZw0Kc29mdHdhcmUuICZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGUgSVNJRHMgY2FuIGhhdmUgYmVl biBnaXZlbiBhIG51bWJlciBvZiB3YXlzIHRvIGJlIHNwZWNpZmllZCwgb25lIG9mDQp0aGUgd2F5 cyBpcyB0byB1c2UgdGhlIE9VSSwgdGhhdCByZXByZXNlbnRzIHRoZSBWZW5kb3IgSUQsIGFuZCB0 aGVuIHlvdQ0KbWF5IHVzZSB5b3VyIG93biB0ZWNobmlxdWUgdG8gbW9kaWZ5IHRoZSByZXN0IG9m IHRoZSBiaXRzIGluIHRoZSBJU0lEIGFueQ0Kd2F5IHlvdSB3aXNoLCB3aGljaCBtYWtlcyB0aGUg VG90YWwgbmFtZSAoaW5jbHVkaW5nIHRoZSBOb2RlIE5hbWUpIHVuaXF1ZQ0Kd2l0aGluIHRoZSB3 b3JsZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KLjxicj4NCi48YnI+DQpKb2huIEwu IEh1ZmZlcmQ8YnI+DQpTZW5pb3IgVGVjaG5pY2FsIFN0YWZmIE1lbWJlciAoU1RTTSk8YnI+DQpJ Qk0vU3lzdGVtIEdyb3VwLCBTYW4gSm9zZSBDQTxicj4NCk1haW4gT2ZmaWNlOiAoNDA4KSAyNTYt MDQwMywgVGllOiAyNzYtMDQwMywgZUZheDogKDQwOCkgOTA0LTQ2ODg8YnI+DQpBbHQgT2ZmaWNl OiAoNDA4KSA5OTctNjEzNiwgQ2VsbDogKDQwOCkgNDk5LTk3MDI8YnI+DQpJbnRlcm5ldCBBZGRy ZXNzOiBodWZmZXJkQHVzLmlibS5jb208L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9NTQlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj4mcXVvdDtSYW1lc2ggTWFuZ2FtdXJpJnF1b3Q7DQombHQ7cm1hbmdhbXVyaUBpc3Rvci5jb20m Z3Q7PC9iPiA8YnI+DQpTZW50IGJ5OiBpcHMtYWRtaW5AaWV0Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MDEvMjkvMjAwNCAwNTo0MyBQTTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD00NSU+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0cj4NCjx0ZCB3aWR0aD0xNiU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD04 MyUgdmFsaWduPXRvcD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O3dyc3R1ZGVu QHdhc2FiaXN5c3RlbXMuY29tJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4NCjwvZm9udD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtpcHNAaWV0Zi5vcmcmZ3Q7PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHRyPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDwv Zm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5SRTogW0lwc10gTWF4IGlTQ1NJIFNlc3Npb25zDQpzdXBwb3J0ZWQ8L2ZvbnQ+PC90YWJsZT4N CjxwPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxw Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01 MCU+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHRk IHdpZHRoPTQ5JT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2Zv bnQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KSGVyZSBhcmUgc29tZSBxdWVzdGlvbnMgYWdhaW4uPGJyPg0KPGJyPg0KMSkgV2hh dCBpZiB3ZSBoYXZlIG11bHRpLXBhdGhpbmcgc29mdHdhcmUgaW5zdGFsbGVkIG9uIHRoZSBIb3N0 PGJyPg0KT1MoSW5pdGlhdG9yKSA/IDxicj4NCjIpIEhvdyBjYW4gd2UgZ2VuZXJhdGUgZGlmZmVy ZW50IElTSURzIGZyb20gdGhlIHNhbWUgaW5pdGlhdG9yLj8gSXMgdGhpczxicj4NCm9uZSBjb25m aWd1cmFibGUgdmFsdWU/PGJyPg0KPGJyPg0KTW9yZSBsYXRlciAuLi4sPGJyPg0KUmFtZXNoPGJy Pg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiB3cnN0dWRlbkB3 YXNhYmlzeXN0ZW1zLmNvbSBbbWFpbHRvOndyc3R1ZGVuQHdhc2FiaXN5c3RlbXMuY29tXSA8YnI+ DQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyOSwgMjAwNCA1OjIwIFBNPGJyPg0KVG86IFJhbWVz aCBNYW5nYW11cmk8YnI+DQpDYzogaXBzQGlldGYub3JnPGJyPg0KU3ViamVjdDogUmU6IFtJcHNd IE1heCBpU0NTSSBTZXNzaW9ucyBzdXBwb3J0ZWQ8YnI+DQo8YnI+DQpPbiBUaHUsIDI5IEphbiAy MDA0LCBSYW1lc2ggTWFuZ2FtdXJpIHdyb3RlOjxicj4NCjxicj4NCiZndDsgRm9sa3MsPGJyPg0K Jmd0Ozxicj4NCiZndDsgSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgaXMgcG9zc2liaWxpdHkgdGhh dCB0aGVyZSBjYW4gYmUgbXVsdGlwbGU8YnI+DQomZ3Q7IGNvbm5lY3Rpb25zIGluIGFuIGlTQ1NJ IHNlc3Npb24uIEJ1dCwgQ2FuIGFuIGlTQ1NJIGluaXRpYXRvciBoYXZlDQptb3JlPGJyPg0KJmd0 OyB0aGFuIG9uZSBhY3RpdmUgaVNDU0kgc2Vzc2lvbiBzaW11bHRhbmVvdXNseSB3aXRoIGEgZ2l2 ZW4gdGFyZ2V0Ljxicj4NCjxicj4NClllcyBhbmQgbm8uPGJyPg0KPGJyPg0KU3RyaWN0bHkgc3Bl YWtpbmcsIG5vLiBBbnkgYXR0ZW1wdCB0byBvcGVuIGEgc2Vjb25kIHNlc3Npb24gd2l0aCB0aGU8 YnI+DQp0YXJnZXQgYnkgYSBnaXZlbiBpbml0aWF0b3Igd291bGQgdHJpZ2dlciBzZXNzaW9uIHJl aW5zdGF0ZW1lbnQuIFRoaXM8YnI+DQpyZXByZXNlbnRzIHRoZSBmYWN0IHRoYXQgdGhlcmUgY2Fu IGJlIG9ubHkgb25lIElfVCBuZXh1cy48YnI+DQo8YnI+DQpIb3dldmVyIHNpbmNlIHRoZSBpZGVu dGlmaWVyIGZvciBhbiBpbml0aWF0b3IgaXMgYm90aCB0aGUgaW5pdGlhdG9yIG5hbWU8YnI+DQph bmQgdGhlIElTSUQsIHRoZSBzYW1lIGluaXRpYXRvciBuYW1lIGNhbiBiZSB1c2VkIG9uIGRpZmZl cmVudCBzZXNzaW9uczxicj4NCmlmPGJyPg0KdGhleSBoYXZlIGRpZmZlcmVudCBJU0lEcy4gVGhp cyBzaXR1YXRpb24sIHRob3VnaCwgY2FuIGJlIGRhbmdlcm91cyBhbmQ8YnI+DQpzaG91bGQgYmUg YXZvaWRlZDsgdGhlIHRhcmdldCB3b3VsZCBhcHBlYXIgYXMgdHdvIGRpZmZlcmVudCBTQ1NJIGRl dmljZXM8YnI+DQp0byB0aGUgaW5pdGlhdG9yJ3MgT1MuIE1vc3QgT1NzIHdvbid0IGRlYWwgd2Vs bCB3aXRoIHRoYXQgc2l0dWF0aW9uLiBGb3I8YnI+DQppbnN0YW5jZSBNaWNyb3NvZnQgV2luZG93 cydzIGF1dG8tbW91bnRpbmcgb2YgcGFydGl0aW9ucyBjb3VsZCBjYXVzZSB0aGU8YnI+DQpwYXJ0 aXRpb25zIG9uIHRoZSBkaXNrIHRvIGJlIG1vdW50ZWQgdHdpY2UuPGJyPg0KPGJyPg0KVGFrZSBj YXJlLDxicj4NCjxicj4NCkJpbGw8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCklwcyBtYWlsaW5nIGxpc3Q8YnI+DQpJcHNAaWV0 Zi5vcmc8YnI+DQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHM8L2Zv bnQ+DQo8cD4NCg== --=_alternative 0022EDED88256E2B_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 07:03:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11107 for ; Fri, 30 Jan 2004 07:03:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmXMY-0002x8-DQ for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 07:03:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UC36D1011346 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 07:03:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmXMY-0002wv-6Z for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 07:03:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11068 for ; Fri, 30 Jan 2004 07:03:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmXMU-00079Q-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 07:03:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmXLY-00070p-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 07:02:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmXKe-0006tY-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 07:01:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmXKY-0002R7-Hp; Fri, 30 Jan 2004 07:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmXJe-0002Oo-IG for ips@optimus.ietf.org; Fri, 30 Jan 2004 07:00:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10948 for ; Fri, 30 Jan 2004 07:00:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmXJZ-0006kO-00 for ips@ietf.org; Fri, 30 Jan 2004 07:00:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmXIc-0006bx-00 for ips@ietf.org; Fri, 30 Jan 2004 06:59:03 -0500 Received: from mtagate5.uk.ibm.com ([195.212.29.138]) by ietf-mx with esmtp (Exim 4.12) id 1AmXHe-0006N8-00 for ips@ietf.org; Fri, 30 Jan 2004 06:58:02 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate5.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i0UBvGWH121416; Fri, 30 Jan 2004 11:57:16 GMT Received: from d10ml001.telaviv.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0UBvBtQ071914; Fri, 30 Jan 2004 11:57:11 GMT In-Reply-To: To: pat_thaler@agilent.com Cc: cbm@rose.hp.com, ips@ietf.org, ips-admin@ietf.org, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Fri, 30 Jan 2004 13:57:08 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 30/01/2004 13:57:13, Serialize complete at 30/01/2004 13:57:13 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Will fix the example (thanks Pat and perhaps add the text you suggested). For pratical purposes it should be noted that the only SCSI device that plans to use bidirectional data transfers to-date has different phases for input and output so that block are no mixed. However I assumed always that the space is shared and that data placement is unaffected by the order of PDU's . The SNACK identifies unambiguously to the target what is missing and the initiator has to know only that something is missing in order to start a recovery action. Other than the example the spec is fine. ips-admin@ietf.org wrote on 30/01/2004 03:25:58: > I also don't think the current spec is clear and I think the > combination of the behavior described in 10.4.8 and that described in > 3.2.2 is broken for bidirectional commands. The reason for reporting > ExpDataSN in the SCSI Response is to allow the initiator to check that > it received all the Data-In PDUs associated with the command and to > send a SNACK if it didn't. > > For example, one could have the following in response to a > bidirectional command: > > DataSN PDU > 0 1st Data-In > 1 1st R2T > 2 2nd R2T > 3 2nd Data-In > 4 3rd Data-In > 5 4th Data-In > 6 3rd R2T > > If the ExpDataSN to be reported in the SCSI Response was truly the > number of Data-In PDUs as 10.4.8 says, its value would be 4. Note that > the above is consistent with the text of 3.2.2.3 which says that > DataSN and R2TSN for bidirectional commands form one continuous > undifferentiated series but it is not consistent with the example in > B.3. The example shows a PDU with R2TSN = 0 followed by a PDU with DataSN = 0. > > This is broken because the initiator could not compare the value > received in ExpDataSN to its copy of ExpDataSN to determine whether it > had gotten all the Data-In PDUs. If the behavior in 10.4.8 is > maintained, an initiator will have to keep a count of the Data-In PDUs > it has received for bidirectional commands in addition to keeping the > ExpDataSN value. The target would also have to keep two separate > counters during processing of bidirectional commands (both named > ExpDataSN by the draft) - one of how many Data-In PDUs it has sent so > it can put it in the Response and one of the value of ExpDataSN > indicating the DataSN to put in the next Data-In or R2T PDU it sends > for the command. > > There is no reason to define the protocol such that keeping two values > is necessary here. It appears that the reason to say that DataSN and > R2TSN form one sequence for bidirectional commands is to allow the > command to maintain one count for DataIn and R2T PDUs rather than > having two counters. If we were willing to forgo that optimization, > then DataSN and R2TSN should have been kept separate. > > In any case, it is incorrect to have two variables for the same > context with the same name. > > One can correct the problem by changing 10.4.8 to say that for > bidirectional commands ExpDataSN is the number of DataIn and R2T PDUs > that were sent, then one can maintain one value. One should also > correct the example in B.3. > > One could also correct the problem by changing 3.2.2 so that DataSN > was kept separate from R2TSN in bidirectional commands. In some > senses, this would have been cleaner because it avoids having one > variable with two names but it would require more context per command > and it is probably a bigger change for existing implementations. > > The code in E.2.2 seems ambiguous - it just says if (expDataSN does > not match) but it doesn't define what is considered a match. Neither > the target code nor the initiator code in E.2 seems to address how the > value of ExpDataSN for response PDUs and the compare to response PDUs > is derived. Therefore it would be consistent with either choice. > > Regards, > Pat > > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of > wrstuden@wasabisystems.com > Sent: Thursday, January 29, 2004 2:46 PM > To: Mallikarjun C. > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional > commands > > > On Thu, 29 Jan 2004, Mallikarjun C. wrote: > > > Not sure why the initiator needs to be reported on the > > total # of R2Ts in the final response....I presume > > any mismatch in R2Ts is already factored into the status. > > > > _If_ we indeed want to include R2Ts, I think it would be > > necessary to make changes (10.4.8, E.2.2, and perhaps 6) > > because I believe the current spec semantics are clear > > that R2Ts are not included. > > While I'll be honest that I don't understand _why_ R2Ts are factored into > the DataSN space along with Data-In PDUs, I've understood they were > comingled for over a year. I think it was about 16 months ago I asked > about this (before draft 20), and Julian explained that they shared the > same space. > > So I don't think it's supposed to be something new. > > Take care, > > 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 From exim@www1.ietf.org Fri Jan 30 09:47:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19030 for ; Fri, 30 Jan 2004 09:47:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmZvL-0004F6-9t for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 09:47:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UElBXa016289 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 09:47:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmZvL-0004Ee-4x for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 09:47:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19000 for ; Fri, 30 Jan 2004 09:47:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmZvJ-0005Jw-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 09:47:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmZuK-0005Ci-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 09:46:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmZtK-000506-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 09:45:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmZtG-000445-O5; Fri, 30 Jan 2004 09:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmZsV-000401-34 for ips@optimus.ietf.org; Fri, 30 Jan 2004 09:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18906 for ; Fri, 30 Jan 2004 09:44:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmZsT-0004yO-00 for ips@ietf.org; Fri, 30 Jan 2004 09:44:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmZrZ-0004s5-00 for ips@ietf.org; Fri, 30 Jan 2004 09:43:18 -0500 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1AmZrD-0004jz-00 for ips@ietf.org; Fri, 30 Jan 2004 09:42:55 -0500 Received: from ivvt2dxrc11 (c-66-177-51-158.se.client2.attbi.com[66.177.51.158]) by comcast.net (rwcrmhc11) with SMTP id <2004013014422401300lovb2e> (Authid: esquicksall); Fri, 30 Jan 2004 14:42:24 +0000 Message-ID: <000a01c3e73f$46c99dc0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Mallikarjun C." , Subject: Fw: [Ips] iSCSI: abort task set Date: Fri, 30 Jan 2004 09:42:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C3E715.5D4C8050" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3E715.5D4C8050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mallikarjun, I am really wondering what the target should do. Can you give some = advice? It is clear what to do if the TMF is not immediate... the problem is: If = it is immediate, how can the target determine when "all affected tasks = in the task set" have been received? The target can't simply wait for = all earlier CmdSN's to be received or the target can deadlock if = multiple connections. Eddy ----- Original Message -----=20 From: Eddy Quicksall=20 To: ips@ietf.org=20 Sent: Wednesday, January 28, 2004 4:39 PM Subject: [Ips] iSCSI: abort task set I've always wondered about the following paragraph but never asked. 10.6.2 says: The target: a) Receives the ABORT TASK SET/CLEAR TASK SET request. b) Waits for all target transfer tags to be responded to and for all affected tasks in the task set to be received. How can the target determine that all affected tasks in the task set = have been received? Does this simply mean that the target must sequence = the TMF just as any other command even if the TMF is immediate? What about if TST is 000b? How do I determine when some other initiator = has sent all affected tasks? Eddy ------=_NextPart_000_0007_01C3E715.5D4C8050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mallikarjun,
 
I am really wondering what the target should do. Can = you=20 give some advice?
 
It is clear what to do if the TMF is not=20 immediate... the problem is: If it is immediate, how can the=20 target determine when "all affected tasks in the task set" have = been=20 received? The target can't simply wait for all earlier CmdSN's to = be=20 received or the target can deadlock if multiple=20 connections.
 
Eddy
 
----- Original Message -----=20
From: Eddy = Quicksall
Sent: Wednesday, January 28, 2004 4:39 PM
Subject: [Ips] iSCSI: abort task set

I've always wondered about the following paragraph but never = asked.
 
10.6.2 says:

The target:

a) Receives the ABORT TASK SET/CLEAR TASK SET = request.

b) Waits for all target transfer tags to be responded = to

and for all affected tasks in the task set to be

received.

 
How can the target determine that all affected tasks in the task = set have=20 been received? Does this simply mean that the target must sequence the = TMF just=20 as any other command even if the TMF is immediate?
 
What about if TST is 000b? How do I determine when = some other=20 initiator has sent all affected tasks?
 
Eddy
------=_NextPart_000_0007_01C3E715.5D4C8050-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 12:46:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03234 for ; Fri, 30 Jan 2004 12:46:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amci3-0005Ux-DN for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 12:45:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UHjdf5021131 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 12:45:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amci3-0005Uk-8m for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 12:45:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03219 for ; Fri, 30 Jan 2004 12:45:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amci1-0000wb-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 12:45:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amch9-0000nY-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 12:44:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmcgY-0000dh-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 12:44:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcgT-0005M8-Oe; Fri, 30 Jan 2004 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amcg4-0005LC-I7 for ips@optimus.ietf.org; Fri, 30 Jan 2004 12:43:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03015 for ; Fri, 30 Jan 2004 12:43:32 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amcg2-0000aH-00 for ips@ietf.org; Fri, 30 Jan 2004 12:43:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmcfB-0000N8-00 for ips@ietf.org; Fri, 30 Jan 2004 12:42:42 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Amce7-00008g-00; Fri, 30 Jan 2004 12:41:35 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 7F75340137; Fri, 30 Jan 2004 12:41:29 -0500 (EST) Date: Fri, 30 Jan 2004 09:41:19 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Ramesh Mangamuri Cc: John Hufferd , ips@ietf.org, ips-admin@ietf.org Subject: RE: [Ips] Max iSCSI Sessions supported In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A2@mail1irv.inside.istor.com> Message-ID: References: <7D036BD3216A084DB1BD9D62BCEAF2905717A2@mail1irv.inside.istor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Thu, 29 Jan 2004, Ramesh Mangamuri wrote: > Based on this I understandd that if you use two different vendor HBAs on > a single Host(initiator), their ISIDs also would be different. > For example if I use two HBAs from the same vendor on a single host, > will they have the same ISID, or different ISIDs??? > > Also I wasn't clear that whether this ISID is modifiable from an end > user perpective, or it is driven by iSCSI Drivers???? You've now gone beyond the iSCSI spec. How two different HBAs in a single host work together is still an open question. There are two possibilities. One is that all of the HBAs act independently, and that a wedge driver unifies them for the OS. John actually talks about this in his book, and on page 145 has a diagram. How the host OS knows to only communicate with the wedge driver, and it in turn to the HBAs, is a question for the host OS. The other possibility is that there is a unified HBA API that permits the different HBAs to share a session across them. This would involve some sort of centralized command numbering, among other things. Both of these options are areas of open development. I know some of it's happening in the SNIA IPS forum. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 13:21:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06117 for ; Fri, 30 Jan 2004 13:21:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdFv-00008Z-1o for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 13:20:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UIKcxh000515 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 13:20:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdFs-00008C-To for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 13:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06105 for ; Fri, 30 Jan 2004 13:20:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmdFq-0006eJ-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 13:20:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmdEs-0006VF-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 13:19:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmdEN-0006N0-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 13:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdEL-0008PW-2H; Fri, 30 Jan 2004 13:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdDr-0008MM-0Z for ips@optimus.ietf.org; Fri, 30 Jan 2004 13:18:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05959 for ; Fri, 30 Jan 2004 13:18:26 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmdDp-0006Lj-00 for ips@ietf.org; Fri, 30 Jan 2004 13:18:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmdCq-0006C6-00 for ips@ietf.org; Fri, 30 Jan 2004 13:17:29 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AmdCV-00064a-00 for ips@ietf.org; Fri, 30 Jan 2004 13:17:07 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id B17F340137; Fri, 30 Jan 2004 13:17:07 -0500 (EST) Date: Fri, 30 Jan 2004 10:16:57 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: abort task set In-Reply-To: <003d01c3e5e7$36150860$0303a8c0@ivvt2dxrc11> Message-ID: References: <003d01c3e5e7$36150860$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Wed, 28 Jan 2004, Eddy Quicksall wrote: > I've always wondered about the following paragraph but never asked. > > 10.6.2 says: > The target: > > a) Receives the ABORT TASK SET/CLEAR TASK SET request. > > b) Waits for all target transfer tags to be responded to > > and for all affected tasks in the task set to be > > received. > > > How can the target determine that all affected tasks in the task set > have been received? Does this simply mean that the target must sequence > the TMF just as any other command even if the TMF is immediate? I don't think so. I think the best way to think of it is that at some point, the TMF starts being processed. You abort all tasks active at that point. I think it's mostly saying that the target waits for all outstanding TTTs to be answered. All tasks stop generating new target tasks; writes stop generating new R2Ts and reads stop generating bursts. The initiator terminates all outstanding tasks by sending data and setting the 'F' bit. It also answers any outstanding Data In runs (where the 'A' bit was set). i.e. it's doing the gentle shutdown the iSCSI spec describes, on all of the tasks. I guess you'd also start a timer on the task(s), and if they weren't completed in a timely manner then you just kill them. Like if an initiator aborting the task set to clean up after an initiator that has gone off line. > What about if TST is 000b? How do I determine when some other initiator > has sent all affected tasks? Pick a moment in time (grab a lock somewhere). Everything that exists at that moment gets killed. Everything else doesn't. Note that this applies to tasks in the task set, which as I understand it is a SCSI thing. I think your comments about waiting have to do with commands in the CmdSN queue. Since they aren't in the SCSI task set yet, I don't think you have to worry about them. At least I don't. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 13:46:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07862 for ; Fri, 30 Jan 2004 13:46:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amde6-0005OK-Qp for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 13:45:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UIjcP6020724 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 13:45:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amde6-0005OB-NC for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 13:45:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07849 for ; Fri, 30 Jan 2004 13:45:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amde4-0002aZ-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 13:45:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amdd6-0002SC-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 13:44:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmdcX-0002Jh-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 13:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdcY-0005EV-9f; Fri, 30 Jan 2004 13:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdc6-0005DZ-Mo for ips@optimus.ietf.org; Fri, 30 Jan 2004 13:43:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07737 for ; Fri, 30 Jan 2004 13:43:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amdc4-0002II-00 for ips@ietf.org; Fri, 30 Jan 2004 13:43:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmdbC-00028n-00 for ips@ietf.org; Fri, 30 Jan 2004 13:42:39 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1Amdad-0001zm-00 for ips@ietf.org; Fri, 30 Jan 2004 13:42:03 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel13.hp.com (Postfix) with ESMTP id 2AEC01C00D86; Fri, 30 Jan 2004 10:42:03 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id EC99B8090; Fri, 30 Jan 2004 10:37:28 -0800 (PST) Message-ID: <401AA571.9000306@rose.hp.com> Date: Fri, 30 Jan 2004 10:41:53 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: Fw: [Ips] iSCSI: abort task set References: <000a01c3e73f$46c99dc0$0303a8c0@ivvt2dxrc11> In-Reply-To: <000a01c3e73f$46c99dc0$0303a8c0@ivvt2dxrc11> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddy, Sorry for not responding sooner, I was checking my old notes (but couldn't find relevant ones so far). The authors' advice on this is the following - The wait for affected tasks can be done (need to pick a point in time as the reference for determining the "affected" tasks, regardless of the # of sessions). However, an alternative that's also legal is given below. Bullet (b) should have been: b) Waits for all target transfer tags to be responded to and for all affected tasks in the task set to be received (alternatively, the target may plug the CmdSN gaps for unreceived commands just as if an abort request is received for each individual affected task, refer section 6.9 "SCSI timeouts") Note that the wait on StatSN ack is however mandatory. It is good to get this alternative/clarification into the final RFC. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Eddy Quicksall wrote: > Mallikarjun, > > I am really wondering what the target should do. Can you give some advice? > > It is clear what to do if the TMF is not immediate... the problem is: If > it is immediate, how can the target determine when "all affected tasks > in the task set" have been received? The target can't simply wait for > all earlier CmdSN's to be received or the target can deadlock if > multiple connections. > > Eddy > > ----- Original Message ----- > From: Eddy Quicksall > To: ips@ietf.org > Sent: Wednesday, January 28, 2004 4:39 PM > Subject: [Ips] iSCSI: abort task set > > I've always wondered about the following paragraph but never asked. > > 10.6.2 says: > > The target: > > a) Receives the ABORT TASK SET/CLEAR TASK SET request. > > b) Waits for all target transfer tags to be responded to > > and for all affected tasks in the task set to be > > received. > > > How can the target determine that all affected tasks in the task set > have been received? Does this simply mean that the target must sequence > the TMF just as any other command even if the TMF is immediate? > > What about if TST is 000b? How do I determine when some other initiator > has sent all affected tasks? > > Eddy _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 14:33:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11249 for ; Fri, 30 Jan 2004 14:33:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeNe-00010r-Uq for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 14:32:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UJWghU003893 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 14:32:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeNe-00010i-QH for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 14:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11229 for ; Fri, 30 Jan 2004 14:32:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmeNc-0002Q1-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 14:32:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmeMl-0002Gu-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 14:31:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmeM5-00027A-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 14:31:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeM5-0000oe-Rs; Fri, 30 Jan 2004 14:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeLx-0000lc-9o for ips@optimus.ietf.org; Fri, 30 Jan 2004 14:30:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11092 for ; Fri, 30 Jan 2004 14:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmeLu-00026c-00 for ips@ietf.org; Fri, 30 Jan 2004 14:30:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmeL4-0001vW-00 for ips@ietf.org; Fri, 30 Jan 2004 14:30:03 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AmeKI-0001jK-00 for ips@ietf.org; Fri, 30 Jan 2004 14:29:15 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id B4C751C00F0E; Fri, 30 Jan 2004 11:29:14 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 4E4768009; Fri, 30 Jan 2004 11:24:40 -0800 (PST) Message-ID: <401AB080.1060607@rose.hp.com> Date: Fri, 30 Jan 2004 11:29:04 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Satran , pat_thaler@agilent.com Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat wrote: >One can correct the problem by changing 10.4.8 to say that for >bidirectional commands ExpDataSN is the number of DataIn and R2T PDUs >that were sent, then one can maintain one value. One should also >correct the example in B.3. Agreed, both need to be done. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Julian Satran wrote: > Will fix the example (thanks Pat and perhaps add the text you suggested). > For pratical purposes it should be noted that the only SCSI device that > plans to use bidirectional data transfers to-date has different phases for > input and output so that block are no mixed. > > However I assumed always that the space is shared and that data placement > is unaffected by the order of PDU's . The SNACK identifies unambiguously > to the target what is missing and the initiator has to know only that > something is missing in order to start a recovery action. > > Other than the example the spec is fine. > > ips-admin@ietf.org wrote on 30/01/2004 03:25:58: > > >>I also don't think the current spec is clear and I think the >>combination of the behavior described in 10.4.8 and that described in >>3.2.2 is broken for bidirectional commands. The reason for reporting >>ExpDataSN in the SCSI Response is to allow the initiator to check that >>it received all the Data-In PDUs associated with the command and to >>send a SNACK if it didn't. >> >>For example, one could have the following in response to a >>bidirectional command: >> >>DataSN PDU >>0 1st Data-In >>1 1st R2T >>2 2nd R2T >>3 2nd Data-In >>4 3rd Data-In >>5 4th Data-In >>6 3rd R2T >> >>If the ExpDataSN to be reported in the SCSI Response was truly the >>number of Data-In PDUs as 10.4.8 says, its value would be 4. Note that >>the above is consistent with the text of 3.2.2.3 which says that >>DataSN and R2TSN for bidirectional commands form one continuous >>undifferentiated series but it is not consistent with the example in >>B.3. The example shows a PDU with R2TSN = 0 followed by a PDU with > > DataSN = 0. > >>This is broken because the initiator could not compare the value >>received in ExpDataSN to its copy of ExpDataSN to determine whether it >>had gotten all the Data-In PDUs. If the behavior in 10.4.8 is >>maintained, an initiator will have to keep a count of the Data-In PDUs >>it has received for bidirectional commands in addition to keeping the >>ExpDataSN value. The target would also have to keep two separate >>counters during processing of bidirectional commands (both named >>ExpDataSN by the draft) - one of how many Data-In PDUs it has sent so >>it can put it in the Response and one of the value of ExpDataSN >>indicating the DataSN to put in the next Data-In or R2T PDU it sends >>for the command. >> >>There is no reason to define the protocol such that keeping two values >>is necessary here. It appears that the reason to say that DataSN and >>R2TSN form one sequence for bidirectional commands is to allow the >>command to maintain one count for DataIn and R2T PDUs rather than >>having two counters. If we were willing to forgo that optimization, >>then DataSN and R2TSN should have been kept separate. >> >>In any case, it is incorrect to have two variables for the same >>context with the same name. >> >>One can correct the problem by changing 10.4.8 to say that for >>bidirectional commands ExpDataSN is the number of DataIn and R2T PDUs >>that were sent, then one can maintain one value. One should also >>correct the example in B.3. >> >>One could also correct the problem by changing 3.2.2 so that DataSN >>was kept separate from R2TSN in bidirectional commands. In some >>senses, this would have been cleaner because it avoids having one >>variable with two names but it would require more context per command >>and it is probably a bigger change for existing implementations. >> >>The code in E.2.2 seems ambiguous - it just says if (expDataSN does >>not match) but it doesn't define what is considered a match. Neither >>the target code nor the initiator code in E.2 seems to address how the >>value of ExpDataSN for response PDUs and the compare to response PDUs >>is derived. Therefore it would be consistent with either choice. >> >>Regards, >>Pat _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 14:37:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11500 for ; Fri, 30 Jan 2004 14:37:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeSJ-0001YK-24 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 14:37:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UJbU2A005962 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 14:37:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeSI-0001Y5-HF for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 14:37:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11495 for ; Fri, 30 Jan 2004 14:37:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmeSF-00035Q-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 14:37:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmeRL-0002yY-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 14:36:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmeQr-0002rL-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 14:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeQs-0001GT-OK; Fri, 30 Jan 2004 14:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeQN-00019k-CO for ips@optimus.ietf.org; Fri, 30 Jan 2004 14:35:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11417 for ; Fri, 30 Jan 2004 14:35:28 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmeQK-0002qL-00 for ips@ietf.org; Fri, 30 Jan 2004 14:35:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmePO-0002jP-00 for ips@ietf.org; Fri, 30 Jan 2004 14:34:31 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AmeP2-0002cF-00 for ips@ietf.org; Fri, 30 Jan 2004 14:34:08 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 699DA40137; Fri, 30 Jan 2004 14:34:08 -0500 (EST) Date: Fri, 30 Jan 2004 11:33:55 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Mallikarjun C." Cc: Eddy Quicksall , ips@ietf.org Subject: Re: Fw: [Ips] iSCSI: abort task set In-Reply-To: <401AA571.9000306@rose.hp.com> Message-ID: References: <000a01c3e73f$46c99dc0$0303a8c0@ivvt2dxrc11> <401AA571.9000306@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Fri, 30 Jan 2004, Mallikarjun C. wrote: > Eddy, > > Sorry for not responding sooner, I was checking my old > notes (but couldn't find relevant ones so far). > > The authors' advice on this is the following - > > The wait for affected tasks can be done (need to > pick a point in time as the reference for determining > the "affected" tasks, regardless of the # of sessions). > However, an alternative that's also legal is given below. > > Bullet (b) should have been: > > b) Waits for all target transfer tags to be responded to > and for all affected tasks in the task set to be > received (alternatively, the target may plug the CmdSN > gaps for unreceived commands just as if an abort request > is received for each individual affected task, refer > section 6.9 "SCSI timeouts") Abort Task Set has to plug the whole CmdSN window on each session?? That sounds excessive. Plugging the CmdSN hole for an Abort Task seems fine, since the initiator tells the target explicitly which CmdSN to abort (and also knows what the highest CmdSN used so far is). But with the Task Set commands, we _don't_ know the highest CmdSN the initiator has used, only the highest CmdSN we've seen and MaxCmdSN. Also, for the TST 000b case, what does that mean for other initiators? Their entire CmdSN window gets filled? Consider an initiator that was quiescent. If I'm understanding the window-filling correctly, its entire CmdSN window gets slammed shut. Since its quescent, how will it know its window got closed? Any non-immediate command it sends will just disapear as the CmdSN window was filled. It will also see the CmdSN window just move if the target sends in a PDU. It won't understand why the window moved of its own accord until it gets a SCSI abort UA. ?? Finally, since iSCSI tasks don't get passed to the SCSI layer until the CmdSN window is satisfied, are CmdSN-pending tasks really in the SCSI task set? Or did I misunderstand something? Please tell me I did as the above looks messy. :-) > Note that the wait on StatSN ack is however > mandatory. Is there any sort of time out? > It is good to get this alternative/clarification into > the final RFC. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 14:45:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11826 for ; Fri, 30 Jan 2004 14:45:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeZy-0002As-9Y for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 14:45:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UJjQlE008352 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 14:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeZy-0002Ad-4J for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 14:45:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11822 for ; Fri, 30 Jan 2004 14:45:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmeZv-0004AD-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 14:45:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmeZ2-000441-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 14:44:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmeYZ-0003xD-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 14:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeYb-0001zN-93; Fri, 30 Jan 2004 14:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmeXz-0001xh-3a for ips@optimus.ietf.org; Fri, 30 Jan 2004 14:43:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11754 for ; Fri, 30 Jan 2004 14:43:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmeXw-0003vK-00 for ips@ietf.org; Fri, 30 Jan 2004 14:43:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmeWx-0003lX-00 for ips@ietf.org; Fri, 30 Jan 2004 14:42:20 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AmeW0-0003cB-00 for ips@ietf.org; Fri, 30 Jan 2004 14:41:20 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1AmeUb-0002IE-00; Fri, 30 Jan 2004 19:39:53 +0000 From: "Ken Sandars" To: "'Mallikarjun C.'" , "'Julian Satran'" , Cc: Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Date: Fri, 30 Jan 2004 19:40:40 -0000 Message-ID: <001c01c3e769$05c82150$7107a8c0@winminx> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <401AB080.1060607@rose.hp.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mallikarjun, One final clarification request, and I can sleep easy on this topic! Will the new wording for 10.4.8 be more general to indicate that ExpDataSN is the number of DataIn and R2T PDUs that were sent? Is this field only valid for commands which have at least one Data-In PDU? Thanks again, Ken Sandars Elipsan UK > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of Mallikarjun C. > Sent: 30 January 2004 19:29 > To: Julian Satran; pat_thaler@agilent.com > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for > bidirectional commands > > > Pat wrote: > > >One can correct the problem by changing 10.4.8 to say that > for >bidirectional commands ExpDataSN is the number of > DataIn and R2T PDUs >that were sent, then one can maintain > one value. One should also >correct the example in B.3. > > Agreed, both need to be done. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > > Julian Satran wrote: > > > Will fix the example (thanks Pat and perhaps add the text you > > suggested). > > For pratical purposes it should be noted that the only SCSI > device that > > plans to use bidirectional data transfers to-date has > different phases for > > input and output so that block are no mixed. > > > > However I assumed always that the space is shared and that data > > placement > > is unaffected by the order of PDU's . The SNACK identifies > unambiguously > > to the target what is missing and the initiator has to know > only that > > something is missing in order to start a recovery action. > > > > Other than the example the spec is fine. > > > > ips-admin@ietf.org wrote on 30/01/2004 03:25:58: > > > > > >>I also don't think the current spec is clear and I think the > >>combination of the behavior described in 10.4.8 and that > described in > >>3.2.2 is broken for bidirectional commands. The reason for > reporting > >>ExpDataSN in the SCSI Response is to allow the initiator to > check that > >>it received all the Data-In PDUs associated with the command and to > >>send a SNACK if it didn't. > >> > >>For example, one could have the following in response to a > >>bidirectional command: > >> > >>DataSN PDU > >>0 1st Data-In > >>1 1st R2T > >>2 2nd R2T > >>3 2nd Data-In > >>4 3rd Data-In > >>5 4th Data-In > >>6 3rd R2T > >> > >>If the ExpDataSN to be reported in the SCSI Response was truly the > >>number of Data-In PDUs as 10.4.8 says, its value would be > 4. Note that > >>the above is consistent with the text of 3.2.2.3 which says that > >>DataSN and R2TSN for bidirectional commands form one continuous > >>undifferentiated series but it is not consistent with the > example in > >>B.3. The example shows a PDU with R2TSN = 0 followed by a PDU with > > > > DataSN = 0. > > > >>This is broken because the initiator could not compare the value > >>received in ExpDataSN to its copy of ExpDataSN to determine > whether it > >>had gotten all the Data-In PDUs. If the behavior in 10.4.8 is > >>maintained, an initiator will have to keep a count of the > Data-In PDUs > >>it has received for bidirectional commands in addition to > keeping the > >>ExpDataSN value. The target would also have to keep two separate > >>counters during processing of bidirectional commands (both named > >>ExpDataSN by the draft) - one of how many Data-In PDUs it > has sent so > >>it can put it in the Response and one of the value of ExpDataSN > >>indicating the DataSN to put in the next Data-In or R2T PDU > it sends > >>for the command. > >> > >>There is no reason to define the protocol such that keeping > two values > >>is necessary here. It appears that the reason to say that > DataSN and > >>R2TSN form one sequence for bidirectional commands is to allow the > >>command to maintain one count for DataIn and R2T PDUs rather than > >>having two counters. If we were willing to forgo that optimization, > >>then DataSN and R2TSN should have been kept separate. > >> > >>In any case, it is incorrect to have two variables for the same > >>context with the same name. > >> > >>One can correct the problem by changing 10.4.8 to say that for > >>bidirectional commands ExpDataSN is the number of DataIn > and R2T PDUs > >>that were sent, then one can maintain one value. One should also > >>correct the example in B.3. > >> > >>One could also correct the problem by changing 3.2.2 so that DataSN > >>was kept separate from R2TSN in bidirectional commands. In some > >>senses, this would have been cleaner because it avoids having one > >>variable with two names but it would require more context > per command > >>and it is probably a bigger change for existing implementations. > >> > >>The code in E.2.2 seems ambiguous - it just says if (expDataSN does > >>not match) but it doesn't define what is considered a > match. Neither > >>the target code nor the initiator code in E.2 seems to > address how the > >>value of ExpDataSN for response PDUs and the compare to > response PDUs > >>is derived. Therefore it would be consistent with either choice. > >> > >>Regards, > >>Pat > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Jan 30 15:03:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12558 for ; Fri, 30 Jan 2004 15:03:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmerR-0007Ln-23 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 15:03:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UK3TjH028250 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 15:03:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmerQ-0007LT-So for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 15:03:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12495 for ; Fri, 30 Jan 2004 15:03:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmerN-0006No-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:03:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmeqT-0006Fy-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:02:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amepz-00069H-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ameq0-0005cs-51; Fri, 30 Jan 2004 15:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmepV-00058y-B0 for ips@optimus.ietf.org; Fri, 30 Jan 2004 15:01:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12383 for ; Fri, 30 Jan 2004 15:01:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmepS-00068A-00 for ips@ietf.org; Fri, 30 Jan 2004 15:01:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmeoQ-000611-00 for ips@ietf.org; Fri, 30 Jan 2004 15:00:23 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AmenU-0005tz-00 for ips@ietf.org; Fri, 30 Jan 2004 14:59:24 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1Amem4-00042t-00; Fri, 30 Jan 2004 19:57:56 +0000 From: "Ken Sandars" To: , "'Mallikarjun C.'" Cc: "'Eddy Quicksall'" , Subject: RE: Fw: [Ips] iSCSI: abort task set Date: Fri, 30 Jan 2004 19:58:43 -0000 Message-ID: <001d01c3e76b$8b867e70$7107a8c0@winminx> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Bill, > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of wrstuden@wasabisystems.com > Sent: 30 January 2004 19:34 > To: Mallikarjun C. > Cc: Eddy Quicksall; ips@ietf.org > Subject: Re: Fw: [Ips] iSCSI: abort task set > > > On Fri, 30 Jan 2004, Mallikarjun C. wrote: > > > Eddy, > > > > Sorry for not responding sooner, I was checking my old > > notes (but couldn't find relevant ones so far). > > > > The authors' advice on this is the following - > > > > The wait for affected tasks can be done (need to > > pick a point in time as the reference for determining > > the "affected" tasks, regardless of the # of sessions). However, an > > alternative that's also legal is given below. > > > > Bullet (b) should have been: > > > > b) Waits for all target transfer tags to be responded to > > and for all affected tasks in the task set to be > > received (alternatively, the target may plug the CmdSN > > gaps for unreceived commands just as if an abort request > > is received for each individual affected task, refer > > section 6.9 "SCSI timeouts") > > Abort Task Set has to plug the whole CmdSN window on each > session?? That sounds excessive. Plugging the CmdSN hole for > an Abort Task seems fine, since the initiator tells the > target explicitly which CmdSN to abort (and also knows what > the highest CmdSN used so far is). But with the Task Set > commands, we _don't_ know the highest CmdSN the initiator has > used, only the highest CmdSN we've seen and MaxCmdSN. > For the session the TMF was issued in, the CmdSN of the TMF command is where it's up to. However I think this plugging breaks down for a multiple-LUN target. Can the target assume the missing tasks are for the affected LUN? > Also, for the TST 000b case, what does that mean for other > initiators? [snip] Nothing - fallback to to the 'pick a point in time' method. Hope that helps, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 15:15:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13764 for ; Fri, 30 Jan 2004 15:15:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amf2A-00045k-Vg for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 15:14:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UKEYUX015722 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 15:14:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amf2A-00045V-R8 for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 15:14:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13688 for ; Fri, 30 Jan 2004 15:14:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amf29-000031-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:14:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amf1F-0007iK-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:13:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amf0g-0007aI-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amf0d-0003WB-Tj; Fri, 30 Jan 2004 15:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amf03-0003Ek-L2 for ips@optimus.ietf.org; Fri, 30 Jan 2004 15:12:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13428 for ; Fri, 30 Jan 2004 15:12:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amf02-0007Wb-00 for ips@ietf.org; Fri, 30 Jan 2004 15:12:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amez9-0007Ox-00 for ips@ietf.org; Fri, 30 Jan 2004 15:11:28 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1AmeyE-0007GV-00 for ips@ietf.org; Fri, 30 Jan 2004 15:10:30 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 749571C014EB; Fri, 30 Jan 2004 15:10:29 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id AFD178009; Fri, 30 Jan 2004 12:05:54 -0800 (PST) Message-ID: <401ABA2C.807@rose.hp.com> Date: Fri, 30 Jan 2004 12:10:20 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wrstuden@wasabisystems.com Cc: Eddy Quicksall , ips@ietf.org Subject: Re: Fw: [Ips] iSCSI: abort task set References: <000a01c3e73f$46c99dc0$0303a8c0@ivvt2dxrc11> <401AA571.9000306@rose.hp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The term "plugging the CmdSN gap" doesn't mean shutting the CmdSN window down. If the target received a CmdSN X but has not yet received a CmdSN Y within the CmdSN window (where Y < X, in Serial Number Arithmetic), then Y is the "CmdSN gap" (not the valid window > X). To summarize, a "CmdSN gap" must meet two conditions a) target deterministically knows it's already issued by the initiator, and, b) it has not yet arrived. In this example, an abort operation for CmdSN=Y simply "plugs" the CmdSN gap, i.e. the CmdSN is considered received and aborted from now on. This lets the window slide (standard behavior today). There's no reason to disallow the same behavior when multiple tasks are being aborted. Plugging the CmdSN gaps at a point in time is not a complex operation. And it doesn't affect quiescent initiators at all. > Finally, since iSCSI tasks don't get passed to the SCSI layer until the > CmdSN window is satisfied, are CmdSN-pending tasks really in the SCSI task > set? I assme you mean "commands are reordered" when you say "CmdSN window is satisfied". One could make an argument that the tasks wating in the transport are not in a SCSI task set. But we decided way back that iSCSI should hide the queueing that it introduced in the transport, so application clients won't receive some task responses after the task set is aborted (also check the command ordering draft for a related discussion). > Is there any sort of time out? Not that the spec specifies. Standard error recovery is applicable on timeouts. Hope this helps. M wrstuden@wasabisystems.com wrote: > On Fri, 30 Jan 2004, Mallikarjun C. wrote: > > >>Eddy, >> >>Sorry for not responding sooner, I was checking my old >>notes (but couldn't find relevant ones so far). >> >>The authors' advice on this is the following - >> >>The wait for affected tasks can be done (need to >>pick a point in time as the reference for determining >>the "affected" tasks, regardless of the # of sessions). >>However, an alternative that's also legal is given below. >> >>Bullet (b) should have been: >> >>b) Waits for all target transfer tags to be responded to >> and for all affected tasks in the task set to be >> received (alternatively, the target may plug the CmdSN >> gaps for unreceived commands just as if an abort request >> is received for each individual affected task, refer >> section 6.9 "SCSI timeouts") > > > Abort Task Set has to plug the whole CmdSN window on each session?? That > sounds excessive. Plugging the CmdSN hole for an Abort Task seems fine, > since the initiator tells the target explicitly which CmdSN to abort (and > also knows what the highest CmdSN used so far is). But with the Task Set > commands, we _don't_ know the highest CmdSN the initiator has used, only > the highest CmdSN we've seen and MaxCmdSN. > > Also, for the TST 000b case, what does that mean for other initiators? > Their entire CmdSN window gets filled? Consider an initiator that was > quiescent. If I'm understanding the window-filling correctly, its entire > CmdSN window gets slammed shut. Since its quescent, how will it know its > window got closed? Any non-immediate command it sends will just disapear > as the CmdSN window was filled. It will also see the CmdSN window just > move if the target sends in a PDU. It won't understand why the window > moved of its own accord until it gets a SCSI abort UA. ?? > > Finally, since iSCSI tasks don't get passed to the SCSI layer until the > CmdSN window is satisfied, are CmdSN-pending tasks really in the SCSI task > set? > > Or did I misunderstand something? Please tell me I did as the above looks > messy. :-) > > >>Note that the wait on StatSN ack is however >>mandatory. > > > Is there any sort of time out? > > >>It is good to get this alternative/clarification into >>the final RFC. > > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 15:32:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15039 for ; Fri, 30 Jan 2004 15:32:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfJU-0006ZU-LA for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 15:32:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UKWS84025260 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 15:32:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfJU-0006ZL-6e for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 15:32:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15036 for ; Fri, 30 Jan 2004 15:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmfJS-0002UU-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:32:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmfIY-0002Nr-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:31:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmfIE-0002H8-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfI7-0006P0-EK; Fri, 30 Jan 2004 15:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfHb-0006Iz-Ms for ips@optimus.ietf.org; Fri, 30 Jan 2004 15:30:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14960 for ; Fri, 30 Jan 2004 15:30:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmfHa-0002GG-00 for ips@ietf.org; Fri, 30 Jan 2004 15:30:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmfGc-00029k-00 for ips@ietf.org; Fri, 30 Jan 2004 15:29:30 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1AmfGG-00022t-00 for ips@ietf.org; Fri, 30 Jan 2004 15:29:08 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id D9CFB1C0071D; Fri, 30 Jan 2004 12:29:08 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 684F48082; Fri, 30 Jan 2004 12:24:26 -0800 (PST) Message-ID: <401ABE83.1050008@rose.hp.com> Date: Fri, 30 Jan 2004 12:28:51 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Sandars Cc: "'Julian Satran'" , pat_thaler@agilent.com, ips@ietf.org Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands References: <001c01c3e769$05c82150$7107a8c0@winminx> In-Reply-To: <001c01c3e769$05c82150$7107a8c0@winminx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ken, I am not sure we need to restrict the wording to commands with at least one Data-In PDU. Do you see an issue? In any case, if you have a specific wording suggestion, please send it to Julian directly (he owns the pen). Regards. Mallikarjun Ken Sandars wrote: > Hi Mallikarjun, > > One final clarification request, and I can sleep easy on this topic! > > Will the new wording for 10.4.8 be more general to indicate that > ExpDataSN is the number of DataIn and R2T PDUs that were sent? > > Is this field only valid for commands which have at least one Data-In > PDU? > > > Thanks again, > Ken Sandars > Elipsan UK > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 15:56:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16123 for ; Fri, 30 Jan 2004 15:56:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amfgh-00085L-PY for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 15:56:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UKuRP5031073 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 15:56:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amfgh-000856-Ls for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 15:56:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16112 for ; Fri, 30 Jan 2004 15:56:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amfgg-0005hd-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:56:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amffm-0005bC-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:55:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmffM-0005UT-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 15:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmffL-0007oS-L1; Fri, 30 Jan 2004 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amfeq-0007nY-08 for ips@optimus.ietf.org; Fri, 30 Jan 2004 15:54:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16061 for ; Fri, 30 Jan 2004 15:54:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amfeo-0005Tr-00 for ips@ietf.org; Fri, 30 Jan 2004 15:54:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amfdt-0005N5-00 for ips@ietf.org; Fri, 30 Jan 2004 15:53:34 -0500 Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx with esmtp (Exim 4.12) id 1AmfdR-0005EI-00 for ips@ietf.org; Fri, 30 Jan 2004 15:53:05 -0500 Received: from ivvt2dxrc11 (c-66-177-51-158.se.client2.attbi.com[66.177.51.158]) by comcast.net (rwcrmhc13) with SMTP id <20040130205235015005gh9he> (Authid: esquicksall); Fri, 30 Jan 2004 20:52:35 +0000 Message-ID: <001a01c3e772$fcf52c80$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: References: <000a01c3e73f$46c99dc0$0303a8c0@ivvt2dxrc11> <401AA571.9000306@rose.hp.com> Subject: Re: Fw: [Ips] iSCSI: abort task set Date: Fri, 30 Jan 2004 15:52:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit When you say "pick a point in time" do you simply mean to use the CmdSN of the ABORT TASK SET TMF for the given initiator and TST=001b? Or are you applying this phrase to other initiators when TST is 000b? Eddy ----- Original Message ----- From: "Mallikarjun C." To: "Eddy Quicksall" Cc: Sent: Friday, January 30, 2004 1:41 PM Subject: Re: Fw: [Ips] iSCSI: abort task set > Eddy, > > Sorry for not responding sooner, I was checking my old > notes (but couldn't find relevant ones so far). > > The authors' advice on this is the following - > > The wait for affected tasks can be done (need to > pick a point in time as the reference for determining > the "affected" tasks, regardless of the # of sessions). > However, an alternative that's also legal is given below. > > Bullet (b) should have been: > > b) Waits for all target transfer tags to be responded to > and for all affected tasks in the task set to be > received (alternatively, the target may plug the CmdSN > gaps for unreceived commands just as if an abort request > is received for each individual affected task, refer > section 6.9 "SCSI timeouts") > > Note that the wait on StatSN ack is however > mandatory. > > It is good to get this alternative/clarification into > the final RFC. > > Thanks. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > > Eddy Quicksall wrote: > > > Mallikarjun, > > > > I am really wondering what the target should do. Can you give some advice? > > > > It is clear what to do if the TMF is not immediate... the problem is: If > > it is immediate, how can the target determine when "all affected tasks > > in the task set" have been received? The target can't simply wait for > > all earlier CmdSN's to be received or the target can deadlock if > > multiple connections. > > > > Eddy > > > > ----- Original Message ----- > > From: Eddy Quicksall > > To: ips@ietf.org > > Sent: Wednesday, January 28, 2004 4:39 PM > > Subject: [Ips] iSCSI: abort task set > > > > I've always wondered about the following paragraph but never asked. > > > > 10.6.2 says: > > > > The target: > > > > a) Receives the ABORT TASK SET/CLEAR TASK SET request. > > > > b) Waits for all target transfer tags to be responded to > > > > and for all affected tasks in the task set to be > > > > received. > > > > > > How can the target determine that all affected tasks in the task set > > have been received? Does this simply mean that the target must sequence > > the TMF just as any other command even if the TMF is immediate? > > > > What about if TST is 000b? How do I determine when some other initiator > > has sent all affected tasks? > > > > Eddy > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 16:01:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16300 for ; Fri, 30 Jan 2004 16:01:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmflV-0008V6-BD for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:01:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UL1PSu032675 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmflV-0008Uw-5v for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:01:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16295 for ; Fri, 30 Jan 2004 16:01:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmflT-0006HM-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:01:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmfkX-0006BJ-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:00:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmfkC-00065V-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:00:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfkD-0008Iy-0M; Fri, 30 Jan 2004 16:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfjZ-0008HZ-U1 for ips@optimus.ietf.org; Fri, 30 Jan 2004 15:59:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16232 for ; Fri, 30 Jan 2004 15:59:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmfjY-000654-00 for ips@ietf.org; Fri, 30 Jan 2004 15:59:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amfii-0005zC-00 for ips@ietf.org; Fri, 30 Jan 2004 15:58:33 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AmfiG-0005sQ-00 for ips@ietf.org; Fri, 30 Jan 2004 15:58:04 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1Amfgs-0002Jk-00; Fri, 30 Jan 2004 20:56:38 +0000 From: "Ken Sandars" To: "'Julian Satran'" , "'Mallikarjun C.'" Cc: , Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Date: Fri, 30 Jan 2004 20:57:29 -0000 Message-ID: <001e01c3e773$be305640$7107a8c0@winminx> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <401ABE83.1050008@rose.hp.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Julo, As requested, two alternative proposals for section 10.4.8: Suggestion 1 -------------------------- 10.4.8 ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for the command. This field is reserved if the response code is not Command Completed at Target. Suggestion 2 -------------------------- 10.4.8 ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for the command. This field is reserved if the response code is not Command Completed at Target or the target sent no Data-In PDUs for the command. ---------------------------------------- I'm more than happy with any answer which clarifies when the field is reserved. Thanks, Ken Sandars Elipsan UK > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of Mallikarjun C. > Sent: 30 January 2004 20:29 > To: Ken Sandars > Cc: 'Julian Satran'; pat_thaler@agilent.com; ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for > bidirectional commands > > > Ken, > > I am not sure we need to restrict the wording > to commands with at least one Data-In PDU. Do > you see an issue? > > In any case, if you have a specific wording suggestion, > please send it to Julian directly (he owns the pen). > > Regards. > > Mallikarjun > > > > Ken Sandars wrote: > > > Hi Mallikarjun, > > > > One final clarification request, and I can sleep easy on > this topic! > > > > Will the new wording for 10.4.8 be more general to indicate that > > ExpDataSN is the number of DataIn and R2T PDUs that were sent? > > > > Is this field only valid for commands which have at least > one Data-In > > PDU? > > > > > > Thanks again, > > Ken Sandars > > Elipsan UK > > > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Jan 30 16:03:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16411 for ; Fri, 30 Jan 2004 16:03:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfnY-0000Iu-2V for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:03:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UL3W8B001162 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:03:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfnX-0000Ic-Uj for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:03:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16407 for ; Fri, 30 Jan 2004 16:03:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmfnW-0006Xk-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:03:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amfma-0006Pw-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:02:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amfm4-0006Ix-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amfm4-0000AS-TP; Fri, 30 Jan 2004 16:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmflT-0008Uq-Q2 for ips@optimus.ietf.org; Fri, 30 Jan 2004 16:01:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16284 for ; Fri, 30 Jan 2004 16:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmflS-0006HA-00 for ips@ietf.org; Fri, 30 Jan 2004 16:01:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmfkV-0006B2-00 for ips@ietf.org; Fri, 30 Jan 2004 16:00:24 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1Amfjw-00065M-00 for ips@ietf.org; Fri, 30 Jan 2004 15:59:48 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 6A0331C02545; Fri, 30 Jan 2004 15:59:48 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 90A788009; Fri, 30 Jan 2004 12:55:13 -0800 (PST) Message-ID: <401AC5BB.4040603@rose.hp.com> Date: Fri, 30 Jan 2004 12:59:39 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Sandars Cc: ips@ietf.org Subject: Re: Fw: [Ips] iSCSI: abort task set References: <001d01c3e76b$8b867e70$7107a8c0@winminx> In-Reply-To: <001d01c3e76b$8b867e70$7107a8c0@winminx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >However I think this plugging > breaks down for a multiple-LUN target. Can the target assume > the missing tasks are for the affected LUN? No, not always. A very good point. Even though the suggested "alternative" is an optimization for tight-knit (i.e. rototilled) targets, it isn't generally usable for multi-LU, strict-layered, targets. Now I recall this is why we didn't put this "alternative" in the spec to begin with (haven't found those notes...). So I now believe the "alternative" text in paranetheses that was suggested is at best a fit for implementers notes, if at all. To answer Eddy's original question in light of this, while the standard error recovery is applicable on timeouts, the wait for all TTT-reponses, CmdSN gaps and StatSN acks is necessary. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Ken Sandars wrote: > Hi Bill, > > > >>-----Original Message----- >>From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On >>Behalf Of wrstuden@wasabisystems.com >>Sent: 30 January 2004 19:34 >>To: Mallikarjun C. >>Cc: Eddy Quicksall; ips@ietf.org >>Subject: Re: Fw: [Ips] iSCSI: abort task set >> >> >>On Fri, 30 Jan 2004, Mallikarjun C. wrote: >> >> >>>Eddy, >>> >>>Sorry for not responding sooner, I was checking my old >>>notes (but couldn't find relevant ones so far). >>> >>>The authors' advice on this is the following - >>> >>>The wait for affected tasks can be done (need to >>>pick a point in time as the reference for determining >>>the "affected" tasks, regardless of the # of sessions). However, an >>>alternative that's also legal is given below. >>> >>>Bullet (b) should have been: >>> >>>b) Waits for all target transfer tags to be responded to >>> and for all affected tasks in the task set to be >>> received (alternatively, the target may plug the CmdSN >>> gaps for unreceived commands just as if an abort request >>> is received for each individual affected task, refer >>> section 6.9 "SCSI timeouts") >> >>Abort Task Set has to plug the whole CmdSN window on each >>session?? That sounds excessive. Plugging the CmdSN hole for >>an Abort Task seems fine, since the initiator tells the >>target explicitly which CmdSN to abort (and also knows what >>the highest CmdSN used so far is). But with the Task Set >>commands, we _don't_ know the highest CmdSN the initiator has >>used, only the highest CmdSN we've seen and MaxCmdSN. >> > > > For the session the TMF was issued in, the CmdSN of the TMF > command is where it's up to. However I think this plugging > breaks down for a multiple-LUN target. Can the target assume > the missing tasks are for the affected LUN? > > > >>Also, for the TST 000b case, what does that mean for other >>initiators? > > [snip] > > Nothing - fallback to to the 'pick a point in time' method. > > > > Hope that helps, > > Ken Sandars > Elipsan UK > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 16:19:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17282 for ; Fri, 30 Jan 2004 16:19:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amg2x-0001sy-Gm for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:19:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ULJRxr007247 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:19:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amg2x-0001so-6J for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:19:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17257 for ; Fri, 30 Jan 2004 16:19:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amg2v-0000lU-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:19:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amg22-0000eL-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:18:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amg1Z-0000XZ-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amg1Y-0001dv-FH; Fri, 30 Jan 2004 16:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amg10-0001bk-8K for ips@optimus.ietf.org; Fri, 30 Jan 2004 16:17:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17176 for ; Fri, 30 Jan 2004 16:17:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amg0y-0000UO-00 for ips@ietf.org; Fri, 30 Jan 2004 16:17:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amg04-0000OK-00 for ips@ietf.org; Fri, 30 Jan 2004 16:16:29 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1Amfzl-0000I1-00 for ips@ietf.org; Fri, 30 Jan 2004 16:16:09 -0500 Received: from ivvt2dxrc11 (c-66-177-51-158.se.client2.attbi.com[66.177.51.158]) by comcast.net (sccrmhc12) with SMTP id <20040130211539012006ufl2e> (Authid: esquicksall); Fri, 30 Jan 2004 21:15:39 +0000 Message-ID: <000601c3e776$3601f140$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Mallikarjun C." Cc: References: <001d01c3e76b$8b867e70$7107a8c0@winminx> <401AC5BB.4040603@rose.hp.com> Subject: Re: Fw: [Ips] iSCSI: abort task set Date: Fri, 30 Jan 2004 16:15:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > the wait for all ... CmdSN gaps ... is necessary Does this mean that if an ABORT TASK SET is immediate. it can't be executed as immediate? (i.e., it must wait for all CmdSN's less than the ABORT TASK SET CmdSN to be received). If so, and the missing CmdSN's are from a connection that has stalled indefinatly (e.g. a stuck router), how long should the target wait? Time2Retain (actually, I don't think that is what Time2Retain is for)? Eddy ----- Original Message ----- From: "Mallikarjun C." To: "Ken Sandars" Cc: Sent: Friday, January 30, 2004 3:59 PM Subject: Re: Fw: [Ips] iSCSI: abort task set > >However I think this plugging > > breaks down for a multiple-LUN target. Can the target assume > > the missing tasks are for the affected LUN? > > No, not always. A very good point. Even though the > suggested "alternative" is an optimization for > tight-knit (i.e. rototilled) targets, it isn't generally > usable for multi-LU, strict-layered, targets. Now > I recall this is why we didn't put this "alternative" > in the spec to begin with (haven't found those notes...). > > So I now believe the "alternative" text in paranetheses > that was suggested is at best a fit for implementers > notes, if at all. > > To answer Eddy's original question in light of this, > while the standard error recovery is applicable on > timeouts, the wait for all TTT-reponses, CmdSN gaps > and StatSN acks is necessary. > > Thanks. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > > > Ken Sandars wrote: > > > Hi Bill, > > > > > > > >>-----Original Message----- > >>From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > >>Behalf Of wrstuden@wasabisystems.com > >>Sent: 30 January 2004 19:34 > >>To: Mallikarjun C. > >>Cc: Eddy Quicksall; ips@ietf.org > >>Subject: Re: Fw: [Ips] iSCSI: abort task set > >> > >> > >>On Fri, 30 Jan 2004, Mallikarjun C. wrote: > >> > >> > >>>Eddy, > >>> > >>>Sorry for not responding sooner, I was checking my old > >>>notes (but couldn't find relevant ones so far). > >>> > >>>The authors' advice on this is the following - > >>> > >>>The wait for affected tasks can be done (need to > >>>pick a point in time as the reference for determining > >>>the "affected" tasks, regardless of the # of sessions). However, an > >>>alternative that's also legal is given below. > >>> > >>>Bullet (b) should have been: > >>> > >>>b) Waits for all target transfer tags to be responded to > >>> and for all affected tasks in the task set to be > >>> received (alternatively, the target may plug the CmdSN > >>> gaps for unreceived commands just as if an abort request > >>> is received for each individual affected task, refer > >>> section 6.9 "SCSI timeouts") > >> > >>Abort Task Set has to plug the whole CmdSN window on each > >>session?? That sounds excessive. Plugging the CmdSN hole for > >>an Abort Task seems fine, since the initiator tells the > >>target explicitly which CmdSN to abort (and also knows what > >>the highest CmdSN used so far is). But with the Task Set > >>commands, we _don't_ know the highest CmdSN the initiator has > >>used, only the highest CmdSN we've seen and MaxCmdSN. > >> > > > > > > For the session the TMF was issued in, the CmdSN of the TMF > > command is where it's up to. However I think this plugging > > breaks down for a multiple-LUN target. Can the target assume > > the missing tasks are for the affected LUN? > > > > > > > >>Also, for the TST 000b case, what does that mean for other > >>initiators? > > > > [snip] > > > > Nothing - fallback to to the 'pick a point in time' method. > > > > > > > > Hope that helps, > > > > Ken Sandars > > Elipsan UK > > > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Jan 30 16:21:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17405 for ; Fri, 30 Jan 2004 16:21:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amg40-0001vV-Mr for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:20:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ULKWTT007399 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:20:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amg40-0001vG-Ie for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:20:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17338 for ; Fri, 30 Jan 2004 16:20:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amg3y-0000tz-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:20:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amg34-0000mp-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:19:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amg2W-0000fc-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amg2X-0001m8-8v; Fri, 30 Jan 2004 16:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amg1w-0001l6-DG for ips@optimus.ietf.org; Fri, 30 Jan 2004 16:18:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17209 for ; Fri, 30 Jan 2004 16:18:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amg1u-0000d1-00 for ips@ietf.org; Fri, 30 Jan 2004 16:18:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amg10-0000Ul-00 for ips@ietf.org; Fri, 30 Jan 2004 16:17:27 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1Amg0C-0000Oh-00 for ips@ietf.org; Fri, 30 Jan 2004 16:16:37 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 06F8D1C026DA; Fri, 30 Jan 2004 16:16:37 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 22A188009; Fri, 30 Jan 2004 13:12:02 -0800 (PST) Message-ID: <401AC9AB.7050901@rose.hp.com> Date: Fri, 30 Jan 2004 13:16:27 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: Fw: [Ips] iSCSI: abort task set References: <000a01c3e73f$46c99dc0$0303a8c0@ivvt2dxrc11> <401AA571.9000306@rose.hp.com> <001a01c3e772$fcf52c80$0303a8c0@ivvt2dxrc11> In-Reply-To: <001a01c3e772$fcf52c80$0303a8c0@ivvt2dxrc11> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The same method applies for either case, the TST field is however not relevant unless it is CLEAR TASK SET. The "point in time" should preferably immediately follow the reception of the TMF. BTW, now that I think more about it, the "alternative" text below is to be ignored - rototilled or otherwise. M Eddy Quicksall wrote: > When you say "pick a point in time" do you simply mean to use the CmdSN of > the ABORT TASK SET TMF for the given initiator and TST=001b? Or are you > applying this phrase to other initiators when TST is 000b? > > Eddy > > ----- Original Message ----- > From: "Mallikarjun C." > To: "Eddy Quicksall" > Cc: > Sent: Friday, January 30, 2004 1:41 PM > Subject: Re: Fw: [Ips] iSCSI: abort task set > > > >>Eddy, >> >>Sorry for not responding sooner, I was checking my old >>notes (but couldn't find relevant ones so far). >> >>The authors' advice on this is the following - >> >>The wait for affected tasks can be done (need to >>pick a point in time as the reference for determining >>the "affected" tasks, regardless of the # of sessions). >>However, an alternative that's also legal is given below. >> >>Bullet (b) should have been: >> >>b) Waits for all target transfer tags to be responded to >> and for all affected tasks in the task set to be >> received (alternatively, the target may plug the CmdSN >> gaps for unreceived commands just as if an abort request >> is received for each individual affected task, refer >> section 6.9 "SCSI timeouts") >> >>Note that the wait on StatSN ack is however >>mandatory. >> >>It is good to get this alternative/clarification into >>the final RFC. >> >>Thanks. >>-- >>Mallikarjun >> >>Mallikarjun Chadalapaka >>Networked Storage Architecture >>Network Storage Solutions >>Hewlett-Packard MS 5668 >>Roseville CA 95747 >>cbm [at] rose.hp.com >> >> >> >>Eddy Quicksall wrote: >> >> >>>Mallikarjun, >>> >>>I am really wondering what the target should do. Can you give some > > advice? > >>>It is clear what to do if the TMF is not immediate... the problem is: If >>>it is immediate, how can the target determine when "all affected tasks >>>in the task set" have been received? The target can't simply wait for >>>all earlier CmdSN's to be received or the target can deadlock if >>>multiple connections. >>> >>>Eddy >>> _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 16:37:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18793 for ; Fri, 30 Jan 2004 16:37:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgJW-000328-8T for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:36:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ULaYSj011654 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:36:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgJW-00031t-3p for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:36:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18784 for ; Fri, 30 Jan 2004 16:36:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgJU-0003HN-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:36:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgIc-00039j-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:35:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmgI6-00031d-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgI1-0002kV-Tk; Fri, 30 Jan 2004 16:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgHQ-0002jS-Eu for ips@optimus.ietf.org; Fri, 30 Jan 2004 16:34:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18516 for ; Fri, 30 Jan 2004 16:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgHO-0002y9-00 for ips@ietf.org; Fri, 30 Jan 2004 16:34:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgGP-0002qj-00 for ips@ietf.org; Fri, 30 Jan 2004 16:33:22 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AmgFU-0002jO-00 for ips@ietf.org; Fri, 30 Jan 2004 16:32:24 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1AmgE4-0005qn-00; Fri, 30 Jan 2004 21:30:56 +0000 From: "Ken Sandars" To: "'Eddy Quicksall'" , "'Mallikarjun C.'" Cc: Subject: RE: Fw: [Ips] iSCSI: abort task set Date: Fri, 30 Jan 2004 21:31:42 -0000 Message-ID: <001f01c3e778$89268280$7107a8c0@winminx> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <000601c3e776$3601f140$0303a8c0@ivvt2dxrc11> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Eddy, > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of Eddy Quicksall > Sent: 30 January 2004 21:16 > To: Mallikarjun C. > Cc: ips@ietf.org > Subject: Re: Fw: [Ips] iSCSI: abort task set > > > > the wait for all ... CmdSN gaps ... is necessary > > Does this mean that if an ABORT TASK SET is immediate. it > can't be executed as immediate? (i.e., it must wait for all > CmdSN's less than the ABORT TASK SET CmdSN to be received). Sort of like the spec should mandate ABORT TASK SET and CLEAR TASK SET MUST NOT be sent as immediate? I'd buy an iSCSI spec like that ;-) > > If so, and the missing CmdSN's are from a connection that has > stalled indefinatly (e.g. a stuck router), how long should > the target wait? Time2Retain (actually, I don't think that is > what Time2Retain is for)? I'm thinking that's an initiator problem ;-) Targets do the receive data sequence timeout thang on TTT, but isn't it up to the initiators to work out the news when ExpCmdSN isn't changing regardless of what the target sends back (in say NOP-IN pdus)? Cheers, Ken Sandars Elipsan UK > > Eddy > > ----- Original Message ----- > From: "Mallikarjun C." > To: "Ken Sandars" > Cc: > Sent: Friday, January 30, 2004 3:59 PM > Subject: Re: Fw: [Ips] iSCSI: abort task set > > > > >However I think this plugging > > > breaks down for a multiple-LUN target. Can the target > assume > the > > missing tasks are for the affected LUN? > > > > No, not always. A very good point. Even though the suggested > > "alternative" is an optimization for tight-knit (i.e. rototilled) > > targets, it isn't generally usable for multi-LU, strict-layered, > > targets. Now I recall this is why we didn't put this "alternative" > > in the spec to begin with (haven't found those notes...). > > > > So I now believe the "alternative" text in paranetheses > > that was suggested is at best a fit for implementers > > notes, if at all. > > > > To answer Eddy's original question in light of this, > > while the standard error recovery is applicable on > > timeouts, the wait for all TTT-reponses, CmdSN gaps > > and StatSN acks is necessary. > > > > Thanks. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm [at] rose.hp.com > > > > > > > > > > Ken Sandars wrote: > > > > > Hi Bill, > > > > > > > > > > > >>-----Original Message----- > > >>From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of > > >>wrstuden@wasabisystems.com > > >>Sent: 30 January 2004 19:34 > > >>To: Mallikarjun C. > > >>Cc: Eddy Quicksall; ips@ietf.org > > >>Subject: Re: Fw: [Ips] iSCSI: abort task set > > >> > > >> > > >>On Fri, 30 Jan 2004, Mallikarjun C. wrote: > > >> > > >> > > >>>Eddy, > > >>> > > >>>Sorry for not responding sooner, I was checking my old > notes (but > > >>>couldn't find relevant ones so far). > > >>> > > >>>The authors' advice on this is the following - > > >>> > > >>>The wait for affected tasks can be done (need to > > >>>pick a point in time as the reference for determining > > >>>the "affected" tasks, regardless of the # of sessions). > However, an > > >>>alternative that's also legal is given below. > > >>> > > >>>Bullet (b) should have been: > > >>> > > >>>b) Waits for all target transfer tags to be responded to > > >>> and for all affected tasks in the task set to be > > >>> received (alternatively, the target may plug the CmdSN > > >>> gaps for unreceived commands just as if an abort request > > >>> is received for each individual affected task, refer > > >>> section 6.9 "SCSI timeouts") > > >> > > >>Abort Task Set has to plug the whole CmdSN window on each > session?? > > >>That sounds excessive. Plugging the CmdSN hole for an Abort Task > > >>seems fine, since the initiator tells the target explicitly which > > >>CmdSN to abort (and also knows what the highest CmdSN used so far > > >>is). But with the Task Set commands, we _don't_ know the highest > > >>CmdSN the initiator has used, only the highest CmdSN > we've seen and > > >>MaxCmdSN. > > >> > > > > > > > > > For the session the TMF was issued in, the CmdSN of the > TMF command > > > is where it's up to. However I think this plugging > breaks down for > > > a multiple-LUN target. Can the target assume the missing > tasks are > > > for the affected LUN? > > > > > > > > > > > >>Also, for the TST 000b case, what does that mean for other > > >>initiators? > > > > > > [snip] > > > > > > Nothing - fallback to to the 'pick a point in time' method. > > > > > > > > > > > > Hope that helps, > > > > > > Ken Sandars > > > Elipsan UK > > > > > > > > > _______________________________________________ > > 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 From exim@www1.ietf.org Fri Jan 30 16:37:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18806 for ; Fri, 30 Jan 2004 16:37:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgJW-00032Q-RP for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:36:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ULaYan011672 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:36:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgJW-00032B-NC for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:36:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18788 for ; Fri, 30 Jan 2004 16:36:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgJU-0003HT-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:36:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgId-00039r-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:35:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmgI6-00031e-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgI4-0002kt-63; Fri, 30 Jan 2004 16:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgHU-0002ji-Pg for ips@optimus.ietf.org; Fri, 30 Jan 2004 16:34:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18526 for ; Fri, 30 Jan 2004 16:34:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgHS-0002yk-00 for ips@ietf.org; Fri, 30 Jan 2004 16:34:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgGW-0002rh-00 for ips@ietf.org; Fri, 30 Jan 2004 16:33:29 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1AmgFw-0002lM-00 for ips@ietf.org; Fri, 30 Jan 2004 16:32:52 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id BF7A91C02431; Fri, 30 Jan 2004 13:32:52 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 136118009; Fri, 30 Jan 2004 13:28:18 -0800 (PST) Message-ID: <401ACD7B.1060400@rose.hp.com> Date: Fri, 30 Jan 2004 13:32:43 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: Fw: [Ips] iSCSI: abort task set References: <001d01c3e76b$8b867e70$7107a8c0@winminx> <401AC5BB.4040603@rose.hp.com> <000601c3e776$3601f140$0303a8c0@ivvt2dxrc11> In-Reply-To: <000601c3e776$3601f140$0303a8c0@ivvt2dxrc11> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddy Quicksall wrote: >>the wait for all ... CmdSN gaps ... is necessary > > > Does this mean that if an ABORT TASK SET is immediate. it can't be executed > as immediate? (i.e., it must wait for all CmdSN's less than the ABORT TASK > SET CmdSN to be received). Yes. 10.5.1 already states for this reason: If the task management request is marked for immediate delivery, it must be considered immediately for execution, but the operations involved (all or part of them) may be postponed to allow the target to receive all relevant tasks. > > If so, and the missing CmdSN's are from a connection that has stalled > indefinatly (e.g. a stuck router), how long should the target wait? > Time2Retain (actually, I don't think that is what Time2Retain is for)? No, it is not that. This is in the implementation territory, and I would simply say that standard error recovery should be used for non-responding connections with implementation-defined timeouts. Mallikarjun > > Eddy > > ----- Original Message ----- > From: "Mallikarjun C." > To: "Ken Sandars" > Cc: > Sent: Friday, January 30, 2004 3:59 PM > Subject: Re: Fw: [Ips] iSCSI: abort task set > > > >>>However I think this plugging >> >> > breaks down for a multiple-LUN target. Can the target assume >> > the missing tasks are for the affected LUN? >> >>No, not always. A very good point. Even though the >>suggested "alternative" is an optimization for >>tight-knit (i.e. rototilled) targets, it isn't generally >>usable for multi-LU, strict-layered, targets. Now >>I recall this is why we didn't put this "alternative" >>in the spec to begin with (haven't found those notes...). >> >>So I now believe the "alternative" text in paranetheses >>that was suggested is at best a fit for implementers >>notes, if at all. >> >>To answer Eddy's original question in light of this, >>while the standard error recovery is applicable on >>timeouts, the wait for all TTT-reponses, CmdSN gaps >>and StatSN acks is necessary. >> >>Thanks. >>-- >>Mallikarjun >> >>Mallikarjun Chadalapaka >>Networked Storage Architecture >>Network Storage Solutions >>Hewlett-Packard MS 5668 >>Roseville CA 95747 >>cbm [at] rose.hp.com >> _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 16:45:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22279 for ; Fri, 30 Jan 2004 16:45:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgS6-0003fO-J1 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:45:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ULjQUE014093 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgS6-0003fE-Be for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:45:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21706 for ; Fri, 30 Jan 2004 16:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgS4-0004Nz-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:45:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgRB-0004Hj-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:44:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmgQi-0004Bp-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgQj-0003Vm-Az; Fri, 30 Jan 2004 16:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgQE-0003VS-F8 for ips@optimus.ietf.org; Fri, 30 Jan 2004 16:43:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19620 for ; Fri, 30 Jan 2004 16:43:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgQC-0004BN-00 for ips@ietf.org; Fri, 30 Jan 2004 16:43:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgPF-00043l-00 for ips@ietf.org; Fri, 30 Jan 2004 16:42:30 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AmgOf-0003xN-00 for ips@ietf.org; Fri, 30 Jan 2004 16:41:54 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1AmgNG-0006qR-00; Fri, 30 Jan 2004 21:40:26 +0000 From: "Ken Sandars" To: "'Ken Sandars'" , "'Eddy Quicksall'" , "'Mallikarjun C.'" Cc: Subject: RE: Fw: [Ips] iSCSI: abort task set Date: Fri, 30 Jan 2004 21:41:18 -0000 Message-ID: <002001c3e779$dd211de0$7107a8c0@winminx> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Eddy, (Sorry, quick rethink. This time using a brain...) > > Does this mean that if an ABORT TASK SET is immediate. it > > can't be executed as immediate? (i.e., it must wait for all > > CmdSN's less than the ABORT TASK SET CmdSN to be received). > > Sort of like the spec should mandate ABORT TASK SET and > CLEAR TASK SET MUST NOT be sent as immediate? I'd buy an > iSCSI spec like that ;-) > But if the command window is closed, the TMF can't be sent, so that doesn't help. So yes, it makes sense to allow the immediate ABORT/CLEAR TASK set in, and then as part of its execution make it wait for the missing commands. Thanks, Ken Sandars Elipsan UK _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 16:48:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25939 for ; Fri, 30 Jan 2004 16:48:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgV5-00040n-Cn for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:48:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ULmVqN015415 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 16:48:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgV5-00040Y-7m for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:48:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25378 for ; Fri, 30 Jan 2004 16:48:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgV3-0004mb-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:48:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgUA-0004eW-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:47:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmgTd-0004XY-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 16:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgTe-0003qe-4r; Fri, 30 Jan 2004 16:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgT7-0003lt-Fv for ips@optimus.ietf.org; Fri, 30 Jan 2004 16:46:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22916 for ; Fri, 30 Jan 2004 16:46:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmgT5-0004VU-00 for ips@ietf.org; Fri, 30 Jan 2004 16:46:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgS3-0004Nr-00 for ips@ietf.org; Fri, 30 Jan 2004 16:45:23 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AmgR7-0004Bo-00 for ips@ietf.org; Fri, 30 Jan 2004 16:44:25 -0500 Received: from ivvt2dxrc11 (c-66-177-51-158.se.client2.attbi.com[66.177.51.158]) by comcast.net (sccrmhc11) with SMTP id <2004013021435501100gd18ne> (Authid: esquicksall); Fri, 30 Jan 2004 21:43:55 +0000 Message-ID: <001701c3e77a$28e68c10$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Mallikarjun C." Cc: References: <001d01c3e76b$8b867e70$7107a8c0@winminx> <401AC5BB.4040603@rose.hp.com> <000601c3e776$3601f140$0303a8c0@ivvt2dxrc11> <401ACD7B.1060400@rose.hp.com> Subject: Re: Fw: [Ips] iSCSI: abort task set Date: Fri, 30 Jan 2004 16:43:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok ... got it. It turns out that my NOP-In's will catch a stuck router (I forgot about that). Eddy ----- Original Message ----- From: "Mallikarjun C." To: "Eddy Quicksall" Cc: Sent: Friday, January 30, 2004 4:32 PM Subject: Re: Fw: [Ips] iSCSI: abort task set > Eddy Quicksall wrote: > > >>the wait for all ... CmdSN gaps ... is necessary > > > > > > Does this mean that if an ABORT TASK SET is immediate. it can't be executed > > as immediate? (i.e., it must wait for all CmdSN's less than the ABORT TASK > > SET CmdSN to be received). > > Yes. 10.5.1 already states for this reason: > > If the task management request is marked for immediate delivery, it > must be considered immediately for execution, but the operations > involved (all or part of them) may be postponed to allow the target > to receive all relevant tasks. > > > > > If so, and the missing CmdSN's are from a connection that has stalled > > indefinatly (e.g. a stuck router), how long should the target wait? > > Time2Retain (actually, I don't think that is what Time2Retain is for)? > > No, it is not that. This is in the implementation territory, > and I would simply say that standard error recovery should be > used for non-responding connections with implementation-defined > timeouts. > > > Mallikarjun > > > > > > Eddy > > > > ----- Original Message ----- > > From: "Mallikarjun C." > > To: "Ken Sandars" > > Cc: > > Sent: Friday, January 30, 2004 3:59 PM > > Subject: Re: Fw: [Ips] iSCSI: abort task set > > > > > > > >>>However I think this plugging > >> > >> > breaks down for a multiple-LUN target. Can the target assume > >> > the missing tasks are for the affected LUN? > >> > >>No, not always. A very good point. Even though the > >>suggested "alternative" is an optimization for > >>tight-knit (i.e. rototilled) targets, it isn't generally > >>usable for multi-LU, strict-layered, targets. Now > >>I recall this is why we didn't put this "alternative" > >>in the spec to begin with (haven't found those notes...). > >> > >>So I now believe the "alternative" text in paranetheses > >>that was suggested is at best a fit for implementers > >>notes, if at all. > >> > >>To answer Eddy's original question in light of this, > >>while the standard error recovery is applicable on > >>timeouts, the wait for all TTT-reponses, CmdSN gaps > >>and StatSN acks is necessary. > >> > >>Thanks. > >>-- > >>Mallikarjun > >> > >>Mallikarjun Chadalapaka > >>Networked Storage Architecture > >>Network Storage Solutions > >>Hewlett-Packard MS 5668 > >>Roseville CA 95747 > >>cbm [at] rose.hp.com > >> > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Jan 30 17:58:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17918 for ; Fri, 30 Jan 2004 17:58:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amhao-0001YI-1H for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 17:58:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UMwUoK005963 for ips-archive@odin.ietf.org; Fri, 30 Jan 2004 17:58:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amhan-0001Y6-SL for ips-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 17:58:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17246 for ; Fri, 30 Jan 2004 17:58:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amhal-00073X-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 17:58:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmhZx-0006w1-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 17:57:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmhZN-0006oz-00 for ips-web-archive@ietf.org; Fri, 30 Jan 2004 17:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmhZM-0001Nb-1K; Fri, 30 Jan 2004 17:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmhYq-0001N6-FX for ips@optimus.ietf.org; Fri, 30 Jan 2004 17:56:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15242 for ; Fri, 30 Jan 2004 17:56:24 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmhYn-0006mU-00 for ips@ietf.org; Fri, 30 Jan 2004 17:56:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmhY0-0006gM-00 for ips@ietf.org; Fri, 30 Jan 2004 17:55:37 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AmhXS-0006Ze-00 for ips@ietf.org; Fri, 30 Jan 2004 17:55:02 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id CAA2540152; Fri, 30 Jan 2004 17:54:59 -0500 (EST) Date: Fri, 30 Jan 2004 14:54:48 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Mallikarjun C." Cc: Eddy Quicksall , ips@ietf.org Subject: Re: Fw: [Ips] iSCSI: abort task set In-Reply-To: <401ABA2C.807@rose.hp.com> Message-ID: References: <000a01c3e73f$46c99dc0$0303a8c0@ivvt2dxrc11> <401AA571.9000306@rose.hp.com> <401ABA2C.807@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Fri, 30 Jan 2004, Mallikarjun C. wrote: > The term "plugging the CmdSN gap" doesn't mean > shutting the CmdSN window down. If the target > received a CmdSN X but has not yet received a > CmdSN Y within the CmdSN window (where Y < X, > in Serial Number Arithmetic), then Y is the > "CmdSN gap" (not the valid window > X). To > summarize, a "CmdSN gap" must meet two conditions > a) target deterministically knows it's already > issued by the initiator, and, b) it has not yet > arrived. > > In this example, an abort operation for CmdSN=Y > simply "plugs" the CmdSN gap, i.e. the CmdSN is > considered received and aborted from now on. This > lets the window slide (standard behavior today). > There's no reason to disallow the same behavior > when multiple tasks are being aborted. > > Plugging the CmdSN gaps at a point in time > is not a complex operation. And it doesn't affect > quiescent initiators at all. I agree that the act of plugging gaps is not hard. My question though is about ambiguity as to what gaps to plug. :-) My original concern was about a command CmdSN=Z where X (received) < Z. That's why I was talking about plugging the whole command window. And on other sessions (TST=000b), since we don't have a CmdSN on the command to tell us if there are any commands 'Z', we do have an ambiguity. As Ken mentioned, we have a bigger concern. For the example above, how do we know if CmdSN=Y is for the LU on which we're aborting the set? > > Finally, since iSCSI tasks don't get passed to the SCSI layer until the > > CmdSN window is satisfied, are CmdSN-pending tasks really in the SCSI > task > > set? > > I assme you mean "commands are reordered" when you > say "CmdSN window is satisfied". One could make an No, I meant the commands that are queued so they don't get reordered. :-) > argument that the tasks wating in the transport are > not in a SCSI task set. But we decided way back that > iSCSI should hide the queueing that it introduced in > the transport, so application clients won't receive > some task responses after the task set is aborted > (also check the command ordering draft for a related > discussion). Well, we trade one problem (responses after aborting the task set since the commands were queued and went forward after the abort) for another (ambiguities as to which unreceived tasks should be aborted). I was about to suggest that for multi-LU targets we could just create CmdSN-plugs that had an explicit LUN. If a command comes in with the same CmdSN as a plug but for a different LUN, we would silently unplug & let the command through. Unfortunately it won't work. The problem though is that we could have a situation where the command window moves before a lost command is resent. In that case the initiator thinks a command (for a different LUN than the abort task set) has been received since we moved ExpCmdSN, but the target doesn't have it, since it thought it was aborted. While I agree that we should hide iSCSI's command queuing from end clients, I don't think we need to hide it from the initiator. To that end, I propose that we: 1) Change (or clarify) ABORT TASK SET and CLEAR TASK SET to only apply to commands that have been "delivered for execution"; for commands with CmdSNs that have been successfully received. Commands held to prevent out-of-order SCSI delivery are NOT touched. 2) mandate an initiator's behavior when presented with an ABORT TASK SET or CLEAR TASK SET operation to be: a) issue ABORT TASKs for all issued commands not then acknowledged by the target (*) and then b) issue the ABORT or CLEAR TASK SET. (*) Specifically commands with CmdSN >= last received ExpCmdSN. This may mean aborting immediate commands if there were any in the window. This way all the tasks the initiator thinks are outstanding on the LU get aborted and no others. We hide iSCSI's queuing from end clients yet leave no opportunity for tasks to just be dropped. As for other sessions (TST=000b), the "Abort" happened at a time when only the commands delivered for execution were in the task set. > > Is there any sort of time out? > > Not that the spec specifies. Standard error recovery > is applicable on timeouts. So just to be clear, say one connection in the session is down. Or in the TST=000b case a different session accessing this LU is ill. We will end up waiting for error recovery to happen before responding to the TMR? Which can be tens of seconds if the connection or session times out through Time2Retain? Just making sure... > Hope this helps. It does. I think this discussion is productive. I know my concerns have been refined because of it. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Jan 31 09:21:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21870 for ; Sat, 31 Jan 2004 09:21:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amvzb-00082Q-8N for ips-archive@odin.ietf.org; Sat, 31 Jan 2004 09:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0VEL3XT030892 for ips-archive@odin.ietf.org; Sat, 31 Jan 2004 09:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amvza-00082B-VR for ips-web-archive@optimus.ietf.org; Sat, 31 Jan 2004 09:21:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21842 for ; Sat, 31 Jan 2004 09:21:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmvzZ-0006yc-00 for ips-web-archive@ietf.org; Sat, 31 Jan 2004 09:21:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amvyd-0006rO-00 for ips-web-archive@ietf.org; Sat, 31 Jan 2004 09:20:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amvxg-0006kc-00 for ips-web-archive@ietf.org; Sat, 31 Jan 2004 09:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amvxc-0007sb-Tl; Sat, 31 Jan 2004 09:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amvwf-0007ly-1K for ips@optimus.ietf.org; Sat, 31 Jan 2004 09:18:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21763 for ; Sat, 31 Jan 2004 09:17:58 -0500 (EST) From: Rod.Harrison@windriver.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amvwd-0006cA-00 for ips@ietf.org; Sat, 31 Jan 2004 09:17:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amvvf-0006Vh-00 for ips@ietf.org; Sat, 31 Jan 2004 09:16:59 -0500 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx with esmtp (Exim 4.12) id 1Amvuj-0006J4-00 for ips@ietf.org; Sat, 31 Jan 2004 09:16:01 -0500 Received: from ala-mta03.windriver.com (ala-mta03 [147.11.57.132]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA11136; Sat, 31 Jan 2004 06:15:17 -0800 (PST) Received: by ala-mta03.wrs.com with Internet Mail Service (5.5.2653.19) id ; Sat, 31 Jan 2004 06:15:21 -0800 Message-ID: <83627E19A5D0C448BFAAF40873768B1FB38D63@unknown-74-22.windriver.com> To: rmangamuri@istor.com Cc: ips@ietf.org, wrstuden@wasabisystems.com Subject: RE: [Ips] Max iSCSI Sessions supported Date: Sat, 31 Jan 2004 06:15:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Ramesh, I think you want to use the same ISID and connect to a portal in a different target portal group on the target. That allows the target to understand the sessions are from the same initiator and doesn't violate the parallel nexus rule. - Rod -----Original Message----- From: Ramesh Mangamuri [mailto:rmangamuri@istor.com] Sent: Thursday, January 29, 2004 7:44 PM To: wrstuden@wasabisystems.com Cc: ips@ietf.org Subject: RE: [Ips] Max iSCSI Sessions supported Importance: High Here are some questions again. 1) What if we have multi-pathing software installed on the Host OS(Initiator) ? 2) How can we generate different ISIDs from the same initiator.? Is this one configurable value? More later ..., Ramesh -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] Sent: Thursday, January 29, 2004 5:20 PM To: Ramesh Mangamuri Cc: ips@ietf.org Subject: Re: [Ips] Max iSCSI Sessions supported On Thu, 29 Jan 2004, Ramesh Mangamuri wrote: > Folks, > > I understand that there is possibility that there can be multiple > connections in an iSCSI session. But, Can an iSCSI initiator have more > than one active iSCSI session simultaneously with a given target. Yes and no. Strictly speaking, no. Any attempt to open a second session with the target by a given initiator would trigger session reinstatement. This represents the fact that there can be only one I_T nexus. However since the identifier for an initiator is both the initiator name and the ISID, the same initiator name can be used on different sessions if they have different ISIDs. This situation, though, can be dangerous and should be avoided; the target would appear as two different SCSI devices to the initiator's OS. Most OSs won't deal well with that situation. For instance Microsoft Windows's auto-mounting of partitions could cause the partitions on the disk to be mounted twice. Take care, 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 exim@www1.ietf.org Sat Jan 31 16:32:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06090 for ; Sat, 31 Jan 2004 16:32:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An2iv-00037g-57 for ips-archive@odin.ietf.org; Sat, 31 Jan 2004 16:32:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0VLWHAU011998 for ips-archive@odin.ietf.org; Sat, 31 Jan 2004 16:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An2iu-00037R-VC for ips-web-archive@optimus.ietf.org; Sat, 31 Jan 2004 16:32:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06083 for ; Sat, 31 Jan 2004 16:32:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An2it-0000Z7-00 for ips-web-archive@ietf.org; Sat, 31 Jan 2004 16:32:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An2i0-0000TH-00 for ips-web-archive@ietf.org; Sat, 31 Jan 2004 16:31:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1An2hn-0000NF-00 for ips-web-archive@ietf.org; Sat, 31 Jan 2004 16:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An2hi-0002zY-5Z; Sat, 31 Jan 2004 16:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An2h3-0002xN-Ol for ips@optimus.ietf.org; Sat, 31 Jan 2004 16:30:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06028 for ; Sat, 31 Jan 2004 16:30:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An2h1-0000MT-00 for ips@ietf.org; Sat, 31 Jan 2004 16:30:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An2g8-0000GA-00 for ips@ietf.org; Sat, 31 Jan 2004 16:29:24 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1An2ff-00009b-00 for ips@ietf.org; Sat, 31 Jan 2004 16:28:55 -0500 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] iSCSI: Correct value for ExpDataSN for bidirectional commands X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Sat, 31 Jan 2004 13:27:08 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717A3@mail1irv.inside.istor.com> Thread-Topic: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Thread-Index: AcPnc+7kFxpMg6LQSzmCS94RimDCegAy5sDA From: "Ramesh Mangamuri" To: "Ken Sandars" , "Julian Satran" , "Mallikarjun C." Cc: , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Ken/Julian: I have another proposal here for section 10.4.8: Suggestion --------------------------- 10.4.8 ExpDataSN The number of Data-In (read) PDUs (for bidirectional commands this is R2Ts + Data-Ins) the target has sent for the command. This field is reserved if the response code is not Command Completed at Target, or the command is Write only command. How does this sound??? -Rams =20 =09 -----Original Message----- From: Ken Sandars [mailto:ksandars@elipsan.com]=20 Sent: Friday, January 30, 2004 12:57 PM To: 'Julian Satran'; 'Mallikarjun C.' Cc: pat_thaler@agilent.com; ips@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Hi Julo, As requested, two alternative proposals for section 10.4.8: Suggestion 1 -------------------------- 10.4.8 ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for the command. This field is reserved if the response code is not Command Completed at Target. Suggestion 2 -------------------------- 10.4.8 ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for the command. This field is reserved if the response code is not Command Completed at Target or the target sent no Data-In PDUs for the command. ---------------------------------------- I'm more than happy with any answer which clarifies when the field is reserved. Thanks, Ken Sandars Elipsan UK > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On=20 > Behalf Of Mallikarjun C. > Sent: 30 January 2004 20:29 > To: Ken Sandars > Cc: 'Julian Satran'; pat_thaler@agilent.com; ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for=20 > bidirectional commands >=20 >=20 > Ken, >=20 > I am not sure we need to restrict the wording > to commands with at least one Data-In PDU. Do > you see an issue? >=20 > In any case, if you have a specific wording suggestion, > please send it to Julian directly (he owns the pen). >=20 > Regards. >=20 > Mallikarjun >=20 >=20 >=20 > Ken Sandars wrote: >=20 > > Hi Mallikarjun, > >=20 > > One final clarification request, and I can sleep easy on=20 > this topic! > >=20 > > Will the new wording for 10.4.8 be more general to indicate that=20 > > ExpDataSN is the number of DataIn and R2T PDUs that were sent? > >=20 > > Is this field only valid for commands which have at least=20 > one Data-In=20 > > PDU? > >=20 > >=20 > > Thanks again, > > Ken Sandars > > Elipsan UK > >=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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips