From mailman-bounces@ietf.org Mon Nov 1 06:01:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16454 for ; Mon, 1 Nov 2004 06:01:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COaB8-0004Lb-Db for ips-web-archive@ietf.org; Mon, 01 Nov 2004 06:16:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZJT-0004M8-N0 for ips-web-archive@ietf.org; Mon, 01 Nov 2004 05:21:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ips-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:06:48 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ips-web-archive@ietf.org: List Password // URL ---- -------- ips@ietf.org epceek https://www1.ietf.org/mailman/options/ips/ips-web-archive%40ietf.org From ips-bounces@ietf.org Mon Nov 1 21:15:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03950 for ; Mon, 1 Nov 2004 21:15:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COoRi-0003tc-5g for ips-web-archive@ietf.org; Mon, 01 Nov 2004 21:30:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnq4-0008IF-C9; Mon, 01 Nov 2004 20:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnW2-0000Sv-KV for ips@megatron.ietf.org; Mon, 01 Nov 2004 20:31:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00612 for ; Mon, 1 Nov 2004 20:31:15 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COnl3-000326-BG for ips@ietf.org; Mon, 01 Nov 2004 20:46:49 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id E8425C91F; Mon, 1 Nov 2004 17:31:15 -0800 (PST) Received: from [127.0.0.1] (dhcp-roseor-beb159.rose.hp.com [15.23.141.159]) by rosemail.rose.hp.com (Postfix) with ESMTP id C8DA1835A; Mon, 1 Nov 2004 17:31:15 -0800 (PST) Message-ID: <4186E359.2040704@rose.hp.com> Date: Mon, 01 Nov 2004 17:31:05 -0800 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pittman, Joseph" Subject: Re: [Ips] iSCSI: Recovering from DataDigest error on SCSI_CMD PDU with ImmediateData References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit > 1) Can anyone think of a situation where the PROPOSED RECOVERY ACTION > would not sufficiently handle the error? The Error Recovery Team discussed this in great detail during 2001 and concluded that the proposed action is problematic for technical and implementation reasons. Consequently, the RFC is quite unambiguous that accepting or discarding is at the PDU granularity - partial PDUs are not consumed on the receiver and no partial PDU recovery either. > 2) Would a target behaving in this way be in definite violation of the > spec? Or are there perhaps some other statements in the spec which > would render this behavior legitimate? I believe it would be a violation. The spec is very explicit about your scenario. In addition to the text you quoted, section 6.7 further says the following: "....(for immediate data in a command PDU, non-data PDU rule below applies),...." and the non-data PDU rule says: "In case of immediate data being present on a discarded command, the immediate data is implicitly recovered when the task is retried...." Sorry.... -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Pittman, Joseph wrote: > On August 3-4 2004, I posed a question to this mailing list about the > legitimacy of the following behavior on the part of an iSCSI target: > > - Target receives SCSI_CMD PDU with Immediate Data attached > - Target temporarily has no room to record immediate data, and > so discards it > - Target gets around to processing SCSI Write command > - Target uses R2T to request (re-)transmission of the FirstBurst > of data > > The answer I received from the iSCSI spec authors (Thanks!) was that > this behavior is acceptable (especially in an error situation), and a > compliant initiator MUST provide the data (again) in response to > the R2T in this situation. > > > Now, I have a question about a different error condition involving > ImmediateData -- a DataDigest error. > > Consider a hypothetical iSCSI target with the following pipelined > architecture for handling inbound data: > > +----------------------+ > | iSCSI Session Layer | - Receives PDU headers > +----------------------+ - Performs iSCSI session management > - Drives SCSI data transfer > > +----------------------+ > | PDU Processing Layer | - Forwards PDU headers immediately upon > receipt, > +----------------------+ along with HeaderDigest valid indication > - Holds data segments in layer-private memory > - Verifies DataDigest values, and reports > detected errors, only when data is forwarded > up to the session layer > > +----------------------+ > | TCP/IP, NIC, etc. | > +----------------------+ > > > Consider the handling by this architecture of a data digest error > on a SCSI_CMD PDU with ImmediateData. > > 1) The session layer would begin processing the SCSI command (and > possibly some others later in the command sequence). > > 2) The session layer would NOT know about the data digest error yet, > since that specific error is not recognized until the data is > later retrieved as part of the data transfer phase > > 3) So the session layer would NOT send a Reject PDU > > 4) When the session layer goes to retrieve the immediate data which > is being held in the PDU processing Layer, then the session layer > would learn of the data digest error > > 5) PROPOSED RECOVERY ACTION: The session layer would discard the > immediate data, and use R2T to request retransmission by the > initiator. > > > Practically speaking, I think the proposed recovery action would be > guaranteed to work. Because, from the initiator's point of view, > the target would be behaving exactly as described in the August 3/4 > discussion mentioned above ("drop ImmData due to resource constraints"). > > I am, however, aware of the following statement in the spec surrounding > the handling of data digest errors: > > 6.7 Digest Errors > > When a target receives any iSCSI PDU with a payload digest error, it > MUST answer with a Reject PDU with a reason code of > Data-Digest-Error and discard the PDU. > > > Two questions: > > 1) Can anyone think of a situation where the PROPOSED RECOVERY ACTION > would not sufficiently handle the error? > > 2) Would a target behaving in this way be in definite violation of the > spec? Or are there perhaps some other statements in the spec which > would render this behavior legitimate? > > An authoritative ruling from some of the specification authors and > experts would be GREATLY appreciated. > > > Thanks very much 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 ips-bounces@ietf.org Tue Nov 2 06:48:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09539 for ; Tue, 2 Nov 2004 06:48:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COxO8-0007VV-OY for ips-web-archive@ietf.org; Tue, 02 Nov 2004 07:03:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COwvc-00054S-4E; Tue, 02 Nov 2004 06:34:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COwtl-0004Gz-SU for ips@megatron.ietf.org; Tue, 02 Nov 2004 06:32:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08706 for ; Tue, 2 Nov 2004 06:32:23 -0500 (EST) Received: from web50401.mail.yahoo.com ([206.190.38.66]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1COx8h-0007D1-8Z for ips@ietf.org; Tue, 02 Nov 2004 06:48:02 -0500 Message-ID: <20041102113141.61528.qmail@web50401.mail.yahoo.com> Received: from [203.187.215.134] by web50401.mail.yahoo.com via HTTP; Tue, 02 Nov 2004 03:31:41 PST Date: Tue, 2 Nov 2004 03:31:41 -0800 (PST) From: ulka vaze To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ips] why microsoft initiator sends mode sense X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi all, I am testing my iscsi target developed on MAC OS X.Initially after LOgin is complete microsoft initiator sends report Luns then Inquiry and then Read capacity.After that it is sending read 10 with data transfer length 512.Now in response to Read10 i send DATA _IN pdu which has 512 bytes of data segment which contains the data that i get from MAC's scsi layer.I set the f=1 because only one data-in pdu ,i am setting status bit 1 and sending status as good. After receiving this response microsoft initiator sends mode sense and asks for all mode pagess.I want to know what could be the reason for this? Also it exposes device with device tyep unknown and number -1 what is the problem? Pl. help i am badly stuck here . Thanks ulka __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Nov 2 09:46:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25334 for ; Tue, 2 Nov 2004 09:46:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0Az-0003DZ-Cj for ips-web-archive@ietf.org; Tue, 02 Nov 2004 10:02:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzk3-0002NT-TC; Tue, 02 Nov 2004 09:34:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzdj-0007dv-1B for ips@megatron.ietf.org; Tue, 02 Nov 2004 09:28:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24012 for ; Tue, 2 Nov 2004 09:28:01 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COzsq-0002oN-To for ips@ietf.org; Tue, 02 Nov 2004 09:43:41 -0500 Received: from [24.10.156.180] (c-24-10-156-180.client.comcast.net[24.10.156.180]) by comcast.net (sccrmhc13) with SMTP id <200411021427290160011ic2e>; Tue, 2 Nov 2004 14:27:29 +0000 In-Reply-To: <20041102113141.61528.qmail@web50401.mail.yahoo.com> References: <20041102113141.61528.qmail@web50401.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <52CE9482-2CDB-11D9-8844-000393A22C62@ieee.org> Content-Transfer-Encoding: 7bit From: Pat LaVarre Subject: Re: [Ips] why microsoft initiator sends mode sense Date: Tue, 2 Nov 2004 07:27:28 -0700 To: ulka vaze X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Ulka V: As yet I know very nearly zero of iSCSI ... but speaking of SCSI generally, as in the t10.org texts, I can say: > microsoft initiator > sends mode sense and asks for all mode pagess.I want > to know what could be the reason for this? When PDT = x00 = DASD = HDD/ Flash, a fetch of all mode pages includes the header which includes the DSP ("device specific parameter") which includes a bit to say if the disk is rewritable, read-only, or absent. > microsoft > initiator sends report Luns then Inquiry and then Read > capacity.After that it is sending read 10 with data > transfer length 512. > ... > device tyep unknown To me, "device type" = "peripheral device type" = PDT = mask x1F of byte 0 of op x12 "INQUIRY" data ... so if the Inquiry went well, I don't understand how the device type can be unknown. Pat LaVarre _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Nov 3 10:08:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16560 for ; Wed, 3 Nov 2004 10:08:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMzP-0007Eq-Vr for ips-web-archive@ietf.org; Wed, 03 Nov 2004 10:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMhd-0002P7-Ro; Wed, 03 Nov 2004 10:05:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMYp-0006AW-ID for ips@megatron.ietf.org; Wed, 03 Nov 2004 09:56:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15157 for ; Wed, 3 Nov 2004 09:56:29 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMoA-0006vB-C6 for ips@ietf.org; Wed, 03 Nov 2004 10:12:22 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc12) with SMTP id <20041103145555012009rhfhe> (Authid: esquicksall); Wed, 3 Nov 2004 14:55:55 +0000 Message-ID: <000601c4c1b5$36c79f70$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Wed, 3 Nov 2004 09:55:48 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Ips] copyright notice X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1240923562==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a This is a multi-part message in MIME format. --===============1240923562== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C4C18B.4B68C9B0" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C4C18B.4B68C9B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I want to do cut and past's from RFC 3720 to some work I'm doing for = FAIS (T11.5). But there is a copyright notice in 3720. Is it legal for me to do the cut and past's? If so, should I use some = particular notation that it came from RFC 3720? Eddy ------=_NextPart_000_0003_01C4C18B.4B68C9B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I want to do cut and = past=92s from RFC=20 3720 to some work I=92m doing for FAIS (T11.5). But there is a = copyright=20 notice in 3720.

Is it legal for me to do = the cut and=20 past=92s? If so, should I use some particular notation that it came from = RFC=20 3720?

Eddy

 

------=_NextPart_000_0003_01C4C18B.4B68C9B0-- --===============1240923562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1240923562==-- From ips-bounces@ietf.org Wed Nov 3 13:16:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04399 for ; Wed, 3 Nov 2004 13:16:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPw5-0003Og-Tv for ips-web-archive@ietf.org; Wed, 03 Nov 2004 13:32:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPVJ-0002UK-Fk; Wed, 03 Nov 2004 13:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPO8-0000wv-8G for ips@megatron.ietf.org; Wed, 03 Nov 2004 12:57:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02787 for ; Wed, 3 Nov 2004 12:57:37 -0500 (EST) From: bill@strahm.net Received: from smtpout01-03.mesa1.secureserver.net ([64.202.165.78]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CPPdL-0002tq-8k for ips@ietf.org; Wed, 03 Nov 2004 13:13:33 -0500 Received: (qmail 16863 invoked from network); 3 Nov 2004 17:56:55 -0000 Received: from unknown (HELO webmail04.mesa1.secureserver.net) (64.202.166.125) by smtpout01-03.mesa1.secureserver.net with SMTP; 3 Nov 2004 17:56:55 -0000 Received: (qmail 14147 invoked by uid 99); 3 Nov 2004 17:56:55 -0000 Message-ID: <20041103175655.14146.qmail@webmail04.mesa1.secureserver.net> Date: Wed, 3 Nov 2004 10:56:55 -0700 Subject: RE: [Ips] copyright notice To: Eddy Quicksall MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Not sure this is helpfull or not... Why would a reference with a pointer to 3720 work ? I am not a lawyer (nor do I play one on TV) so I won't advise you on what consitutes fair use Bill > -------- Original Message -------- > Subject: [Ips] copyright notice > From: "Eddy Quicksall" > Date: Wed, November 03, 2004 6:55 am > To: ips@ietf.org > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Nov 3 13:46:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07050 for ; Wed, 3 Nov 2004 13:46:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQP9-0004FV-Ni for ips-web-archive@ietf.org; Wed, 03 Nov 2004 14:02:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQ7V-0002MC-4t; Wed, 03 Nov 2004 13:44:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPyd-0000ED-OB for ips@megatron.ietf.org; Wed, 03 Nov 2004 13:35:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05834 for ; Wed, 3 Nov 2004 13:35:21 -0500 (EST) From: elizabeth.rodriguez@dothill.com Received: from artecon.dothill.com ([155.254.128.254] helo=dothill.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQE0-0003r6-3c for ips@ietf.org; Wed, 03 Nov 2004 13:51:17 -0500 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id iA3ITSLl005170 for ; Wed, 3 Nov 2004 10:29:28 -0800 (PST) Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id <4M1VAT9L>; Wed, 3 Nov 2004 10:33:26 -0800 Message-ID: To: elizabeth.rodriguez@dothill.com, ips@ietf.org Subject: RE: [Ips] copyright notice Date: Wed, 3 Nov 2004 10:38:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Eddy, Can you quote RFC 3720 and then provide a reference to the RFC? In other words, RFC 3720 states "..." Elizabeth -----Original Message----- From: bill@strahm.net [mailto:bill@strahm.net] Sent: Wednesday, November 03, 2004 9:57 AM To: Eddy Quicksall Cc: ips@ietf.org Subject: RE: [Ips] copyright notice Not sure this is helpfull or not... Why would a reference with a pointer to 3720 work ? I am not a lawyer (nor do I play one on TV) so I won't advise you on what consitutes fair use Bill > -------- Original Message -------- > Subject: [Ips] copyright notice > From: "Eddy Quicksall" > Date: Wed, November 03, 2004 6:55 am > To: ips@ietf.org > > _______________________________________________ > 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 ips-bounces@ietf.org Wed Nov 3 15:39:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17827 for ; Wed, 3 Nov 2004 15:39:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPSAL-0006qK-L1 for ips-web-archive@ietf.org; Wed, 03 Nov 2004 15:55:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPRjo-0003pK-K0; Wed, 03 Nov 2004 15:28:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPRfc-0001LV-7y for ips@megatron.ietf.org; Wed, 03 Nov 2004 15:23:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16747 for ; Wed, 3 Nov 2004 15:23:48 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRuu-0006VR-0p for ips@ietf.org; Wed, 03 Nov 2004 15:39:44 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <20041103202311016000uurfe> (Authid: esquicksall); Wed, 3 Nov 2004 20:23:11 +0000 Message-ID: <000601c4c1e2$f1409e10$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: References: Subject: Re: [Ips] copyright notice Date: Wed, 3 Nov 2004 15:23:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Yes. I talked to our attorney and he will suggest some wording. Thanks. Eddy ----- Original Message ----- From: To: ; Sent: Wednesday, November 03, 2004 1:38 PM Subject: RE: [Ips] copyright notice > Eddy, > > Can you quote RFC 3720 and then provide a reference to the RFC? > > In other words, > > RFC 3720 states > "..." > > Elizabeth > > -----Original Message----- > From: bill@strahm.net [mailto:bill@strahm.net] > Sent: Wednesday, November 03, 2004 9:57 AM > To: Eddy Quicksall > Cc: ips@ietf.org > Subject: RE: [Ips] copyright notice > > Not sure this is helpfull or not... > > Why would a reference with a pointer to 3720 work ? > > I am not a lawyer (nor do I play one on TV) so I won't advise you on > what consitutes fair use > > Bill > >> -------- Original Message -------- >> Subject: [Ips] copyright notice >> From: "Eddy Quicksall" >> Date: Wed, November 03, 2004 6:55 am >> To: ips@ietf.org >> >> _______________________________________________ >> 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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Nov 4 13:44:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20639 for ; Thu, 4 Nov 2004 13:44:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPmqx-0003eL-4b for ips-web-archive@ietf.org; Thu, 04 Nov 2004 14:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmPy-0001AR-RE; Thu, 04 Nov 2004 13:33:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmIB-0006wL-BW for ips@megatron.ietf.org; Thu, 04 Nov 2004 13:25:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18801 for ; Thu, 4 Nov 2004 13:25:00 -0500 (EST) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPmXk-0003DG-Qc for ips@ietf.org; Thu, 04 Nov 2004 13:41:09 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iA4IOB1p450260 for ; Thu, 4 Nov 2004 13:24:21 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA4IO1T7158062 for ; Thu, 4 Nov 2004 11:24:01 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iA4IO0aA015243 for ; Thu, 4 Nov 2004 11:24:00 -0700 Received: from d03nm115.boulder.ibm.com (d03nm115.boulder.ibm.com [9.17.195.141]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iA4IO0BB015233 for ; Thu, 4 Nov 2004 11:24:00 -0700 To: ips@ietf.org MIME-Version: 1.0 Subject: [Ips] [iSCSI] iSER on InfiniBand X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: John Hufferd Message-ID: Date: Thu, 4 Nov 2004 11:23:45 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 11/04/2004 11:24:00, Serialize complete at 11/04/2004 11:24:00 X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0845078025==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multipart message in MIME format. --===============0845078025== Content-Type: multipart/alternative; boundary="=_alternative 0064F38388256F42_=" This is a multipart message in MIME format. --=_alternative 0064F38388256F42_= Content-Type: text/plain; charset="US-ASCII" Folks, I am aware of a lot of discussions that have been going on recently regarding iSCSI/iSER operating on InfiniBand Networks. There has been some authors that have been working to create some proposed wordage for the iSER document that would permit support of iSER by an InfiniBand Network. Unfortunately, the work to propose some new wordage did not complete in time to avoid the IETF draft black-out period. However, there was a document that was created that explained what was being discussed and why, and the WEB link to that document (on Julian's Web site) is included here: http://www.haifa.il.ibm.com/satran/ips/iSER-in-an-IB-network-V9.pdf I encourage you to take a look at this document. It should also be noted that because of this work dealing with InfiniBand it was also possible to define how an SCTP implementation could also be created that could be conformant to some new proposed wordage for the iSER Draft (to be released some time after the Black-Out period). Below is the introduction to the paper that was used as a base for some new proposed wordage. (Please understand, this is not meant to do anything other than to start the discussions, I expect there will be a lot of additional work to clarify issues, and craft the most approprate wordage for the iSER document.) Introduction There has been great interest in defining how the iSCSI/iSER (iSCSI Extensions for RDMA) can be made to operate over an InfiniBand network instead of a previously defined protocol called SRP (SCSI RDMA Protocol). The SRP protocol lacked Storage Management and Discovery processes. Therefore, great interest in iSCSI/iSER (iSER for short) has developed since it has the management and discovery structure defined, built, or being built for iSCSI. This will also consolidate the efforts of both Ethernet and InfiniBand communities, and reduce the number of Storage protocols a user has to learn and maintain. Several things are needed in order for an iSCSI/iSER over an InfiniBand (iSER/IB) network to operate. They are: 1. Being able to exploit the fact that all the IB Initiator and Target nodes can also have an IP Transport (IP-over-IB a.k.a. IPoIB) and associated IP Addresses for standard iSCSI discovery and for address resolution. 2. A way for an iSCSI/iSER on IB Initiator to Login directly to an InfiniBand attached iSER storage node (without having to connect and send Login PDUs via TCP/IP). 3. A way for an IB Initiator to choose, if it wishes, directly attached IB iSER Storage Nodes in preference to an iSER to iSCSI Gateway, or in preference to using TCP over IPoIB (Internet Protocol over InfiniBand) connection. 4. A way for iSER to operate on InfiniBand Channel Adapters supporting versions prior to 1.2 that does not support what is called a Zero Based Tagged Offset (ZBTO) or SendInvSE Messages. (Though the IB specification has been updated to support the new RDMA features that were introduced by iWARP, there are likely to be a number of systems that are only using IB hardware that only meet the pre version 1.2 specifications. This would mean that they would not support the features called ZeroBasedTO (called in InfiniBand ZBVA) or SendInvSE Messages.) . . 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 --=_alternative 0064F38388256F42_= Content-Type: text/html; charset="US-ASCII"
Folks,
I am aware of a lot of discussions that have been going on recently regarding iSCSI/iSER operating on InfiniBand Networks.  There has been some authors that have been working to create some proposed wordage for the iSER document that would permit support of iSER by an InfiniBand Network.  Unfortunately, the work to propose some new wordage did not complete in time to avoid the IETF draft black-out period.  However, there was a document that was created that explained what was being discussed and why, and the WEB link to that document (on Julian's Web site) is included here:

http://www.haifa.il.ibm.com/satran/ips/iSER-in-an-IB-network-V9.pdf

I encourage you to take a look at this document.  It should also be noted that because of this work dealing with InfiniBand it was also possible to define how an SCTP implementation could also be created that could be conformant to some new proposed wordage for the iSER Draft (to be released some time after the Black-Out period).

Below is the introduction to the paper that was used as a base for some new proposed wordage.  (Please understand, this is not meant to do anything other than to start the discussions, I expect there will be a lot of additional work to clarify issues, and craft the most approprate wordage for the iSER document.)

Introduction


There has been great interest in defining how the iSCSI/iSER (iSCSI Extensions for RDMA) can be made to operate over an InfiniBand network instead of a previously defined protocol called SRP (SCSI RDMA Protocol). The SRP protocol lacked Storage Management and Discovery processes.  Therefore, great interest in iSCSI/iSER (iSER for short) has developed since it has the management and discovery structure defined, built, or being built for iSCSI. This will also consolidate the efforts of both Ethernet and InfiniBand communities, and reduce the number of Storage protocols a user has to learn and maintain.
 
Several things are needed in order for an iSCSI/iSER over an InfiniBand (iSER/IB) network to operate.  They are:

1. Being able to exploit the fact that all the IB Initiator and Target nodes can also have an IP Transport (IP-over-IB a.k.a. IPoIB) and associated IP Addresses for standard iSCSI discovery and for address resolution.

2. A way for an iSCSI/iSER on IB Initiator to Login directly to an InfiniBand attached iSER storage node (without having to connect and send Login PDUs via TCP/IP).

3.  A way for an IB Initiator to choose, if it wishes, directly attached IB iSER Storage Nodes in preference to an iSER to iSCSI Gateway, or in preference to using TCP over IPoIB (Internet Protocol over InfiniBand) connection.

4. A way for iSER to operate on InfiniBand Channel Adapters supporting versions prior to 1.2 that does not support what is called a Zero Based Tagged Offset (ZBTO) or SendInvSE Messages. (Though the IB specification has been updated to support the new RDMA features that were introduced by iWARP, there are likely to be a number of systems that are only using IB hardware that only meet the pre version 1.2 specifications.  This would mean that they would not support the features called ZeroBasedTO (called in InfiniBand ZBVA) or SendInvSE Messages.)


.
.
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 --=_alternative 0064F38388256F42_=-- --===============0845078025== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0845078025==-- From ips-bounces@ietf.org Thu Nov 4 14:38:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25874 for ; Thu, 4 Nov 2004 14:38:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPnh2-0004vR-G9 for ips-web-archive@ietf.org; Thu, 04 Nov 2004 14:54:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPnPa-0004xM-8K; Thu, 04 Nov 2004 14:36:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPnGU-0003U5-QB for ips@megatron.ietf.org; Thu, 04 Nov 2004 14:27:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24747 for ; Thu, 4 Nov 2004 14:27:21 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPnW4-0004i2-OO for ips@ietf.org; Thu, 04 Nov 2004 14:43:29 -0500 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id C98AB87089; Thu, 4 Nov 2004 14:27:19 -0500 (EST) In-Reply-To: <20041102113141.61528.qmail@web50401.mail.yahoo.com> References: <20041102113141.61528.qmail@web50401.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <87978261-2E97-11D9-943A-000A95D14BEC@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] why microsoft initiator sends mode sense Date: Thu, 4 Nov 2004 11:27:08 -0800 To: ulka vaze X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1268534510==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --===============1268534510== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6-1030149168" --Apple-Mail-6-1030149168 Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-1030149161; protocol="application/pkcs7-signature" --Apple-Mail-5-1030149161 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 2, 2004, at 3:31 AM, ulka vaze wrote: > Hi all, > I am testing my iscsi target developed on MAC OS > X.Initially after LOgin is complete microsoft > initiator sends report Luns then Inquiry and then Read > capacity.After that it is sending read 10 with data > transfer length 512.Now in response to Read10 i send > DATA _IN pdu which has 512 bytes of data segment which > contains the data that i get from MAC's scsi layer.I > set the f=1 because only one data-in pdu ,i am setting > status bit 1 and sending status as good. > After receiving this response microsoft initiator > sends mode sense and asks for all mode pagess.I want > to know what could be the reason for this? Uhm, because the Windows SCSI layer asked it to? Asking for all mode pages is a common operation on device connect. It lets the initiator learn what the target can do. > Also it exposes device with device tyep unknown and > number -1 what is the problem? You should check your mode sense and inquiry data responses. Take care, Bill --Apple-Mail-5-1030149161 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfDCCBXgw ggNgoAMCAQICAUYwDQYJKoZIhvcNAQEEBQAwga0xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcg WW9yazERMA8GA1UEBxMITmV3IFlvcmsxHTAbBgNVBAoTFFdhc2FiaSBTeXN0ZW1zLCBJbmMuMQww CgYDVQQLEwNHSFExHzAdBgNVBAMTFldhc2FiaSBTeXN0ZW1zIFJvb3QgQ0ExKjAoBgkqhkiG9w0B CQEWG3dlYm1hc3RlckB3YXNhYmlzeXN0ZW1zLmNvbTAeFw0wMzA4MTExODU2NDZaFw0wODA2MjUx ODU2NDZaMIGXMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU2Fu IERpZWdvMRcwFQYDVQQKEw5XYXNhYmkgU3lzdGVtczEbMBkGA1UEAxMSV2lsbGlhbSBTdHVkZW5t dW5kMSkwJwYJKoZIhvcNAQkBFhp3cnN0dWRlbkB3YXNhYmlzeXN0ZW1zLmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA9CZhg4GVWYTRGcJz8lU1ipzInlBuGqfZQs88Z1rTP7+c3AyhKwpE TyTmK4UhxslzKa93YLqifLxZKYt1jI6FNq40IQWCKBVywWBwmL5guCu0851f9ywH5Uj2wJdiDrOI sOJKNpwNqml8bFdTrFS2qvyCxTIWVMLYAzUBBcl2F7MCAwEAAaOCATkwggE1MAkGA1UdEwQCMAAw LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBTt mjHbSBlMV48RWOBETM3EV0Tm/jCB2gYDVR0jBIHSMIHPgBQrBOnN88CNCHPaV5wLS212tcrgBaGB s6SBsDCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9y azEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMW V2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5 c3RlbXMuY29tggEAMA0GCSqGSIb3DQEBBAUAA4ICAQCpxoPEYunR7qiXyycEZd0UIatSt/WalMoH nuN9S421iS/sD1wSDqzHyM5YyUWn4z4o6VhT2kD9UV4lk5aXxxefEfGzFcR7Xyah7tO3ziuReFfx qUP5+DTlwDuUBc8Iow6NwY9GlRCKFSsEroLWLGODyYWgN1ojjKOtcXRiOZkYTP3VfDUV2/Xrhh9O l6+3Otf069+KWeOWedWeMsbe1rac96yPEjPogToWkBXVJEeEQktd0BLETt7GUuSZg2Fho/nslqZv nnnKZmrOfdFy9iXDL9T0Hp/OHf5B9RP+r00BJJFO8JzBPIL2IA3CBPApOQty5A00Jg1CGfDQxiV3 s8G0aRUbmFqg9r0OfhPYjJ8BHfw1HHWb7Cu91Sw+d5UnYracZhsR2Gc5H5CnfS6IZhc7ulfnSX8f I4BXR4vbeRUG76J3rkkbkO1haYHLk5w5RlICHsJOBSElG9ggLBWNIfUZwAzo84lfmDmJMP1YCOmi DFCbW1DgxhqVFpYEf5Pq2pVcCguopK2G9oZjH5fxq6ehisk9dN+7NEQ4OSqC43ehaStYOoQAJruN e6e5tCtRMx7bMI7eVPiHxE9/Y38Q+sc5oRN9mCyyAXMweuMRNHAHAWdFB7NhHD6gBa2lh91zIMdf iSVRlBXoMrBKJX6VecgnhvUp4G6QAnN7EMu6QHlc/jGCA0swggNHAgEBMIGzMIGtMQswCQYDVQQG EwJVUzERMA8GA1UECBMITmV3IFlvcmsxETAPBgNVBAcTCE5ldyBZb3JrMR0wGwYDVQQKExRXYXNh YmkgU3lzdGVtcywgSW5jLjEMMAoGA1UECxMDR0hRMR8wHQYDVQQDExZXYXNhYmkgU3lzdGVtcyBS b290IENBMSowKAYJKoZIhvcNAQkBFht3ZWJtYXN0ZXJAd2FzYWJpc3lzdGVtcy5jb20CAUYwCQYF Kw4DAhoFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQx MTA0MTkyNzA4WjAjBgkqhkiG9w0BCQQxFgQUShhhPaLq/7jg1hVy893O3yIfhU4wgcQGCSsGAQQB gjcQBDGBtjCBszCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhO ZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0G A1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdh c2FiaXN5c3RlbXMuY29tAgFGMIHGBgsqhkiG9w0BCRACCzGBtqCBszCBrTELMAkGA1UEBhMCVVMx ETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5 c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBD QTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5c3RlbXMuY29tAgFGMA0GCSqGSIb3 DQEBAQUABIGAllJxfVJYVrHetpgd+6JdxzM6jOve8GnUnaCdH3hMEFEItZE16ke03Te/o/3w1lKM ku4BZtHEKCRhvPXhoLw5NmAjyDRdVIviHuRnMIj9/dYwSyYN/fOl9qq2pvZpZIIZCn+f0dbuf2lZ g5Biw673+JzKASYIKZ806jd2a/SzLeAAAAAAAAA= --Apple-Mail-5-1030149161-- --Apple-Mail-6-1030149168 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBioKWDJT2Egh26K0RAnbtAJsH9PFkWXp/HzU414RoFKwLzRkZbwCcD6tW 6GCv+zg5XtZFZGJuGsRs+ko= =UPm9 -----END PGP SIGNATURE----- --Apple-Mail-6-1030149168-- --===============1268534510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1268534510==-- From ips-bounces@ietf.org Fri Nov 5 19:22:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04721 for ; Fri, 5 Nov 2004 19:22:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQEM5-0000F6-9p for ips-web-archive@ietf.org; Fri, 05 Nov 2004 19:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEF0-0004WT-I5; Fri, 05 Nov 2004 19:15:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQE9I-0002s2-2i for ips@megatron.ietf.org; Fri, 05 Nov 2004 19:09:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03888 for ; Fri, 5 Nov 2004 19:09:40 -0500 (EST) Received: from taurus.voltaire.com ([212.143.27.73]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQE9F-0008PN-R6 for ips@ietf.org; Fri, 05 Nov 2004 19:09:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] [iSCSI] iSER on InfiniBand Date: Sat, 6 Nov 2004 02:08:33 +0200 Message-ID: <35EA21F54A45CB47B879F21A91F4862F258644@taurus.voltaire.com> Thread-Topic: [Ips] [iSCSI] iSER on InfiniBand Thread-Index: AcTCnov4Fx88rZLRTN+42a8YWa2GBAA7O5Ew From: "Yaron Haviv" To: "John Hufferd" , X-Spam-Score: 0.7 (/) X-Scan-Signature: 81ca0cebdb446e1ff4e2b634791f24a9 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1298208438==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 This is a multi-part message in MIME format. --===============1298208438== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C394.D514868E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C394.D514868E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John and Folks, =20 The proposal seems rather complete and straight forward=20 =20 I believe running iSER over InfiniBand in addition to iWarp serves the iSCSI cause=20 It allows iSCSI to span from the lowest end with pure software implementations to the highest end with 30Gb/s InfiniBand hardware=20 Managing all of it with ubiquitous IP semantics, and with common iSCSI/iSNS/SLP infrastructure=20 The InfiniBand community can also accelerate the iSER creation and adoption=20 By pooling in more RDMA developers, and leveraging on existing HW and SW =20 It looks like the required changes in the current iSER spec are only few and are around the negotiation of Send/SendInvSE and ZBTO=20 And specifying that a Login can travel over the IB Reliable connection rather than over TCP =20 The Transport preference looks like something that should also be defined some where=20 I believe its not covered for Ethernet as well today, I haven't seen a definition of when iSCSI decides on using the RDMAExtensions option or not (probably an implementation specific issue), and what happens when we have both a NIC and an RNIC, do we decide base on Subnet Masks, .. So it can either be part of iSER or specified somewhere else=20 =20 If people don't want to change much in the iSER Draft, Maybe it's possible to add just the capability negotiation piece (SendInv, ZBTO), and general comments on iSER usability over InfiniBand, and put all the rest in an external draft that can be discussed separately=20 I can think of some use for non ZBTO (VA Based) for iWarp applications as well =20 All in all it's a good draft and good idea to add iSER binding to InfiniBand=20 =20 Yaron Voltaire, CTO www.voltaire.com =20 =20 ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of John Hufferd Sent: Thursday, November 04, 2004 9:24 PM To: ips@ietf.org Subject: [Ips] [iSCSI] iSER on InfiniBand =20 Folks,=20 I am aware of a lot of discussions that have been going on recently regarding iSCSI/iSER operating on InfiniBand Networks. There has been some authors that have been working to create some proposed wordage for the iSER document that would permit support of iSER by an InfiniBand Network. Unfortunately, the work to propose some new wordage did not complete in time to avoid the IETF draft black-out period. However, there was a document that was created that explained what was being discussed and why, and the WEB link to that document (on Julian's Web site) is included here:=20 http://www.haifa.il.ibm.com/satran/ips/iSER-in-an-IB-network-V9.pdf=20 I encourage you to take a look at this document. It should also be noted that because of this work dealing with InfiniBand it was also possible to define how an SCTP implementation could also be created that could be conformant to some new proposed wordage for the iSER Draft (to be released some time after the Black-Out period).=20 Below is the introduction to the paper that was used as a base for some new proposed wordage. (Please understand, this is not meant to do anything other than to start the discussions, I expect there will be a lot of additional work to clarify issues, and craft the most approprate wordage for the iSER document.)=20 Introduction There has been great interest in defining how the iSCSI/iSER (iSCSI Extensions for RDMA) can be made to operate over an InfiniBand network instead of a previously defined protocol called SRP (SCSI RDMA Protocol). The SRP protocol lacked Storage Management and Discovery processes. Therefore, great interest in iSCSI/iSER (iSER for short) has developed since it has the management and discovery structure defined, built, or being built for iSCSI. This will also consolidate the efforts of both Ethernet and InfiniBand communities, and reduce the number of Storage protocols a user has to learn and maintain.=20 =20 Several things are needed in order for an iSCSI/iSER over an InfiniBand (iSER/IB) network to operate. They are:=20 1. Being able to exploit the fact that all the IB Initiator and Target nodes can also have an IP Transport (IP-over-IB a.k.a. IPoIB) and associated IP Addresses for standard iSCSI discovery and for address resolution.=20 2. A way for an iSCSI/iSER on IB Initiator to Login directly to an InfiniBand attached iSER storage node (without having to connect and send Login PDUs via TCP/IP).=20 3. A way for an IB Initiator to choose, if it wishes, directly attached IB iSER Storage Nodes in preference to an iSER to iSCSI Gateway, or in preference to using TCP over IPoIB (Internet Protocol over InfiniBand) connection.=20 4. A way for iSER to operate on InfiniBand Channel Adapters supporting versions prior to 1.2 that does not support what is called a Zero Based Tagged Offset (ZBTO) or SendInvSE Messages. (Though the IB specification has been updated to support the new RDMA features that were introduced by iWARP, there are likely to be a number of systems that are only using IB hardware that only meet the pre version 1.2 specifications. This would mean that they would not support the features called ZeroBasedTO (called in InfiniBand ZBVA) or SendInvSE Messages.)=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 ------_=_NextPart_001_01C4C394.D514868E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John and = Folks,

 

The proposal seems rather complete = and straight forward

 

I believe running iSER over = InfiniBand in addition to iWarp serves the iSCSI cause

It allows iSCSI to span from the = lowest end with pure software implementations to the highest end with 30Gb/s InfiniBand hardware

Managing all of it with ubiquitous = IP semantics, and with common iSCSI/iSNS/SLP infrastructure =

The InfiniBand community can also = accelerate the iSER creation and adoption

By pooling in more RDMA developers, = and leveraging on existing HW and SW

 

It looks like the required changes = in the current iSER spec are only few and are around the negotiation of = Send/SendInvSE and ZBTO

And specifying that a Login can = travel over the IB Reliable connection rather than over = TCP

 

The Transport preference looks like something that should also be defined some where =

I believe its not covered for = Ethernet as well today, I haven’t seen a definition of when iSCSI decides on = using the RDMAExtensions option or not (probably an implementation specific = issue), and what happens when we have both a NIC and an RNIC, do we decide base = on Subnet Masks, ..

So it can either be part of iSER or = specified somewhere else

 

If people don’t want to = change much in the iSER Draft, Maybe it’s possible to add just the capability negotiation piece (SendInv, ZBTO), and general comments on iSER = usability over InfiniBand, and put all the rest in an external draft that can be = discussed separately

I can think of some use for non = ZBTO (VA Based) for iWarp applications as well

 

All in all it’s a good draft = and good idea to add iSER binding to InfiniBand =

 

Yaron

Voltaire, = CTO

www.voltaire.com<= /font>

 

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of John Hufferd
Sent: Thursday, November = 04, 2004 9:24 PM
To: ips@ietf.org
Subject: [Ips] [iSCSI] = iSER on InfiniBand

 


Folks,
I am aware of a lot of discussions that have been going on recently = regarding iSCSI/iSER operating on InfiniBand Networks.  There has been some = authors that have been working to create some proposed wordage for the iSER = document that would permit support of iSER by an InfiniBand Network. =  Unfortunately, the work to propose some new wordage did not complete in time to avoid = the IETF draft black-out period.  However, there was a document that was = created that explained what was being discussed and why, and the WEB link to = that document (on Julian's Web site) is included here:

http://www.haifa.il.ibm= .com/satran/ips/iSER-in-an-IB-network-V9.pdf

I encourage you to take a look at this document.  It should also be = noted that because of this work dealing with InfiniBand it was also possible = to define how an SCTP implementation could also be created that could be conformant to some new proposed wordage for the iSER Draft (to be = released some time after the Black-Out period).

Below is the introduction to the paper that was used as a base for some new = proposed wordage.  (Please understand, this is not meant to do anything = other than to start the discussions, I expect there will be a lot of additional = work to clarify issues, and craft the most approprate wordage for the iSER = document.)


Introduction



There has been great interest in defining how = the iSCSI/iSER (iSCSI Extensions for RDMA) can be made to operate over an InfiniBand network instead of a previously defined protocol called SRP = (SCSI RDMA Protocol). The SRP protocol lacked Storage Management and Discovery processes.  Therefore, great interest in iSCSI/iSER (iSER for = short) has developed since it has the management and discovery structure defined, = built, or being built for iSCSI. This will also consolidate the efforts of both Ethernet and InfiniBand communities, and reduce the number of Storage = protocols a user has to learn and maintain.
 
Several things are needed in order for an iSCSI/iSER over an InfiniBand = (iSER/IB) network to operate.  They are:

1. Being able to exploit the fact that all the IB Initiator and Target = nodes can also have an IP Transport (IP-over-IB a.k.a. IPoIB) and associated IP = Addresses for standard iSCSI discovery and for address resolution. =

2. A way for an iSCSI/iSER on IB Initiator to Login directly to an = InfiniBand attached iSER storage node (without having to connect and send Login = PDUs via TCP/IP).

3.  A way for an IB Initiator to choose, if it wishes, directly = attached IB iSER Storage Nodes in preference to an iSER to iSCSI Gateway, or in = preference to using TCP over IPoIB (Internet Protocol over InfiniBand) = connection.

4. A way for iSER to operate on InfiniBand Channel Adapters supporting = versions prior to 1.2 that does not support what is called a Zero Based Tagged = Offset (ZBTO) or SendInvSE Messages. (Though the IB specification has been = updated to support the new RDMA features that were introduced by iWARP, there are = likely to be a number of systems that are only using IB hardware that only meet = the pre version 1.2 specifications.  This would mean that they would = not support the features called ZeroBasedTO (called in InfiniBand ZBVA) or SendInvSE Messages.)


.
.
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

------_=_NextPart_001_01C4C394.D514868E-- --===============1298208438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1298208438==-- From ips-bounces@ietf.org Sun Nov 7 21:31:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24247 for ; Sun, 7 Nov 2004 21:31:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQzKM-00031z-Cp for ips-web-archive@ietf.org; Sun, 07 Nov 2004 21:32:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQzIG-0001dL-6C; Sun, 07 Nov 2004 21:30:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQzEQ-0001GQ-DK for ips@megatron.ietf.org; Sun, 07 Nov 2004 21:26:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23955 for ; Sun, 7 Nov 2004 21:26:08 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQzEs-0002x1-HB for ips@ietf.org; Sun, 07 Nov 2004 21:26:38 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iA82Q7gU021382 for ; Sun, 7 Nov 2004 21:26:07 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Nov 2004 21:26:07 -0500 Message-ID: To: ips@ietf.org Date: Sun, 7 Nov 2004 21:26:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.7.0 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ips] Washington, DC Agenda X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Sorry for the lateness of this, --David The IP Storage (ips) WG meets 1300-1500 on Monday, November 8 at the IETF meetings in Washington, DC. Here's a rough agenda: Administrivia, agenda bashing, draft status review, etc.: 15 min Any open MIB issues: 15 min iSER: 1 hour (draft-ietf-ips-iser-00.txt) iSER = iSCSI Extensions for RDMA iSER over InfiniBand: 30 min No draft available. This time period is for discussion of possible work to support iSCSI over InfiniBand via iSER. The primary purpose of this time is a discussion of whether the IETF should undertake work in this area, and if so, what scope of work is appropriate (e.g., to avoid all of us having to become InfiniBand experts). ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Nov 8 11:59:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01234 for ; Mon, 8 Nov 2004 11:59:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCsZ-00073c-6y for ips-web-archive@ietf.org; Mon, 08 Nov 2004 12:00:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCW5-0005FC-0g; Mon, 08 Nov 2004 11:37:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCQT-0003mF-Bz for ips@megatron.ietf.org; Mon, 08 Nov 2004 11:31:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27499 for ; Mon, 8 Nov 2004 11:31:26 -0500 (EST) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCR0-00065N-1N for ips@ietf.org; Mon, 08 Nov 2004 11:32:05 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel13.hp.com (Postfix) with ESMTP id DAF2B1C03FD0 for ; Mon, 8 Nov 2004 08:31:19 -0800 (PST) Received: from [127.0.0.1] (palnai12-91.corp.hp.com [15.244.192.91]) by rosemail.rose.hp.com (Postfix) with ESMTP id 7FD388242 for ; Mon, 8 Nov 2004 08:31:19 -0800 (PST) Message-ID: <418F9F4B.6040306@rose.hp.com> Date: Mon, 08 Nov 2004 08:31:07 -0800 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] [iSCSI] iSER on InfiniBand References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit John and all, - Agree with and support the basic notion being advanced here - it is ideal to have one iSCSI-based transport for RDMA and non-RDMA transports, and one iSCSI/iSER-based transport for iWARP and IB storage access. - Suggest that this work should go into separate draft(s) because it appears to describe different modes of operation as I see them (more on this below), and allows significantly different behaviors from the current mandatory behavior required in the iSER draft. E.g., - Support for non-SendInvSE operation. - Support for non-zero-based-TO operation. Also separate drafts would allow the current iSER/iWARP draft to proceed to its milestone dates as planned. - Assuming that S-RQ is a high-want for iSER targets, one should consider if it's indeed worth designing for the old IB ecosystem. If we assume SendInvSE & zb-TO support in IB, the iSER/IB semantics would be substantially closer to iSER/iWARP semantics during runtime. - I am not an IB expert, but it seems to me that the draft is outlining multiple modes of operation. Is it fair to say that modes b, c and d below could support gateways? a) iSCSI/iSER/IB end node talking to iSCSI/iSER/IB end node. b) iSCSI-3720 PDUs in IB Send Messages. This is currently proposed only for login phase, but appears to be usable even beyond to talk to an iSCSI/iSER gateway. c) iSCSI/IB end node talking to iSCSI/TCP end node. As I understand this, this should be iSCSI-3720 over IPoIB with no changes to peer iSCSI layers. d) iSCSI/iSER/IB end node talking to iSCSI/iSER/iWARP end node. - Should iSER/RDMA capabilities be reported in discovery? Should IB-support? How about the iSCSI MIB? - Finally, the draft makes an interesting observation which was brought up earlier as well - devising an integrated approach for iSER/SCTP and iSER/IB. This notion should be considered further. It might also decouple iSER from the current indirect MPA dependency. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com John Hufferd wrote: > > Folks, > I am aware of a lot of discussions that have been going on recently > regarding iSCSI/iSER operating on InfiniBand Networks. There has been > some authors that have been working to create some proposed wordage for > the iSER document that would permit support of iSER by an InfiniBand > Network. Unfortunately, the work to propose some new wordage did not > complete in time to avoid the IETF draft black-out period. However, > there was a document that was created that explained what was being > discussed and why, and the WEB link to that document (on Julian's Web > site) is included here: > > http://www.haifa.il.ibm.com/satran/ips/iSER-in-an-IB-network-V9.pdf > > I encourage you to take a look at this document. It should also be > noted that because of this work dealing with InfiniBand it was also > possible to define how an SCTP implementation could also be created that > could be conformant to some new proposed wordage for the iSER Draft (to > be released some time after the Black-Out period). > > Below is the introduction to the paper that was used as a base for some > new proposed wordage. (Please understand, this is not meant to do > anything other than to start the discussions, I expect there will be a > lot of additional work to clarify issues, and craft the most approprate > wordage for the iSER document.) > > *Introduction* > > > There has been great interest in defining how the iSCSI/iSER (iSCSI > Extensions for RDMA) can be made to operate over an InfiniBand network > instead of a previously defined protocol called SRP (SCSI RDMA > Protocol). The SRP protocol lacked Storage Management and Discovery > processes. Therefore, great interest in iSCSI/iSER (iSER for short) has > developed since it has the management and discovery structure defined, > built, or being built for iSCSI. This will also consolidate the efforts > of both Ethernet and InfiniBand communities, and reduce the number of > Storage protocols a user has to learn and maintain. > > Several things are needed in order for an iSCSI/iSER over an InfiniBand > (iSER/IB) network to operate. They are: > > 1. Being able to exploit the fact that all the IB Initiator and Target > nodes can also have an IP Transport (IP-over-IB a.k.a. IPoIB) and > associated IP Addresses for standard iSCSI discovery and for address > resolution. > > 2. A way for an iSCSI/iSER on IB Initiator to Login directly to an > InfiniBand attached iSER storage node (without having to connect and > send Login PDUs via TCP/IP). > > 3. A way for an IB Initiator to choose, if it wishes, directly attached > IB iSER Storage Nodes in preference to an iSER to iSCSI Gateway, or in > preference to using TCP over IPoIB (Internet Protocol over InfiniBand) > connection. > > 4. A way for iSER to operate on InfiniBand Channel Adapters supporting > versions prior to 1.2 that does not support what is called a Zero Based > Tagged Offset (ZBTO) or SendInvSE Messages. (Though the IB specification > has been updated to support the new RDMA features that were introduced > by iWARP, there are likely to be a number of systems that are only using > IB hardware that only meet the pre version 1.2 specifications. This > would mean that they would not support the features called ZeroBasedTO > (called in InfiniBand ZBVA) or SendInvSE Messages.) > > > . > . > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Nov 9 13:28:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27548 for ; Tue, 9 Nov 2004 13:28:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRakF-0002nN-VO for ips-web-archive@ietf.org; Tue, 09 Nov 2004 13:29:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRafS-0006yS-KK; Tue, 09 Nov 2004 13:24:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRaam-0006Ls-84 for ips@megatron.ietf.org; Tue, 09 Nov 2004 13:19:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27041 for ; Tue, 9 Nov 2004 13:19:40 -0500 (EST) Received: from mail.mellanox.co.il ([194.90.237.34] helo=mtlex01.yok.mtl.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRabZ-0002e1-2C for ips@ietf.org; Tue, 09 Nov 2004 13:20:34 -0500 Received: by mtlex01.yok.mtl.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Nov 2004 20:17:20 +0200 Message-ID: <506C3D7B14CDD411A52C00025558DED606540808@mtlex01.yok.mtl.com> From: Dror Goldenberg To: "Mallikarjun C." , ips@ietf.org Subject: RE: [Ips] [iSCSI] iSER on InfiniBand Date: Tue, 9 Nov 2004 20:17:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0186820526==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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. --===============0186820526== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C688.5943BD40" 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_01C4C688.5943BD40 Content-Type: text/plain > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, November 08, 2004 6:31 PM > To: ips@ietf.org > Subject: Re: [Ips] [iSCSI] iSER on InfiniBand > > - Suggest that this work should go into separate draft(s) because it > appears to describe different modes of operation as I see > them (more > on this below), and allows significantly different behaviors from > the current mandatory behavior required in the iSER draft. E.g., > - Support for non-SendInvSE operation. > - Support for non-zero-based-TO operation. > > Also separate drafts would allow the current iSER/iWARP draft to > proceed to its milestone dates as planned. > > - Assuming that S-RQ is a high-want for iSER targets, one should > consider if it's indeed worth designing for the old IB ecosystem. > If we assume SendInvSE & zb-TO support in IB, the iSER/IB semantics > would be substantially closer to iSER/iWARP semantics > during runtime. Hi Mallikarjun, The IB Verbs Extensions (IB 1.2) have been defined in groups, where each group is optional to implement in an IB 1.2 compliant Channel Adapter. The groups of interest are: (1) SRQ - Shared Receive Queue (2) BMM - Base Memory Management - includes Send&Invalidate (and Fast Register) (3) ZBVA - Zero Based Regions An implementation may support any combination of these groups. Therefore it is very likely that you can find an implementation that supports SRQ, but does not support ZBVA and Send&Invalidate. Therefore I see a good value in iSER supporting hybrid modes (especially implementation that have SRQ but do not support other extensions). BTW, the reason that the IB Verbs Extensions were defined in optional groups is because vendors believed that some of the extensions can be implemented even by the old IB parts through a firmware upgrade or through simple design changes. Implementation of all the features, usually require a longer development cycle, and therefore delays the deployment of products which strongly rely on the new features for their wire protocol. -Dror ------_=_NextPart_001_01C4C688.5943BD40 Content-Type: text/html RE: [Ips] [iSCSI] iSER on InfiniBand

> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Monday, November 08, 2004 6:31 PM
> To: ips@ietf.org
> Subject: Re: [Ips] [iSCSI] iSER on InfiniBand
>
 
<snip>

> - Suggest that this work should go into separate draft(s) because it
>    appears to describe different modes of operation as I see
> them (more
>    on this below), and allows significantly different behaviors from
>    the current mandatory behavior required in the iSER draft. E.g.,
>       - Support for non-SendInvSE operation.
>       - Support for non-zero-based-TO operation.
>
>    Also separate drafts would allow the current iSER/iWARP draft to
>    proceed to its milestone dates as planned.
>
> - Assuming that S-RQ is a high-want for iSER targets, one should
>    consider if it's indeed worth designing for the old IB ecosystem.
>    If we assume SendInvSE & zb-TO support in IB, the iSER/IB semantics
>    would be substantially closer to iSER/iWARP semantics
> during runtime.

Hi Mallikarjun,

The IB Verbs Extensions (IB 1.2) have been defined in groups, where each
group is optional to implement in an IB 1.2 compliant Channel Adapter.
The groups of interest are:
(1) SRQ - Shared Receive Queue
(2) BMM - Base Memory Management - includes Send&Invalidate (and Fast Register)
(3) ZBVA - Zero Based Regions
An implementation may support any combination of these groups. Therefore
it is very likely that you can find an implementation that supports SRQ, but
does not support ZBVA and Send&Invalidate. Therefore I see a good value in
iSER supporting hybrid modes (especially implementation that have SRQ but
do not support other extensions).

BTW, the reason that the IB Verbs Extensions were defined in optional groups
is because vendors believed that some of the extensions can be implemented
even by the old IB parts through a firmware upgrade or through simple design
changes. Implementation of all the features, usually require a longer development
cycle, and therefore delays the deployment of products which strongly rely
on the new features for their wire protocol.

-Dror

------_=_NextPart_001_01C4C688.5943BD40-- --===============0186820526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0186820526==-- From ips-bounces@ietf.org Fri Nov 12 00:32:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12954 for ; Fri, 12 Nov 2004 00:32:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSU3w-0007aR-Lt for ips-web-archive@ietf.org; Fri, 12 Nov 2004 00:33:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSU0a-0008LE-J4; Fri, 12 Nov 2004 00:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSTwh-0007rI-TM for ips@megatron.ietf.org; Fri, 12 Nov 2004 00:26:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12473 for ; Fri, 12 Nov 2004 00:26:01 -0500 (EST) Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSTxz-0007TK-IS for ips@ietf.org; Fri, 12 Nov 2004 00:27:25 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAC5PSG4279686 for ; Fri, 12 Nov 2004 00:25:28 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAC5PSWm279316 for ; Fri, 12 Nov 2004 00:25:28 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAC5PScK014598 for ; Fri, 12 Nov 2004 00:25:28 -0500 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAC5PSKD014594 for ; Fri, 12 Nov 2004 00:25:28 -0500 Importance: Normal MIME-Version: 1.0 To: ips@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Thu, 11 Nov 2004 21:25:27 -0800 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M2_07222004 Beta 2|July 22, 2004) at 11/12/2004 00:25:27, Serialize complete at 11/12/2004 00:25:27 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Subject: [Ips] Updated text for MaxOutstandingUnexpectedPDUs for iSER X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 After thinking through the potential problem with overuse of the unidirectional NOP-out PDUs, I concluded that the situation where the initiator can send twice MaxOutstandUnexpectedPDUs cannot happen. Even if the initiator abuses the use of the unidirectional NOP-out PDUs, it can only send MaxOutstandUnexpectedPDUs, but not twice the number. The reasoning is as follows: For the unidirectional NOP-out, the CmdSN used is the next CmdSN and the variable is not advanced when the PDU is sent, and neither is ExpCmdSN. So for the target to respond with a PDU where ExpCmdSN is x+1 where x is CmdSN of the NOP-out PDU, it must be acknowledging a non-immediate PDU also with CmdSN = x. This must be sent after all the NOP-outs with CmdSN = x have been sent, since this non-immediate PDU will advance CmdSN. Assuming the target has processed all the NOP-outs with the immediate flag set before the non-immediate PDU that follows, the receive buffers should be replenished. So even if the initiator sends a huge number of NOP-outs later after receiving a PDU from the target with ExpCmdSN = x+1, it will be using CmdSN = x+1 for those NOP-outs and there is no ambiguity on the CmdSN that the ExpCmdSN is acknowledging. So if the target has provisions for MaxOutstandUnexpectedPDUs number of receive buffers available, it should be able to handle the unexpected NOP-out PDUs. For StatSN, the reasoning is similar since StatSN in the NOP-In is interpreted as the next StatSN. The following is the updated text for the new key, MaxOutstandingUnexpectedPDUs. Note that the default for the key is TBD as David Black has suggested in the 61st IETF meeting. The argument for the default being "None" is that it is the preferred value if the implementation uses Shared RQ, supports graceful handling, or can replenish receive buffers at wire speed. Please respond if you have a suggestion for a different default value. Mike -------------- start of new key definition --------------- Use: LO (leading only), Declarative Senders: Initiator and Target Scope: SW (session-wide) Irrelevant when: RDMAExtensions=No MaxOutstandingUnexpectedPDUs= Default is TBD This key is used by the initiator and the target to declare the maximum number of outstanding "unexpected" control-type PDUs that it can receive. It is intended to allow the receiving side to determine the amount of buffer resources needed beyond the normal flow control mechanism available in iSCSI. An initiator or target should select a value such that it would not impose an unnecessary constraint on the iSCSI layer under normal circumstances. If the sending side fails to adhere to the declared limit as set by the receiving side, it is up to the receiving side to determine ways of handling the overrun, including dropping the connection. The control-type PDUs that can be sent by an initiator to a target can be grouped into the following categories: 1. Regulated: Control-type PDUs in this category are regulated by the iSCSI CmdSN window mechanism and the immediate flag is not set. 2. Unregulated but Expected: Control-type PDUs in this category are not regulated by the iSCSI CmdSN window mechanism but are expected by the target. 3. Unregulated and Unexpected: Control-type PDUs in this category are not regulated by the iSCSI CmdSN window mechanism and are "unexpected" by the target. For the control-type PDUs in the Regulated category, the queuing capacity required of the iSCSI layer at the target is described in section 3.2.2.1 of [RFC3720]. For each of these control-type PDUs sent by the initiator, the initiator MUST provision for the buffer resources required for the corresponding control-type PDU to be returned from the target. The following is a list of the PDUs that can be sent by the initiator and the PDUs that are sent by the target in response: a. When an initiator sends a SCSI Command PDU, it expects a SCSI Response PDU from the target. Alternatively, the target can respond with the Reject PDU before the task is active. b. When the initiator sends a Task Management Function Request PDU, it expects a Task Management Function Response PDU from the target. c. When the initiator sends a Text Request PDU, it expects a Text Response PDU from the target. d. When the initiator sends a Login Request PDU, it expects a Login Response PDU from the target. e. When the initiator sends a Logout Request PDU, it expects a Logout Response PDU from the target. f. When the initiator sends a NOP-out PDU as a ping request with ITT /= 0xffffffff and TTT = 0xffffffff, it expects a NOP-in PDU from the target with the same ITT and TTT as in the ping request. For the control-type PDUs in the Unregulated but Expected category, the amount of buffering resources required at the target can be predetermined. The following is a list of the PDUs in this category: a. SCSI Data-out PDUs are used by the initiator to send unsolicited data. The amount of buffer resources required by the target can be determined using FirstBurstLength. Note that SCSI Data-out PDUs are not used for solicited data since the R2T PDU which is used for solicitation is transformed into RDMA Read operations by the iSER layer at the target. See section 7.3.4. b. A NOP-out PDU with ITT = 0xffffffff and TTT /= 0xffffffff is sent as a ping response by the initiator to the NOP-in PDU sent as a ping request by the target. The number of PDUs in the Unregulated and Unexpected category which can be sent by an initiator is controlled by MaxOutstandingUnexpectedPDUs declared by the target. After a PDU in this category is sent by the initiator, it is outstanding until it is retired. At any time, the number of outstanding PDUs MUST not exceed MaxOutstandingUnexpectedPDUs. The following is a list of the PDUs in this category and the conditions for retiring the outstanding PDU: a. For the PDUs listed in the Regulated category but with the immediate flag set, a PDU is outstanding until the target responds with the correspdonding response PDU. b. SNACK PDUs are not needed in iSER (see section 7.3.11). A SNACK PDU which is sent by the initiator anyway is outstanding until the target responds with a SCSI Response PDU for the referenced command. c. For a NOP-out PDU with ITT = TTT = 0xffffffff, the PDU is outstanding until the target responds with a control-type PDU with ExpCmdSN set to at least x+1 where x is the CmdSN of the NOP-out PDU. Control-type PDUs that can be sent by a target and are expected by the initiator are listed in the Regulated category. For the control-type PDUs that are unexpected by the initiator, the number that can be sent by a target is controlled by MaxOutstandingUnexpectedPDUs declared by the initiator. After a PDU in this category is sent by a target, it is outstanding until it is retired. At any time, the number of outstanding PDUs MUST not exceed MaxOutstandingUnexpectedPDUs. The following is a list of the PDUs in this category and the conditions for retiring the outstanding PDU: a. For an Asynchronous Message PDU with StatSN = x, the PDU is outstanding until the initiator sends a control-type PDU with ExpStatSN set to at least x+1. b. For a Reject PDU with StatSN = x which is sent after a task is active, the PDU is outstanding until the initiator sends a control-type PDU with ExpStatSN set to at least x+1. c. For a NOP-in PDU with ITT = TTT = 0xffffffff, the PDU is outstanding until the initiator responds with a control-type PDU with ExpStatSN set to at least x+1 where x is the StatSN of the NOP-in PDU. d. For a NOP-in PDU sent as a ping request with ITT = 0xffffffff and TTT /= 0xffffffff, the PDU is outstanding until the initiator sends a NOP-out PDU with the same ITT and TTT as in the ping request. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 12 11:42:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18676 for ; Fri, 12 Nov 2004 11:42:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeWv-0004NN-MZ for ips-web-archive@ietf.org; Fri, 12 Nov 2004 11:44:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSeNT-0001Ht-8E; Fri, 12 Nov 2004 11:34:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSeG8-0008IE-6s for ips@megatron.ietf.org; Fri, 12 Nov 2004 11:26:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17590 for ; Fri, 12 Nov 2004 11:26:45 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeHT-00043u-U4 for ips@ietf.org; Fri, 12 Nov 2004 11:28:15 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iACGQUhD010351 for ; Fri, 12 Nov 2004 11:26:32 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Nov 2004 11:26:29 -0500 Message-ID: To: ips@ietf.org Date: Fri, 12 Nov 2004 11:26:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.11.3 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Ips] Draft DC minutes X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Send comments/corrections/etc. to me (and the list if you think they're important). This also serves as an announcement of the sense of the room decisions taken in DC - in the absence of objection on the list, they are the rough consensus of the IPS WG. The most important decision is on the limit for # of outstanding unexpected PDUs for iSER - see below. Thanks, --David IP Storage (ips) WG - Washington DC minutes - DRAFT --------------------------------------------------- The IP Storage (ips) WG meets 1300-1500 on Monday, November 8, 2004 at the IETF meetings in Washington, DC. AGENDA and MINUTES ------------------ Letters in square brackets (e.g., [A]) indicate first character in filename of presenation. Administrivia, agenda bashing, draft status review, etc.: [A] 15 min David Black, EMC (co-chair) Blue sheets Note Well Milestones - iSER and DA to ADs in April/May 2005 Draft status - All protocol drafts are in RFC Editor queue - iSNS DHC option will be there shortly after meeting - FCIP SLP template probably needs an errata to correct version # in template from 0.1 to 1.0 - Waiting on new versions of iSCSI MIB, iSCSI Auth MIB and FCIP MIB from draft authors. - iFCP and iSNS MIBs need author attention Any open MIB issues: [no slides] 15 min Elizabeth Rodriguez, Dot Hill (co-chair) FC Management MIB (draft-ietf-ips-fcmgmt-mib-05.txt) - New field to be added to deal with a MIB instance that covers multiple switches. This was submitted as an IETF Last Call comment, but got lost. -06 version of MIB will be produced containing all agreed-to changes from -05 plus this change. Message will be sent to list to do a quick review of this final change. iSER and DA: [B] 1 hour Mike Ko, IBM (draft-ietf-ips-iser-00.txt) (draft-ietf-ips-iwarp-da-00.txt) iSER = iSCSI Extensions for RDMA DA = Datamover Architecture for iSCSI Control of unexpected PDUs - Sense of room: Using a key to limit # of outstanding unexpected PDUs is the right approach. "None" = "No Limit" is allowed. Minimum value (e.g., to avoid 1 or 2) is TBD [Open Issue] - Specified default value (None vs. specific value) in absence of negotiation will be taken to list. [Open Issue] - Draft will need to contain discussion of unexpected vs. expected PDUs and buffering requirements, and when an unexpected PDU ceases to be outstanding. - Add cautionary notes to avoid NOP-out and NOP-in abuse, but take this to the list, as there may be a possibility of being able to specify initiator behavior that always works. [Open Issue] iSER over InfiniBand: [C] 30 min John Hufferd, IBM No draft available. This time period is for discussion of possible work to support iSCSI over InfiniBand via iSER. The primary purpose of this time is a discussion of whether the IETF should undertake work in this area, and if so, what scope of work is appropriate (e.g., to avoid all of us having to become InfiniBand experts). Proposal is iSER over InfiniBand to enable use of iSCSI Terminology: RDMAP should be for the RDDP WG protocol only, and not generalized as proposed in the slides. Resolution: No real conclusion. Enabling reuse of IETF technology like iSCSI/iSER in other environments is a "good thing" in principle. OTOH, our AD is concerned about InfiniBand protocols (e.g., RC) getting out onto the Internet and causing problems. Proponents should produce Internet-Draft addressing architecture, intended usage, Infiniband to IP/Internet proxy (in particular, protocol stack layer diagram) and proposed division of work between IETF and IBTA that avoids need for serious InfiniBand expertise in IETF (e.g., the work needed to cope with old implementations of InfiniBand appears to belong in IBTA, not IETF). Based on WG discussion of that draft, the WG co-chairs, and ADs can determine appropriate next steps. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 12 16:12:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24461 for ; Fri, 12 Nov 2004 16:12:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSijj-0006Et-P7 for ips-web-archive@ietf.org; Fri, 12 Nov 2004 16:13:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSiS1-0008Fp-Mw; Fri, 12 Nov 2004 15:55:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CShsI-0006R2-Ge for ips@megatron.ietf.org; Fri, 12 Nov 2004 15:18:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10168 for ; Fri, 12 Nov 2004 15:18:24 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CShti-0001U9-J3 for ips@ietf.org; Fri, 12 Nov 2004 15:19:55 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (rwcrmhc12) with SMTP id <2004111220175201400ogudoe> (Authid: esquicksall); Fri, 12 Nov 2004 20:17:53 +0000 Message-ID: <000601c4c8f4$af6454a0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Fri, 12 Nov 2004 15:17:49 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ips] Long CDBs and bi-directional commands X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1770028760==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is a multi-part message in MIME format. --===============1770028760== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C4C8CA.C5A1A2B0" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C4C8CA.C5A1A2B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to test long CDB's and bi-directional commands. Does anyone = know of any initiator that uses these? Eddy ------=_NextPart_000_0003_01C4C8CA.C5A1A2B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would like to test long CDB's and bi-directional = commands.=20 Does anyone know of any initiator that uses these?
 
Eddy
------=_NextPart_000_0003_01C4C8CA.C5A1A2B0-- --===============1770028760== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1770028760==-- From ips-bounces@ietf.org Fri Nov 12 16:15:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25205 for ; Fri, 12 Nov 2004 16:15:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSinI-0006U4-5c for ips-web-archive@ietf.org; Fri, 12 Nov 2004 16:17:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSiYJ-0004gT-HK; Fri, 12 Nov 2004 16:01:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSi1w-000644-9p for ips@megatron.ietf.org; Fri, 12 Nov 2004 15:28:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12700 for ; Fri, 12 Nov 2004 15:28:16 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSi3H-0002Fu-I9 for ips@ietf.org; Fri, 12 Nov 2004 15:29:48 -0500 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 05B20870B3; Fri, 12 Nov 2004 15:28:08 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <59275D9A-34E9-11D9-93B9-000A95D14BEC@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Updated text for MaxOutstandingUnexpectedPDUs for iSER Date: Fri, 12 Nov 2004 12:27:55 -0800 To: Mike Ko X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1994181356==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 --===============1994181356== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8--422486681" --Apple-Mail-8--422486681 Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--422486686; protocol="application/pkcs7-signature" --Apple-Mail-7--422486686 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 11, 2004, at 9:25 PM, Mike Ko wrote: > After thinking through the potential problem with overuse of the > unidirectional NOP-out PDUs, I concluded that the situation where the > initiator can send twice MaxOutstandUnexpectedPDUs cannot happen. > Even if > the initiator abuses the use of the unidirectional NOP-out PDUs, it can > only send MaxOutstandUnexpectedPDUs, but not twice the number. The > reasoning is as follows: > > For the unidirectional NOP-out, the CmdSN used is the next CmdSN and > the > variable is not advanced when the PDU is sent, and neither is > ExpCmdSN. So > for the target to respond with a PDU where ExpCmdSN is x+1 where x is > CmdSN of the NOP-out PDU, it must be acknowledging a non-immediate PDU > also with CmdSN = x. This must be sent after all the NOP-outs with > CmdSN > = x have been sent, since this non-immediate PDU will advance CmdSN. > Assuming the target has processed all the NOP-outs with the immediate > flag > set before the non-immediate PDU that follows, the receive buffers > should > be replenished. So even if the initiator sends a huge number of > NOP-outs > later after receiving a PDU from the target with ExpCmdSN = x+1, it > will > be using CmdSN = x+1 for those NOP-outs and there is no ambiguity on > the > CmdSN that the ExpCmdSN is acknowledging. So if the target has > provisions > for MaxOutstandUnexpectedPDUs number of receive buffers available, it > should be able to handle the unexpected NOP-out PDUs. Just to make sure I'm understanding things, MaxOutstandUnexpectedPDUs limits the total number of un-ack'd PDUs (NOP-OUTs in this case), not the number per any specific CmdSN. Correct? > For StatSN, the reasoning is similar since StatSN in the NOP-In is > interpreted as the next StatSN. > > The following is the updated text for the new key, > MaxOutstandingUnexpectedPDUs. Note that the default for the key is > TBD as > David Black has suggested in the 61st IETF meeting. The argument for > the > default being "None" is that it is the preferred value if the > implementation uses Shared RQ, supports graceful handling, or can > replenish receive buffers at wire speed. Please respond if you have a > suggestion for a different default value. > > Mike > -------------- start of new key definition --------------- > Use: LO (leading only), Declarative > > Senders: Initiator and Target > > Scope: SW (session-wide) > > Irrelevant when: RDMAExtensions=No > > MaxOutstandingUnexpectedPDUs= None> Why 2**64-1? All the other counting in iSCSI uses 32-bit ints. Including the numbers we want to use for status acknowledgement. Thus I really don't see how we could need more than 2**32. Take care, Bill --Apple-Mail-7--422486686 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfDCCBXgw ggNgoAMCAQICAUYwDQYJKoZIhvcNAQEEBQAwga0xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcg WW9yazERMA8GA1UEBxMITmV3IFlvcmsxHTAbBgNVBAoTFFdhc2FiaSBTeXN0ZW1zLCBJbmMuMQww CgYDVQQLEwNHSFExHzAdBgNVBAMTFldhc2FiaSBTeXN0ZW1zIFJvb3QgQ0ExKjAoBgkqhkiG9w0B CQEWG3dlYm1hc3RlckB3YXNhYmlzeXN0ZW1zLmNvbTAeFw0wMzA4MTExODU2NDZaFw0wODA2MjUx ODU2NDZaMIGXMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU2Fu IERpZWdvMRcwFQYDVQQKEw5XYXNhYmkgU3lzdGVtczEbMBkGA1UEAxMSV2lsbGlhbSBTdHVkZW5t dW5kMSkwJwYJKoZIhvcNAQkBFhp3cnN0dWRlbkB3YXNhYmlzeXN0ZW1zLmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA9CZhg4GVWYTRGcJz8lU1ipzInlBuGqfZQs88Z1rTP7+c3AyhKwpE TyTmK4UhxslzKa93YLqifLxZKYt1jI6FNq40IQWCKBVywWBwmL5guCu0851f9ywH5Uj2wJdiDrOI sOJKNpwNqml8bFdTrFS2qvyCxTIWVMLYAzUBBcl2F7MCAwEAAaOCATkwggE1MAkGA1UdEwQCMAAw LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBTt mjHbSBlMV48RWOBETM3EV0Tm/jCB2gYDVR0jBIHSMIHPgBQrBOnN88CNCHPaV5wLS212tcrgBaGB s6SBsDCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9y azEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMW V2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5 c3RlbXMuY29tggEAMA0GCSqGSIb3DQEBBAUAA4ICAQCpxoPEYunR7qiXyycEZd0UIatSt/WalMoH nuN9S421iS/sD1wSDqzHyM5YyUWn4z4o6VhT2kD9UV4lk5aXxxefEfGzFcR7Xyah7tO3ziuReFfx qUP5+DTlwDuUBc8Iow6NwY9GlRCKFSsEroLWLGODyYWgN1ojjKOtcXRiOZkYTP3VfDUV2/Xrhh9O l6+3Otf069+KWeOWedWeMsbe1rac96yPEjPogToWkBXVJEeEQktd0BLETt7GUuSZg2Fho/nslqZv nnnKZmrOfdFy9iXDL9T0Hp/OHf5B9RP+r00BJJFO8JzBPIL2IA3CBPApOQty5A00Jg1CGfDQxiV3 s8G0aRUbmFqg9r0OfhPYjJ8BHfw1HHWb7Cu91Sw+d5UnYracZhsR2Gc5H5CnfS6IZhc7ulfnSX8f I4BXR4vbeRUG76J3rkkbkO1haYHLk5w5RlICHsJOBSElG9ggLBWNIfUZwAzo84lfmDmJMP1YCOmi DFCbW1DgxhqVFpYEf5Pq2pVcCguopK2G9oZjH5fxq6ehisk9dN+7NEQ4OSqC43ehaStYOoQAJruN e6e5tCtRMx7bMI7eVPiHxE9/Y38Q+sc5oRN9mCyyAXMweuMRNHAHAWdFB7NhHD6gBa2lh91zIMdf iSVRlBXoMrBKJX6VecgnhvUp4G6QAnN7EMu6QHlc/jGCA0swggNHAgEBMIGzMIGtMQswCQYDVQQG EwJVUzERMA8GA1UECBMITmV3IFlvcmsxETAPBgNVBAcTCE5ldyBZb3JrMR0wGwYDVQQKExRXYXNh YmkgU3lzdGVtcywgSW5jLjEMMAoGA1UECxMDR0hRMR8wHQYDVQQDExZXYXNhYmkgU3lzdGVtcyBS b290IENBMSowKAYJKoZIhvcNAQkBFht3ZWJtYXN0ZXJAd2FzYWJpc3lzdGVtcy5jb20CAUYwCQYF Kw4DAhoFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQx MTEyMjAyNzU2WjAjBgkqhkiG9w0BCQQxFgQUTo5a76ilZe9CYj0PFzrd1uVUQz0wgcQGCSsGAQQB gjcQBDGBtjCBszCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhO ZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0G A1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdh c2FiaXN5c3RlbXMuY29tAgFGMIHGBgsqhkiG9w0BCRACCzGBtqCBszCBrTELMAkGA1UEBhMCVVMx ETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5 c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBD QTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5c3RlbXMuY29tAgFGMA0GCSqGSIb3 DQEBAQUABIGAEwVLYD90UdTqjrlBPwJ6s8V1PHTxXXdN1gVG7TQVab6YrOVIELtpu2+5hFNfDAAl jtTd0DRU0lQNpXaAp8BRnvd2u9ZN8plHU+ANAnr9btckTyDMalaGcgMaojRmjXDmO1EWtFaDNjqC Q3IAb99Ir9gscb6jFHoJaBLRZNoLTqQAAAAAAAA= --Apple-Mail-7--422486686-- --Apple-Mail-8--422486681 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBlRzVDJT2Egh26K0RAhoiAJ91d29APukQU8HhMI63q+kFF/e/uACfVxls DLIYR/wAq2IPH3s3ZACm/O8= =6V7x -----END PGP SIGNATURE----- --Apple-Mail-8--422486681-- --===============1994181356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1994181356==-- From ips-bounces@ietf.org Fri Nov 12 16:18:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25995 for ; Fri, 12 Nov 2004 16:18:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSiqA-0006hI-Sf for ips-web-archive@ietf.org; Fri, 12 Nov 2004 16:20:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSifp-0004xV-6W; Fri, 12 Nov 2004 16:09:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSiJa-0001I0-I0 for ips@megatron.ietf.org; Fri, 12 Nov 2004 15:46:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17937 for ; Fri, 12 Nov 2004 15:46:35 -0500 (EST) Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSiL1-0003qL-4C for ips@ietf.org; Fri, 12 Nov 2004 15:48:07 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iACKk5G4084806 for ; Fri, 12 Nov 2004 15:46:05 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iACKk5eS287166 for ; Fri, 12 Nov 2004 15:46:05 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iACKk5bO024044 for ; Fri, 12 Nov 2004 15:46:05 -0500 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iACKk5bi024035; Fri, 12 Nov 2004 15:46:05 -0500 Importance: Normal MIME-Version: 1.0 To: William Studenmund Subject: Re: [Ips] Updated text for MaxOutstandingUnexpectedPDUs for iSER X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Fri, 12 Nov 2004 12:46:03 -0800 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M2_07222004 Beta 2|July 22, 2004) at 11/12/2004 15:46:04, Serialize complete at 11/12/2004 15:46:04 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 William, You wrote "Just to make sure I'm understanding things, MaxOutstandUnexpectedPDUs limits the total number of un-ack'd PDUs (NOP-OUTs in this case), not the number per any specific CmdSN. Correct?" For the target, MaxOutstandingUnexpectedPDUs limits the unregulated and unexpected PDUs from the initiator. This is described in the Unregulated and Unexpected Category in the added text. It includes PDUs with the immediate flag set and the SNACK PDU. A unidirectional NOP-out PDU (where ITT = TTT = 0xffffffff) has the immediate flag set and so is included with the PDUs with the immediate flag set. The limit is not restricted to a specific CmdSN. For the initiator, MaxOutstandingUnexpectedPDUs limits all PDUs originated from the target which are not sent as a response to a request from the initiator. They do not carry CmdSN by definition. You wrote "Why 2**64-1? All the other counting in iSCSI uses 32-bit ints. Including the numbers we want to use for status acknowledgement. Thus I really don't see how we could need more than 2**32." I just want to pick a large number for the upper limit, and I can live with 32 bits. I can change the spec to reflect 32 bits if there are no objections. Mike To: Mike Ko cc: ips@ietf.org Subject: Re: [Ips] Updated text for MaxOutstandingUnexpectedPDUs for iSER On Nov 11, 2004, at 9:25 PM, Mike Ko wrote: > After thinking through the potential problem with overuse of the > unidirectional NOP-out PDUs, I concluded that the situation where the > initiator can send twice MaxOutstandUnexpectedPDUs cannot happen. > Even if > the initiator abuses the use of the unidirectional NOP-out PDUs, it can > only send MaxOutstandUnexpectedPDUs, but not twice the number. The > reasoning is as follows: > > For the unidirectional NOP-out, the CmdSN used is the next CmdSN and > the > variable is not advanced when the PDU is sent, and neither is > ExpCmdSN. So > for the target to respond with a PDU where ExpCmdSN is x+1 where x is > CmdSN of the NOP-out PDU, it must be acknowledging a non-immediate PDU > also with CmdSN = x. This must be sent after all the NOP-outs with > CmdSN > = x have been sent, since this non-immediate PDU will advance CmdSN. > Assuming the target has processed all the NOP-outs with the immediate > flag > set before the non-immediate PDU that follows, the receive buffers > should > be replenished. So even if the initiator sends a huge number of > NOP-outs > later after receiving a PDU from the target with ExpCmdSN = x+1, it > will > be using CmdSN = x+1 for those NOP-outs and there is no ambiguity on > the > CmdSN that the ExpCmdSN is acknowledging. So if the target has > provisions > for MaxOutstandUnexpectedPDUs number of receive buffers available, it > should be able to handle the unexpected NOP-out PDUs. Just to make sure I'm understanding things, MaxOutstandUnexpectedPDUs limits the total number of un-ack'd PDUs (NOP-OUTs in this case), not the number per any specific CmdSN. Correct? > For StatSN, the reasoning is similar since StatSN in the NOP-In is > interpreted as the next StatSN. > > The following is the updated text for the new key, > MaxOutstandingUnexpectedPDUs. Note that the default for the key is > TBD as > David Black has suggested in the 61st IETF meeting. The argument for > the > default being "None" is that it is the preferred value if the > implementation uses Shared RQ, supports graceful handling, or can > replenish receive buffers at wire speed. Please respond if you have a > suggestion for a different default value. > > Mike > -------------- start of new key definition --------------- > Use: LO (leading only), Declarative > > Senders: Initiator and Target > > Scope: SW (session-wide) > > Irrelevant when: RDMAExtensions=No > > MaxOutstandingUnexpectedPDUs= None> Why 2**64-1? All the other counting in iSCSI uses 32-bit ints. Including the numbers we want to use for status acknowledgement. Thus I really don't see how we could need more than 2**32. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 12 16:59:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05118 for ; Fri, 12 Nov 2004 16:59:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjTi-0002Eh-Ij for ips-web-archive@ietf.org; Fri, 12 Nov 2004 17:01:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjKw-0008WF-Ih; Fri, 12 Nov 2004 16:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjDd-000567-9v for ips@megatron.ietf.org; Fri, 12 Nov 2004 16:44:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04419 for ; Fri, 12 Nov 2004 16:44:26 -0500 (EST) Received: from host60a.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSj1C-0008Ce-Dl for ips@ietf.org; Fri, 12 Nov 2004 16:31:45 -0500 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id C7E9A11E15F; Fri, 12 Nov 2004 16:30:06 -0500 (EST) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64176-04; Fri, 12 Nov 2004 16:30:05 -0500 (EST) Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by host52a.simplicato.com (Postfix) with ESMTP id F224A11E3C0; Fri, 12 Nov 2004 16:30:02 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0C652A5A-34F2-11D9-B682-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [Ips] [iSCSI] iSER on InfiniBand Date: Fri, 12 Nov 2004 15:30:17 -0600 To: ips@ietf.org, John Hufferd X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at simplicato.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Eliminating the TCP dependencies in iSER would be a good idea. Once a connection between two RDMA Endpoints is established, iSER can be defined as a series of RDMA Messages. As such they are dependent only on RDMAP, and not on the underlying LLP. Adapting to other IP based transports would be easy, such as SCTP, and should be supported. It also enables non-IP transports, which is something that I do not believe anyone would object to, especially if a clarifying draft establishes how to do iSER over generic RDMA services without having to specify the mapping of generic RDMA services to any specific non-IP transport. The only missing service required is support of an initial message before endpoints are selected (the equivalent of the MPA Request and Reply messages and their private data). The key requirement is specifying that the private data contain enough information to enable RDMA endpoints to be selected. After that remaining iSCSI negotiations can be completed using Send messages. Private data exchange prior to pairing RDMA endpoints is already supported for both MPA/TCP and SCTP. The essential similarity is already documented in the RDDP applicability draft. If a "non-streaming mode" method of establishing an iSCSI connection is defined that is compatible with the existing private data exchange followed by Send messages for the remaining negotiations it will enable other IP transports, such as SCTP, and do so in a manner that is fully compatible with existing RDMA APIs such as DAPL and IT-API. It would also make it easy to port "non-TCP-dependent" iSER to non-IP transports, should anyone wish to do that outside the scope of the IETF. Eliminating iSERs dependency on a single RDMA transport is something that should be done anyway. The fact that doing so would be useful for InfiniBand ports is certainly not a reason to avoid doing something that should have been done in the first place. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 12 18:24:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11694 for ; Fri, 12 Nov 2004 18:24:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSkoH-0006J0-QG for ips-web-archive@ietf.org; Fri, 12 Nov 2004 18:26:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSkka-00027R-Qb; Fri, 12 Nov 2004 18:22:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSkjD-0001iR-57 for ips@megatron.ietf.org; Fri, 12 Nov 2004 18:21:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11569 for ; Fri, 12 Nov 2004 18:21:11 -0500 (EST) From: pat_thaler@agilent.com Received: from msgbas2x.cos.agilent.com ([192.25.240.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSkkV-000655-Iu for ips@ietf.org; Fri, 12 Nov 2004 18:22:46 -0500 Received: from pf-enccos5.cos.agilent.com (enccos5.cos.agilent.com [130.29.152.94]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id ABFCA9564 for ; Fri, 12 Nov 2004 16:20:58 -0700 (MST) Received: from enccos5.cos.agilent.com (localhost.localdomain [127.0.0.1]) by localhost.enccos5.cos.agilent.com (Postfix) with SMTP id 4D4E5C09C for ; Fri, 12 Nov 2004 16:21:37 -0700 (MST) Received: from relcos2.cos.agilent.com (130.29.152.237) by enccos5.cos.agilent.com (Sigaba Gateway v3.83) with ESMTP id 5103451; Fri, 12 Nov 2004 16:21:37 -0700 Received: from wcosvs02.cos.agilent.com (wcosvs02.cos.agilent.com [130.29.152.188]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 3B562C14 for ; Fri, 12 Nov 2004 16:20:58 -0700 (MST) Received: from wcosbh22.cos.agilent.com ([130.29.152.178]) by wcosvs02.cos.agilent.com with InterScan Messaging Security Suite; Fri, 12 Nov 2004 16:20:57 -0700 Received: from wcosmb05.cos.agilent.com ([130.29.152.72]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Nov 2004 16:20:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] Updated text for MaxOutstandingUnexpectedPDUs for iSER Date: Fri, 12 Nov 2004 16:20:56 -0700 Message-ID: <9418406DEC3B8A4BBDB1B87291D851AF0E759C@wcosmb05.cos.agilent.com> Thread-Topic: [Ips] Updated text for MaxOutstandingUnexpectedPDUs for iSER Thread-Index: AcTIeUNwt0Opp/xmSJ6gDtvPd05IeAAka/hg To: , X-OriginalArrivalTime: 12 Nov 2004 23:20:57.0193 (UTC) FILETIME=[4378C590:01C4C90E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Mike, I think there is a problem with the assumption that advance of ExpCmdSN = can be used to retire outstanding unexpected PDUs. The problem occurs = when there are multiple connections in a session. Description of how ExpCmdSN retires outstanding unexpected PDUs from = Mike Ko's message: "For the unidirectional NOP-out, the CmdSN used is the next CmdSN and = the=20 variable is not advanced when the PDU is sent, and neither is ExpCmdSN. = So=20 for the target to respond with a PDU where ExpCmdSN is x+1 where x is=20 CmdSN of the NOP-out PDU, it must be acknowledging a non-immediate PDU=20 also with CmdSN =3D x. This must be sent after all the NOP-outs with = CmdSN=20 =3D x have been sent, since this non-immediate PDU will advance CmdSN.=20 Assuming the target has processed all the NOP-outs with the immediate = flag=20 set before the non-immediate PDU that follows, the receive buffers = should=20 be replenished. So even if the initiator sends a huge number of = NOP-outs=20 later after receiving a PDU from the target with ExpCmdSN =3D x+1, it = will=20 be using CmdSN =3D x+1 for those NOP-outs and there is no ambiguity on = the=20 CmdSN that the ExpCmdSN is acknowledging. So if the target has = provisions=20 for MaxOutstandUnexpectedPDUs number of receive buffers available, it=20 should be able to handle the unexpected NOP-out PDUs." Let's look at a session with two connections. Call the connections c1 = and c2. The following are sent from iSCSI to the two connections (cmd(n) = indicates a non-immediate command with CmdSN n. imm(n) indicates an = immediate command carrying CmdSN n): time c1 c2 =20 | cmd(x-1) | imm(x) V imm(x) imm(x) cmd(x) Though all the imm(x) commands are sent by iSCSI before cmd(x), they may = arrive at the target in a different order: time c1 c2 =20 | cmd(x-1) | imm(x) V cmd(x) imm(x) imm(x) This could happen for many reasons. They could have been delayed by = congestion or a need to retransmit due to a lost packet. Perhaps the = initiator's RNIC on c1 received a large RDMA read request before it = received some of the commands and is completing the transmission of the = RDMA read response before it transmits them. When the target receives cmd(x) on c2, it will advance ExpCmdSN and it = has no way to know that there are outstanding unexpected PDUs. One can = really only retire outstanding unexpected PDUs when ExpCmdSN is advanced = past a CmdSN that was sent after them on the same connection - something = that adds additional complexity to this process. =20 =20 =20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 12 19:41:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15868 for ; Fri, 12 Nov 2004 19:41:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSm0b-0001Ce-Kj for ips-web-archive@ietf.org; Fri, 12 Nov 2004 19:43:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSlxO-00084P-54; Fri, 12 Nov 2004 19:39:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSlrM-0006EP-1Q for ips@megatron.ietf.org; Fri, 12 Nov 2004 19:33:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15429 for ; Fri, 12 Nov 2004 19:33:40 -0500 (EST) Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSlso-0000mP-W2 for ips@ietf.org; Fri, 12 Nov 2004 19:35:15 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAD0XBMW694736 for ; Fri, 12 Nov 2004 19:33:11 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAD0XBeS272484 for ; Fri, 12 Nov 2004 19:33:11 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAD0XBqi009959 for ; Fri, 12 Nov 2004 19:33:11 -0500 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAD0XBG5009954; Fri, 12 Nov 2004 19:33:11 -0500 In-Reply-To: <9418406DEC3B8A4BBDB1B87291D851AF0E759C@wcosmb05.cos.agilent.com> Importance: Normal MIME-Version: 1.0 To: Subject: RE: [Ips] Updated text for MaxOutstandingUnexpectedPDUs for iSER X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Fri, 12 Nov 2004 16:33:09 -0800 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M2_07222004 Beta 2|July 22, 2004) at 11/12/2004 19:33:11, Serialize complete at 11/12/2004 19:33:11 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Pat, Note that for immediate PDUs sent by the initiator requiring a response from the target, which include all the PDUs in the regulated category except that the immediate flags are set, the PDUs are retired (not outstanding) when the target responds with the corresponding response PDU. E.g., a Text Request PDU with the immediate flag set is not retired until the target responds with a Text Response PDU. So the only PDU with the immediate flag set that can be sent by the initiator that does not require a response from the target is the NOP-out PDU with ITT = TTT = 0xffffffff. This is the PDU which will be retired when the target responds with a PDU where ExpCmdSN = x+1 where x is the CmdSN of the NOP-out PDU. The iSCSI spec said that "A NOP-Out may also be used to confirm a changed ExpStatSN if another PDU will not be available for a long time." So for the initiator to send multiple unidirectional NOP-outs does not quite meet the spirit as intended in the iSCSI spec. However, the iSCSI spec does not explicitly prohibit the behavior. But your point is well taken that for multiple connections, the problem that I described in the 61st IETF meeting still exists. We have several alternatives: 1. Require that this NOP-out PDU is retired only when the target responds with ExpCmdSN = x+1 or larger on the same connection. 2. Add a cautionary note to warn against the behavior of sending undirectional NOP-out floods. 3. Suggest that undirectional NOP-outs not be used to avoid the ambiguity. Note that in the iSER spec, the recommended use for NOP-out is the bidirectional type. See section 7.3.5 and 7.3.6. I favor option 1, and suggesting option 3 at the same time for the implementation to avoid the complexity. Mike To: , cc: Subject: RE: [Ips] Updated text for MaxOutstandingUnexpectedPDUs for iSER Mike, I think there is a problem with the assumption that advance of ExpCmdSN can be used to retire outstanding unexpected PDUs. The problem occurs when there are multiple connections in a session. Description of how ExpCmdSN retires outstanding unexpected PDUs from Mike Ko's message: "For the unidirectional NOP-out, the CmdSN used is the next CmdSN and the variable is not advanced when the PDU is sent, and neither is ExpCmdSN. So for the target to respond with a PDU where ExpCmdSN is x+1 where x is CmdSN of the NOP-out PDU, it must be acknowledging a non-immediate PDU also with CmdSN = x. This must be sent after all the NOP-outs with CmdSN = x have been sent, since this non-immediate PDU will advance CmdSN. Assuming the target has processed all the NOP-outs with the immediate flag set before the non-immediate PDU that follows, the receive buffers should be replenished. So even if the initiator sends a huge number of NOP-outs later after receiving a PDU from the target with ExpCmdSN = x+1, it will be using CmdSN = x+1 for those NOP-outs and there is no ambiguity on the CmdSN that the ExpCmdSN is acknowledging. So if the target has provisions for MaxOutstandUnexpectedPDUs number of receive buffers available, it should be able to handle the unexpected NOP-out PDUs." Let's look at a session with two connections. Call the connections c1 and c2. The following are sent from iSCSI to the two connections (cmd(n) indicates a non-immediate command with CmdSN n. imm(n) indicates an immediate command carrying CmdSN n): time c1 c2 | cmd(x-1) | imm(x) V imm(x) imm(x) cmd(x) Though all the imm(x) commands are sent by iSCSI before cmd(x), they may arrive at the target in a different order: time c1 c2 | cmd(x-1) | imm(x) V cmd(x) imm(x) imm(x) This could happen for many reasons. They could have been delayed by congestion or a need to retransmit due to a lost packet. Perhaps the initiator's RNIC on c1 received a large RDMA read request before it received some of the commands and is completing the transmission of the RDMA read response before it transmits them. When the target receives cmd(x) on c2, it will advance ExpCmdSN and it has no way to know that there are outstanding unexpected PDUs. One can really only retire outstanding unexpected PDUs when ExpCmdSN is advanced past a CmdSN that was sent after them on the same connection - something that adds additional complexity to this process. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Nov 15 12:52:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14764 for ; Mon, 15 Nov 2004 12:52:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTl44-0003ry-DE for ips-web-archive@ietf.org; Mon, 15 Nov 2004 12:54:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTkuj-0007XV-NJ; Mon, 15 Nov 2004 12:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTksU-0006rY-8U for ips@megatron.ietf.org; Mon, 15 Nov 2004 12:43:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13999 for ; Mon, 15 Nov 2004 12:42:54 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTkuL-0003dj-WE for ips@ietf.org; Mon, 15 Nov 2004 12:45:04 -0500 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iAFHcVLZ186838; Mon, 15 Nov 2004 17:42:12 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAFAH8mP029020; Mon, 15 Nov 2004 11:17:31 +0100 In-Reply-To: <000601c4c8f4$af6454a0$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Subject: Re: [Ips] Long CDBs and bi-directional commands MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M2_07222004 Beta 2NP July 22, 2004 From: Julian Satran Message-ID: Date: Mon, 15 Nov 2004 12:17:26 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 15/11/2004 12:17:33, Serialize complete at 15/11/2004 12:17:33 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ips@ietf.org, michael.mesnier@intel.com, Kalman Meth X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0477130074==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 This is a multipart message in MIME format. --===============0477130074== Content-Type: multipart/alternative; boundary="=_alternative 00348AD3C2256F4D_=" This is a multipart message in MIME format. --=_alternative 00348AD3C2256F4D_= Content-Type: text/plain; charset="US-ASCII" Eddy, Object Storage uses both. It is likely that Intel's initiator uses both. Mike Mesnier may have some details about how to get to it.. Kalman may know about "variants" of the source-forge initiator that support them too. Regards, julo "Eddy Quicksall" Sent by: ips-bounces@ietf.org 12/11/04 22:17 To cc Subject [Ips] Long CDBs and bi-directional commands I would like to test long CDB's and bi-directional commands. Does anyone know of any initiator that uses these? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00348AD3C2256F4D_= Content-Type: text/html; charset="US-ASCII"
Eddy,

Object Storage uses both. It is likely that Intel's initiator uses both.
Mike Mesnier may have some details about how to get to it..
Kalman may know about "variants" of the source-forge initiator that support them too.

Regards,
julo


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

12/11/04 22:17

To
<ips@ietf.org>
cc
Subject
[Ips] Long CDBs and bi-directional commands





I would like to test long CDB's and bi-directional commands. Does anyone know of any initiator that uses these?
 
Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00348AD3C2256F4D_=-- --===============0477130074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0477130074==-- From ips-bounces@ietf.org Tue Nov 16 08:44:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28526 for ; Tue, 16 Nov 2004 08:44:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU3f7-0005iA-IR for ips-web-archive@ietf.org; Tue, 16 Nov 2004 08:46:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3au-00058y-US; Tue, 16 Nov 2004 08:42:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTn3l-00019W-DI for ips@megatron.ietf.org; Mon, 15 Nov 2004 15:02:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26244 for ; Mon, 15 Nov 2004 15:02:42 -0500 (EST) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTn5i-0006nk-9Q for ips@ietf.org; Mon, 15 Nov 2004 15:04:52 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id iAFK1vSq028842; Mon, 15 Nov 2004 20:01:58 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iAFJx22b014244; Mon, 15 Nov 2004 20:01:51 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004111512012230755 ; Mon, 15 Nov 2004 12:01:26 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Nov 2004 12:01:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Long CDBs and bi-directional commands Date: Mon, 15 Nov 2004 12:01:19 -0800 Message-ID: <750B55777FE4A94C8809877001F44F42026A4F36@orsmsx410> Thread-Topic: [Ips] Long CDBs and bi-directional commands Thread-Index: AcTLGtB1nHrOC9AEQJ2WxapYL+Fs9wAKsmRA From: "Mesnier, Michael" To: "Eddy Quicksall" X-OriginalArrivalTime: 15 Nov 2004 20:01:21.0529 (UTC) FILETIME=[E0A8B690:01C4CB4D] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.2 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 X-Mailman-Approved-At: Tue, 16 Nov 2004 08:42:02 -0500 Cc: ips@ietf.org, Julian Satran , Kalman Meth X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0075288316==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef This is a multi-part message in MIME format. --===============0075288316== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CB4D.E059F662" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4CB4D.E059F662 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eddy, =20 The code on source forge (http://www.sourceforge.net/projects/intel-iscsi) supports both in the initiator and target, but the scsi driver only uses extended CDBs (I believe you'll need to make some changes to the linux scsi stack to get bi-directional transfers working). =20 -Mike =20 ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Monday, November 15, 2004 5:17 AM To: Eddy Quicksall Cc: ips@ietf.org; Mesnier, Michael; Kalman Meth Subject: Re: [Ips] Long CDBs and bi-directional commands =20 Eddy,=20 Object Storage uses both. It is likely that Intel's initiator uses both. Mike Mesnier may have some details about how to get to it..=20 Kalman may know about "variants" of the source-forge initiator that support them too.=20 Regards,=20 julo=20 "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 12/11/04 22:17=20 To =20 cc =20 Subject [Ips] Long CDBs and bi-directional commands =20 =20 =20 I would like to test long CDB's and bi-directional commands. Does anyone know of any initiator that uses these?=20 =20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C4CB4D.E059F662 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Eddy,

 

The code on source forge (http://www.sourc= eforge.net/projects/intel-iscsi) supports both in the initiator and target, but the scsi driver only uses extended CDBs (I believe you’ll need to make some changes to the = linux scsi stack to get bi-directional transfers = working).

 

-Mike

 

From: = Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, November = 15, 2004 5:17 AM
To: Eddy Quicksall
Cc: ips@ietf.org; = Mesnier, Michael; Kalman Meth
Subject: Re: [Ips] Long = CDBs and bi-directional commands

 


Eddy,

Object Storage uses both. It is likely that Intel's initiator uses = both.
Mike Mesnier may have some details about how to get to it.. =
Kalman may know about "variants" of the source-forge initiator that = support them too.

Regards,
julo

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

12/11/04 22:17

To

<ips@ietf.org> =

cc

 

Subject

[Ips] Long CDBs and bi-directional = commands

 

 

 




I would = like to test long CDB's and bi-directional commands. Does anyone know of any = initiator that uses these?
 
Eddy______________________________________________= _
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

------_=_NextPart_001_01C4CB4D.E059F662-- --===============0075288316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0075288316==-- From ips-bounces@ietf.org Tue Nov 16 15:36:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10238 for ; Tue, 16 Nov 2004 15:36:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUA5m-0007MN-W9 for ips-web-archive@ietf.org; Tue, 16 Nov 2004 15:38:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9xk-00059t-Kw; Tue, 16 Nov 2004 15:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9vd-00041U-Gp for ips@megatron.ietf.org; Tue, 16 Nov 2004 15:27:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09245 for ; Tue, 16 Nov 2004 15:27:52 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9xt-00078W-So for ips@ietf.org; Tue, 16 Nov 2004 15:30:14 -0500 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 9CEED870AB; Tue, 16 Nov 2004 15:27:46 -0500 (EST) In-Reply-To: <000601c4c8f4$af6454a0$0303a8c0@ivvt2dxrc11> References: <000601c4c8f4$af6454a0$0303a8c0@ivvt2dxrc11> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: William Studenmund Subject: Re: [Ips] Long CDBs and bi-directional commands Date: Tue, 16 Nov 2004 12:27:33 -0800 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1182387321==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 --===============1182387321== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--76907691" --Apple-Mail-2--76907691 Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--76907696; protocol="application/pkcs7-signature" --Apple-Mail-1--76907696 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 12, 2004, at 12:17 PM, Eddy Quicksall wrote: > I would like to test long CDB's and bi-directional commands. Does > anyone know of any initiator that uses these? I'm not familiar with how other OSs handle this, but I believe all of the *BSDs support (privileged) programs sending SCSI commands directly to a device. So you could just write a program to make an initiator send such commands. Take care, Bill --Apple-Mail-1--76907696 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfDCCBXgw ggNgoAMCAQICAUYwDQYJKoZIhvcNAQEEBQAwga0xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcg WW9yazERMA8GA1UEBxMITmV3IFlvcmsxHTAbBgNVBAoTFFdhc2FiaSBTeXN0ZW1zLCBJbmMuMQww CgYDVQQLEwNHSFExHzAdBgNVBAMTFldhc2FiaSBTeXN0ZW1zIFJvb3QgQ0ExKjAoBgkqhkiG9w0B CQEWG3dlYm1hc3RlckB3YXNhYmlzeXN0ZW1zLmNvbTAeFw0wMzA4MTExODU2NDZaFw0wODA2MjUx ODU2NDZaMIGXMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU2Fu IERpZWdvMRcwFQYDVQQKEw5XYXNhYmkgU3lzdGVtczEbMBkGA1UEAxMSV2lsbGlhbSBTdHVkZW5t dW5kMSkwJwYJKoZIhvcNAQkBFhp3cnN0dWRlbkB3YXNhYmlzeXN0ZW1zLmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA9CZhg4GVWYTRGcJz8lU1ipzInlBuGqfZQs88Z1rTP7+c3AyhKwpE TyTmK4UhxslzKa93YLqifLxZKYt1jI6FNq40IQWCKBVywWBwmL5guCu0851f9ywH5Uj2wJdiDrOI sOJKNpwNqml8bFdTrFS2qvyCxTIWVMLYAzUBBcl2F7MCAwEAAaOCATkwggE1MAkGA1UdEwQCMAAw LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBTt mjHbSBlMV48RWOBETM3EV0Tm/jCB2gYDVR0jBIHSMIHPgBQrBOnN88CNCHPaV5wLS212tcrgBaGB s6SBsDCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9y azEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMW V2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5 c3RlbXMuY29tggEAMA0GCSqGSIb3DQEBBAUAA4ICAQCpxoPEYunR7qiXyycEZd0UIatSt/WalMoH nuN9S421iS/sD1wSDqzHyM5YyUWn4z4o6VhT2kD9UV4lk5aXxxefEfGzFcR7Xyah7tO3ziuReFfx qUP5+DTlwDuUBc8Iow6NwY9GlRCKFSsEroLWLGODyYWgN1ojjKOtcXRiOZkYTP3VfDUV2/Xrhh9O l6+3Otf069+KWeOWedWeMsbe1rac96yPEjPogToWkBXVJEeEQktd0BLETt7GUuSZg2Fho/nslqZv nnnKZmrOfdFy9iXDL9T0Hp/OHf5B9RP+r00BJJFO8JzBPIL2IA3CBPApOQty5A00Jg1CGfDQxiV3 s8G0aRUbmFqg9r0OfhPYjJ8BHfw1HHWb7Cu91Sw+d5UnYracZhsR2Gc5H5CnfS6IZhc7ulfnSX8f I4BXR4vbeRUG76J3rkkbkO1haYHLk5w5RlICHsJOBSElG9ggLBWNIfUZwAzo84lfmDmJMP1YCOmi DFCbW1DgxhqVFpYEf5Pq2pVcCguopK2G9oZjH5fxq6ehisk9dN+7NEQ4OSqC43ehaStYOoQAJruN e6e5tCtRMx7bMI7eVPiHxE9/Y38Q+sc5oRN9mCyyAXMweuMRNHAHAWdFB7NhHD6gBa2lh91zIMdf iSVRlBXoMrBKJX6VecgnhvUp4G6QAnN7EMu6QHlc/jGCA0swggNHAgEBMIGzMIGtMQswCQYDVQQG EwJVUzERMA8GA1UECBMITmV3IFlvcmsxETAPBgNVBAcTCE5ldyBZb3JrMR0wGwYDVQQKExRXYXNh YmkgU3lzdGVtcywgSW5jLjEMMAoGA1UECxMDR0hRMR8wHQYDVQQDExZXYXNhYmkgU3lzdGVtcyBS b290IENBMSowKAYJKoZIhvcNAQkBFht3ZWJtYXN0ZXJAd2FzYWJpc3lzdGVtcy5jb20CAUYwCQYF Kw4DAhoFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQx MTE2MjAyNzMzWjAjBgkqhkiG9w0BCQQxFgQU/6IHEtHPxr1NB5h4s0WfN7R2wOswgcQGCSsGAQQB gjcQBDGBtjCBszCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhO ZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0G A1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdh c2FiaXN5c3RlbXMuY29tAgFGMIHGBgsqhkiG9w0BCRACCzGBtqCBszCBrTELMAkGA1UEBhMCVVMx ETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5 c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBD QTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5c3RlbXMuY29tAgFGMA0GCSqGSIb3 DQEBAQUABIGANQxKO/UsR4+v5cTb8zFaABLB3kHZ80pBTnDNTI7imxLgJNZMURi2cwdHKP7fJZSl dbLbCvKEelW7VoNtwVX60nzyRttV1nkD1OtLy97nqm0xNr4pxhBuXcd4VYlx9flhFcqShdfeYHae AVwR/aG5dFK7Z3DXnw9Nuizt49BxweQAAAAAAAA= --Apple-Mail-1--76907696-- --Apple-Mail-2--76907691 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBmmLDDJT2Egh26K0RAtlSAJoDCMaz+2tPjywDwyl8jhUvrYXIjwCgjG+n BHmy8RpW/PEmqRu47f8oFuA= =u/aB -----END PGP SIGNATURE----- --Apple-Mail-2--76907691-- --===============1182387321== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1182387321==-- From ips-bounces@ietf.org Tue Nov 16 17:38:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03520 for ; Tue, 16 Nov 2004 17:38:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBzx-0005WQ-Ey for ips-web-archive@ietf.org; Tue, 16 Nov 2004 17:40:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBjx-0003ap-Mk; Tue, 16 Nov 2004 17:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAz1-0006th-Cb for ips@megatron.ietf.org; Tue, 16 Nov 2004 16:35:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18114 for ; Tue, 16 Nov 2004 16:35:25 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUB1H-0000c9-Rl for ips@ietf.org; Tue, 16 Nov 2004 16:37:49 -0500 Received: from [24.10.156.180] (c-24-10-156-180.client.comcast.net[24.10.156.180]) by comcast.net (sccrmhc11) with SMTP id <20041116213440011000rfrce>; Tue, 16 Nov 2004 21:34:40 +0000 In-Reply-To: References: <000601c4c8f4$af6454a0$0303a8c0@ivvt2dxrc11> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <51AE446E-3817-11D9-87D0-000393A22C62@ieee.org> Content-Transfer-Encoding: 7bit From: Pat LaVarre Subject: Re: [Ips] Long CDBs and bi-directional commands Date: Tue, 16 Nov 2004 14:34:38 -0700 To: William Studenmund X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, Eddy Quicksall X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit >> I would like to test long CDB's and bi-directional commands. Does >> anyone know of any initiator that uses these? > > I'm not familiar with how other OSs handle this, but I believe all of > the *BSDs support (privileged) programs sending SCSI commands directly > to a device. So you could just write a program to make an initiator > send such commands. Elsewhere I've seen SCSI pass thru facilities commonly require root privilege, limit CDB's to 16 or to 12 bytes max, and pass data thru only in or only out ... and the Mac OS X derivative of BSD requires PDT = x05 = DVD/ CD and rewritability for SCSI pass thru ... but maybe life in many BSD is better, I don't know. Pat LaVarre http://plavarre.blog-city.com/read/614076.htm _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 19 16:43:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27202 for ; Fri, 19 Nov 2004 16:43:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVGai-0002pK-5H for ips-web-archive@ietf.org; Fri, 19 Nov 2004 16:46:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVGLg-0003om-48; Fri, 19 Nov 2004 16:31:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVFRa-0006oS-Hy for ips@megatron.ietf.org; Fri, 19 Nov 2004 15:33:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12195 for ; Fri, 19 Nov 2004 15:33:20 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVFUS-0006NW-NC for ips@ietf.org; Fri, 19 Nov 2004 15:36:22 -0500 Received: from phys-giza-1 ([129.147.4.102]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAJKXJup007050 for ; Fri, 19 Nov 2004 13:33:19 -0700 (MST) Received: from conversion-daemon.giza-mail1.Central.Sun.COM by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I7G00B01117S8@giza-mail1.Central.Sun.COM> (original mail from David.Weibel@Sun.COM) for ips@ietf.org; Fri, 19 Nov 2004 13:33:19 -0700 (MST) Received: from [172.20.56.104] (batara.Central.Sun.COM [172.20.56.104]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I7G00M5113JS8@giza-mail1.Central.Sun.COM> for ips@ietf.org; Fri, 19 Nov 2004 13:33:19 -0700 (MST) Date: Fri, 19 Nov 2004 13:33:28 -0700 From: David Weibel To: ips@ietf.org Message-id: <452EF102-3A6A-11D9-92AE-000A95B1A482@sun.com> MIME-version: 1.0 (Apple Message framework v619) X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7BIT Subject: [Ips] maxcmdsn during discovery sessions? X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7BIT We encountered a target that always returns a MaxCmdSn = 0 during a discovery session. Is CmdSn windowing not required during discovery sessions when sending Text Requests? I haven't found anything in the RFC to suggest cmdsn is only for discovery sessions. Thanks for any pointers. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Nov 22 12:50:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26440 for ; Mon, 22 Nov 2004 12:50:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIEe-0003jC-FG for ips-web-archive@ietf.org; Mon, 22 Nov 2004 12:44:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWHph-0005jM-7U; Mon, 22 Nov 2004 12:18:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWHcJ-0001fD-0X for ips@megatron.ietf.org; Mon, 22 Nov 2004 12:04:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17737 for ; Mon, 22 Nov 2004 12:04:40 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWHfk-0006nL-3O for ips@ietf.org; Mon, 22 Nov 2004 12:08:19 -0500 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 6543B87085; Mon, 22 Nov 2004 12:04:32 -0500 (EST) In-Reply-To: <452EF102-3A6A-11D9-92AE-000A95B1A482@sun.com> References: <452EF102-3A6A-11D9-92AE-000A95B1A482@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <8F1D82F4-3CA8-11D9-B9F6-000A95D14BEC@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] maxcmdsn during discovery sessions? Date: Mon, 22 Nov 2004 09:04:23 -0800 To: David Weibel X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0704073616==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --===============0704073616== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-429295862" --Apple-Mail-1-429295862 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 19, 2004, at 12:33 PM, David Weibel wrote: > We encountered a target that always returns a MaxCmdSn = 0 during > a discovery session. Is CmdSn windowing not required during discovery > sessions when sending Text Requests? I haven't found anything in the > RFC to suggest cmdsn is only for discovery sessions. Sounds like a buggy target. I am aware of nothing in the spec that limits command windowing to only non-discovery sessions. Take care, Bill --Apple-Mail-1-429295862 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBohwdDJT2Egh26K0RAiZ0AKCWFLUcKXDRp4oFrThjQWJGiOPuAwCgn1+s uk0yjRB2hiU0rb80ApLkPYQ= =/R+G -----END PGP SIGNATURE----- --Apple-Mail-1-429295862-- --===============0704073616== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0704073616==-- From ips-bounces@ietf.org Mon Nov 22 19:46:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12812 for ; Mon, 22 Nov 2004 19:46:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWOsd-00013J-VK for ips-web-archive@ietf.org; Mon, 22 Nov 2004 19:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWOm6-0004Fp-A0; Mon, 22 Nov 2004 19:43:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWOiu-0003aS-6g for ips@megatron.ietf.org; Mon, 22 Nov 2004 19:40:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12324 for ; Mon, 22 Nov 2004 19:39:57 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWOmS-0000GI-NW for ips@ietf.org; Mon, 22 Nov 2004 19:43:41 -0500 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAN0dumi029009 for ; Mon, 22 Nov 2004 19:39:57 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Nov 2004 19:39:56 -0500 Message-ID: To: ips@ietf.org Subject: RE: [Ips] Draft DC minutes Date: Mon, 22 Nov 2004 19:39:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.22.29 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Having seen no comments, these are the final minutes that will be sent to the secretariat for the proceedings, and the decisions made in DC are now the rough consensus of the IP Storage WG. The iSER draft authors should take this as a cue to start list discussion on their [Open Issue]'s identified below. Thanks, --David > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Black_David@emc.com > Sent: Friday, November 12, 2004 11:26 AM > To: ips@ietf.org > Subject: [Ips] Draft DC minutes > > Send comments/corrections/etc. to me (and the list if you > think they're important). This also serves as an announcement > of the sense of the room decisions taken in DC - in the > absence of objection on the list, they are the rough consensus > of the IPS WG. The most important decision is on the limit > for # of outstanding unexpected PDUs for iSER - see below. > > Thanks, > --David > > IP Storage (ips) WG - Washington DC minutes - DRAFT > --------------------------------------------------- > > The IP Storage (ips) WG meets 1300-1500 on Monday, > November 8, 2004 at the IETF meetings in Washington, DC. > > AGENDA and MINUTES > ------------------ > > Letters in square brackets (e.g., [A]) indicate first character in > filename of presenation. > > Administrivia, agenda bashing, draft status review, etc.: [A] 15 min > David Black, EMC (co-chair) > Blue sheets > Note Well > Milestones - iSER and DA to ADs in April/May 2005 > Draft status > - All protocol drafts are in RFC Editor queue > - iSNS DHC option will be there shortly after meeting > - FCIP SLP template probably needs an errata to correct > version # in template from 0.1 to 1.0 > - Waiting on new versions of iSCSI MIB, iSCSI Auth MIB > and FCIP MIB from draft authors. > - iFCP and iSNS MIBs need author attention > > Any open MIB issues: [no slides] 15 min Elizabeth Rodriguez, > Dot Hill (co-chair) > FC Management MIB (draft-ietf-ips-fcmgmt-mib-05.txt) > - New field to be added to deal with a MIB instance that > covers multiple switches. This was submitted as an > IETF Last Call comment, but got lost. -06 version of > MIB will be produced containing all agreed-to changes > from -05 plus this change. Message will be sent to > list to do a quick review of this final change. > > iSER and DA: [B] 1 hour Mike Ko, IBM > (draft-ietf-ips-iser-00.txt) > (draft-ietf-ips-iwarp-da-00.txt) > iSER = iSCSI Extensions for RDMA > DA = Datamover Architecture for iSCSI > > Control of unexpected PDUs > - Sense of room: Using a key to limit # of outstanding unexpected > PDUs is the right approach. "None" = "No Limit" is allowed. > Minimum value (e.g., to avoid 1 or 2) is TBD [Open Issue] > - Specified default value (None vs. specific value) in > absence of negotiation will be taken to list. [Open Issue] > - Draft will need to contain discussion of unexpected vs. > expected PDUs and buffering requirements, and when > an unexpected PDU ceases to be outstanding. > - Add cautionary notes to avoid NOP-out and NOP-in abuse, > but take this to the list, as there may be a possibility > of being able to specify initiator behavior that always > works. [Open Issue] > > iSER over InfiniBand: [C] 30 min John Hufferd, IBM > No draft available. This time period is for discussion of > possible work to support iSCSI over InfiniBand via iSER. > The primary purpose of this time is a discussion of whether > the IETF should undertake work in this area, and if so, what > scope of work is appropriate (e.g., to avoid all of us > having to become InfiniBand experts). > > Proposal is iSER over InfiniBand to enable use of iSCSI > > Terminology: RDMAP should be for the RDDP WG protocol only, > and not generalized as proposed in the slides. > > Resolution: No real conclusion. Enabling reuse of IETF > technology like iSCSI/iSER in other environments is a > "good thing" in principle. OTOH, our AD is concerned > about InfiniBand protocols (e.g., RC) getting out > onto the Internet and causing problems. Proponents should > produce Internet-Draft addressing architecture, intended > usage, Infiniband to IP/Internet proxy (in particular, > protocol stack layer diagram) and proposed division of > work between IETF and IBTA that avoids need for serious > InfiniBand expertise in IETF (e.g., the work needed > to cope with old implementations of InfiniBand appears > to belong in IBTA, not IETF). Based on WG discussion > of that draft, the WG co-chairs, and ADs can determine > appropriate next steps. > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 26 01:18:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27223 for ; Fri, 26 Nov 2004 01:18:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXZV6-0008DA-D4 for ips-web-archive@ietf.org; Fri, 26 Nov 2004 01:22:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXZNC-00029s-FS; Fri, 26 Nov 2004 01:14:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXZKd-00016s-98 for ips@megatron.ietf.org; Fri, 26 Nov 2004 01:11:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26821 for ; Fri, 26 Nov 2004 01:11:46 -0500 (EST) Received: from web50405.mail.yahoo.com ([206.190.38.70]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXZOg-00086a-4X for ips@ietf.org; Fri, 26 Nov 2004 01:16:09 -0500 Received: (qmail 50400 invoked by uid 60001); 26 Nov 2004 06:11:04 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Kg2bdDitkee/cz1t16kpdk8r5yOpa37RcfCEfJvPT/4ZcHm2GbYvIwST5N1+ULN11Sc1sR/ZRyJ/TJmOSBDGAAE5bvGuT0FCqK10sE3poZEqe+WOcLNJRmnkV/V323Y1InI5chcrja3ScDvQoAYfCmJ5YA9C5WQt8uHXGIN7pwc= ; Message-ID: <20041126061104.50398.qmail@web50405.mail.yahoo.com> Received: from [203.187.215.134] by web50405.mail.yahoo.com via HTTP; Thu, 25 Nov 2004 22:11:04 PST Date: Thu, 25 Nov 2004 22:11:04 -0800 (PST) From: ulka vaze To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ips] problem writing files above 64KB with microsoft initiator X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi all: I have developed iSCSI target on MAC OSx.I am testing with Microsoft Initiator.When we write files below 64KB we are able to read them correctly.But if files are above this size our data get corrupted.We have also found that with one scsi write command initiator sends maximum 64KB of data so we get multiple writes. For testing; We are creating text file in wordpad and reading it back.What could be the problem? Pl. help thanks ulka __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 26 10:44:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20358 for ; Fri, 26 Nov 2004 10:44:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXiKn-0004DG-5r for ips-web-archive@ietf.org; Fri, 26 Nov 2004 10:48:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXi4R-0007go-45; Fri, 26 Nov 2004 10:31:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhoS-0007ga-5k for ips@megatron.ietf.org; Fri, 26 Nov 2004 10:15:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17146 for ; Fri, 26 Nov 2004 03:10:10 -0500 (EST) Received: from web50401.mail.yahoo.com ([206.190.38.66]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXbFR-000223-CX for ips@ietf.org; Fri, 26 Nov 2004 03:14:34 -0500 Received: (qmail 5233 invoked by uid 60001); 26 Nov 2004 08:09:29 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=iYhaLcL0HibOjJ+xW2AKEqVF42Ow4feqPLJ/DQg4OkTBvIF47bUQ2VK+6ZTQhpefSZ3xgS4l/zdddj8hZ2MwJhNw9OAyD00uDZHrf90YQuC50ML7+YN803/EXZtbEonnMfh3p8Q6zpLx4Rjg/XUGlszH5W3wA+m/vPoW5eaeaB4= ; Message-ID: <20041126080929.5231.qmail@web50401.mail.yahoo.com> Received: from [203.187.215.134] by web50401.mail.yahoo.com via HTTP; Fri, 26 Nov 2004 00:09:29 PST Date: Fri, 26 Nov 2004 00:09:29 -0800 (PST) From: ulka vaze To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ips] iscsi opcode 0x33 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi all: i am testing my iscsi target with microsoft initiator .When i do data transfer of large files(say above 2MB) microsoft initiator sends opcode 0x33 and sometimes 0x49.What is meaning of these opcodes? Does any one know? Pl reply as i am badly stuck up here. thanks ulka __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Nov 29 07:39:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13557 for ; Mon, 29 Nov 2004 07:39:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYktG-0007rq-Gz for ips-web-archive@ietf.org; Mon, 29 Nov 2004 07:44:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkfc-0000mq-Vw; Mon, 29 Nov 2004 07:30:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkcK-0008Sg-9y for ips@megatron.ietf.org; Mon, 29 Nov 2004 07:26:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07459 for ; Mon, 29 Nov 2004 06:19:43 -0500 (EST) Received: from vmail.vsnl.com ([203.199.113.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYjeC-0006Ci-03 for ips@ietf.org; Mon, 29 Nov 2004 06:24:49 -0500 Received: from Manohar ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0I7X00GCCU3SCV@vmail.vsnl.com> for ips@ietf.org; Mon, 29 Nov 2004 16:49:05 +0530 (IST) Received: from ([tataelxsi.co.in (203.197.169.3)]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Mon, 29 Nov 2004 16:49:05 +0530 (IST) Date: Mon, 29 Nov 2004 16:49:25 +0530 From: Manohars To: ips@ietf.org Message-id: <00a801c4d605$49620e40$3446010a@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7BIT Subject: [Ips] TargetPortalGroupTag parameter negotiation... X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7BIT Sir, Section 12.9 says about the TargetPortalGroupTag as: "The iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has the C bit set to 0." But in the case of UNH-iSCSI Target this is not the behavior. i.e., it will not return the TargetPortalGroupTag key-value pair.(The same information will be provided in response to the SendTargets as TargetAddress key-value pair during the discovery session). But from Microsoft Initiator even if we do Static Target Configuration and do the login, the MS Initiator quietly accepts the response without TargetPortalGroupTag and proceeds to the next stage. Currently our implementation is not supporting Discovery session and we are expecting the TargetPortalGroupTag to be returned with the First Login response PDU. What should we do? shall we accept the response and proceed to the next stage or drop the session (current implementation). Thanks in advance, with regards, Manohar S. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Nov 29 10:05:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27643 for ; Mon, 29 Nov 2004 10:05:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnAX-0003WM-6k for ips-web-archive@ietf.org; Mon, 29 Nov 2004 10:10:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYmsA-00059U-M8; Mon, 29 Nov 2004 09:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYmlb-0003OQ-76 for ips@megatron.ietf.org; Mon, 29 Nov 2004 09:44:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25621 for ; Mon, 29 Nov 2004 09:44:37 -0500 (EST) Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYmqV-0002vz-TA for ips@ietf.org; Mon, 29 Nov 2004 09:49:44 -0500 Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.13.1/8.13.1) with ESMTP id iATEi538009876; Mon, 29 Nov 2004 09:44:05 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.13.1/8.13.1/Submit) with ESMTP id iATEi5QX009873; Mon, 29 Nov 2004 09:44:05 -0500 Date: Mon, 29 Nov 2004 09:44:05 -0500 (EST) From: "Robert D. Russell" To: Manohars Subject: Re: [Ips] TargetPortalGroupTag parameter negotiation... In-Reply-To: <00a801c4d605$49620e40$3446010a@telxsi.com> Message-ID: References: <00a801c4d605$49620e40$3446010a@telxsi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-UNH-IOL-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-UNH-IOL-MailScanner: Found to be clean X-MailScanner-From: rdr@io.iol.unh.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Manohar: > Section 12.9 says about the TargetPortalGroupTag as: "The iSCSI target > returns this key to the initiator in the Login Response PDU to the first > Login Request PDU that has the C bit set to 0." > > But in the case of UNH-iSCSI Target this is not the behavior. i.e., it will > not return the TargetPortalGroupTag key-value pair. The UNH-iSCSI Target can be configured to either send or not send the TargetPortalGroupTag key-value pair. You must not have it configured correctly. I suggest we take this thread off the reflector to discuss the details, since this has nothing to do with the iSCSI standard. Best, Bob Russell rdr@iol.unh.edu > (The same information > will be provided in response to the SendTargets as TargetAddress key-value > pair during the discovery session). > But from Microsoft Initiator even if we do Static Target Configuration and > do the login, the MS Initiator quietly accepts the response without > TargetPortalGroupTag and proceeds to the next stage. > > Currently our implementation is not supporting Discovery session and we are > expecting the TargetPortalGroupTag to be returned with the First Login > response PDU. What should we do? shall we accept the response and proceed to > the next stage or drop the session (current implementation). > > Thanks in advance, > > with regards, > Manohar S. > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Nov 29 10:40:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02439 for ; Mon, 29 Nov 2004 10:40:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYniy-0004R2-O9 for ips-web-archive@ietf.org; Mon, 29 Nov 2004 10:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnRr-00027O-6j; Mon, 29 Nov 2004 10:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnOG-0000Y2-0e for ips@megatron.ietf.org; Mon, 29 Nov 2004 10:24:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00785 for ; Mon, 29 Nov 2004 10:24:34 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYnTA-00043L-CK for ips@ietf.org; Mon, 29 Nov 2004 10:29:41 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iATFOTT3026665; Mon, 29 Nov 2004 10:24:29 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Nov 2004 10:24:30 -0500 Message-ID: To: ulkav@yahoo.com, ips@ietf.org Subject: RE: [Ips] iscsi opcode 0x33 Date: Mon, 29 Nov 2004 10:24:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.28.45 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, TO_HAS_SPACES 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Ulka, This is really not an appropriate forum for debugging your target implementation. Please work directly with Microsoft for support in using their iSCSI initiator. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of ulka vaze > Sent: Friday, November 26, 2004 3:09 AM > To: ips@ietf.org > Subject: [Ips] iscsi opcode 0x33 > > Hi all: > i am testing my iscsi target with microsoft initiator > .When i do data transfer of large files(say above 2MB) > microsoft initiator sends opcode 0x33 and sometimes > 0x49.What is meaning of these opcodes? > Does any one know? > Pl reply as i am badly stuck up here. > thanks > ulka > > > > __________________________________ > Do you Yahoo!? > The all-new My Yahoo! - What will yours do? > http://my.yahoo.com > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Nov 29 17:50:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22844 for ; Mon, 29 Nov 2004 17:50:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYuQp-0001hz-Jp for ips-web-archive@ietf.org; Mon, 29 Nov 2004 17:55:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYuHd-0000aU-Ih; Mon, 29 Nov 2004 17:46:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYu7f-0005C7-KQ for ips@megatron.ietf.org; Mon, 29 Nov 2004 17:35:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21585 for ; Mon, 29 Nov 2004 17:35:53 -0500 (EST) Received: from smtp103.rog.mail.re2.yahoo.com ([206.190.36.81]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYuCd-0001Eg-SR for ips@ietf.org; Mon, 29 Nov 2004 17:41:05 -0500 Received: from unknown (HELO Doranto) (BillMurray@rogers.com@65.48.112.58 with login) by smtp103.rog.mail.re2.yahoo.com with SMTP; 29 Nov 2004 22:35:22 -0000 Message-ID: <001101c4d663$f0db5970$6502a8c0@Doranto> From: "BillMurray" To: Date: Mon, 29 Nov 2004 17:36:45 -0500 Organization: Storola 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Ips] Clarification of MaxBurstLength parameter X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: BillMurray List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Am I correct in thinking that MaxBurstLength governs the TOTAL amount of solicited data sent across the 'entire sequence' of Data-in/Data-out PDU's or is it the maximum length of just one Data-in/Data-out PDU? 12.13. MaxBurstLength The initiator and target negotiate maximum SCSI data payload in bytes in a Data-In or a solicited Data-Out iSCSI sequence. A sequence consists of one or more consecutive Data-In or Data-Out PDUs that end with a Data-In or Data-Out PDU with the F bit set to one. Thanks in advance, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Nov 30 17:37:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24229 for ; Tue, 30 Nov 2004 17:37:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGiG-0005VE-JN for ips-web-archive@ietf.org; Tue, 30 Nov 2004 17:43:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGFh-0007lw-P6; Tue, 30 Nov 2004 17:13:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFJz-0003WQ-PR for ips@megatron.ietf.org; Tue, 30 Nov 2004 16:14:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08382 for ; Tue, 30 Nov 2004 16:14:01 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFP6-0000NW-Ur for ips@ietf.org; Tue, 30 Nov 2004 16:19:25 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iAULDNug210456 for ; Tue, 30 Nov 2004 21:13:23 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAULDXvH070736 for ; Tue, 30 Nov 2004 22:13:33 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iAULDNv8030883 for ; Tue, 30 Nov 2004 22:13:23 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iAULDNJF030880; Tue, 30 Nov 2004 22:13:23 +0100 In-Reply-To: <001101c4d663$f0db5970$6502a8c0@Doranto> To: BillMurray Subject: Re: [Ips] Clarification of MaxBurstLength parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M2_07222004 Beta 2NP July 22, 2004 From: Julian Satran Message-ID: Date: Tue, 30 Nov 2004 23:13:28 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 30/11/2004 23:13:28, Serialize complete at 30/11/2004 23:13:28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1151384248==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multipart message in MIME format. --===============1151384248== Content-Type: multipart/alternative; boundary="=_alternative 005B6A88C2256F5C_=" This is a multipart message in MIME format. --=_alternative 005B6A88C2256F5C_= Content-Type: text/plain; charset="US-ASCII" ips-bounces@ietf.org wrote on 11/30/2004 12:36:45 AM: > Am I correct in thinking that MaxBurstLength governs the TOTAL amount > of solicited data sent across the 'entire sequence' of Data-in/Data-out > PDU's or is it the maximum length of just one Data-in/Data-out PDU? > TOTAL of a sequence not the whole command. > 12.13. MaxBurstLength > > The initiator and target negotiate maximum SCSI data payload in bytes > in a Data-In or a solicited Data-Out iSCSI sequence. A sequence > consists of one or more consecutive Data-In or Data-Out PDUs that end > with a Data-In or Data-Out PDU with the F bit set to one. > > Thanks in advance, > Bill > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005B6A88C2256F5C_= Content-Type: text/html; charset="US-ASCII"

ips-bounces@ietf.org wrote on 11/30/2004 12:36:45 AM:

> Am I correct in thinking that MaxBurstLength governs the TOTAL amount
> of solicited data sent across the 'entire sequence' of Data-in/Data-out
> PDU's or is it the maximum length of just one Data-in/Data-out PDU?
>

TOTAL of a sequence not the whole command.

> 12.13.  MaxBurstLength
>
> The initiator and target negotiate maximum SCSI data payload in bytes
> in a Data-In or a solicited Data-Out iSCSI sequence.  A sequence
> consists of one or more consecutive Data-In or Data-Out PDUs that end
> with a Data-In or Data-Out PDU with the F bit set to one.
>
> Thanks in advance,
> Bill
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 005B6A88C2256F5C_=-- --===============1151384248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1151384248==-- From ips-bounces@ietf.org Tue Nov 30 21:22:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14147 for ; Tue, 30 Nov 2004 21:22:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZKEB-0002NU-E9 for ips-web-archive@ietf.org; Tue, 30 Nov 2004 21:28:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZK4L-0002qt-4z; Tue, 30 Nov 2004 21:18:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZJjd-0005Q7-5K for ips@megatron.ietf.org; Tue, 30 Nov 2004 20:56:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12230 for ; Tue, 30 Nov 2004 20:56:46 -0500 (EST) Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZJop-0001oQ-Ty for ips@ietf.org; Tue, 30 Nov 2004 21:02:12 -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 D045911DE1 for ; Tue, 30 Nov 2004 17:56:05 -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 9E10F38C3F for ; Tue, 30 Nov 2004 17:55:34 -0800 (PST) Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.6) id 26004-4E30B82A; Tue, 30 Nov 2004 17:55:34 -0800 Received: from duala1.corp.silverbacksystems.com (duala1.corp.silverbacksystems.com [10.0.16.56]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 574BB38C3F for ; Tue, 30 Nov 2004 17:55:34 -0800 (PST) From: Gwendal Grignou To: ips@ietf.org Content-Type: text/plain Message-Id: <1101866113.1520.18.camel@duala1.corp.silverbacksystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 30 Nov 2004 17:55:13 -0800 Content-Transfer-Encoding: 7bit X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.24.0.7; VDF: 6.24.0.88; host: ns.silverbacksystems.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Ips] Update StatSN after sending a Reject PDU X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Hello, I am wondering if the target must increase the connection StatSN after sending a reject PDU. In the RFC, it is stated 10.17.3 StatSN, ExpCmdSN and MaxCmdSN These fields carry their usual values and are not related to the rejected command It is not clear to me if StatSN must be incremented after sending the PDU or not. I would say no, but I would like a confirmation. Thank you, Gwendal. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Nov 30 21:49:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15995 for ; Tue, 30 Nov 2004 21:49:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZKdU-0002yL-4S for ips-web-archive@ietf.org; Tue, 30 Nov 2004 21:54:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKTe-0004qC-3Y; Tue, 30 Nov 2004 21:44:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKNP-00039F-Mt for ips@megatron.ietf.org; Tue, 30 Nov 2004 21:37:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15292 for ; Tue, 30 Nov 2004 21:37:53 -0500 (EST) Received: from email.crossroads.com ([65.68.235.6]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZKSe-0002kH-36 for ips@ietf.org; Tue, 30 Nov 2004 21:43:20 -0500 Received: from mailnode1.COMMSTOR.Crossroads.com ([192.168.1.249]) by email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Nov 2004 20:37:13 -0600 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] Update StatSN after sending a Reject PDU Date: Tue, 30 Nov 2004 20:37:13 -0600 Message-ID: <43F5E8AE07F17C47BC16F7A159E9E7006C68@mailnode1.commstor.crossroads.com> Thread-Topic: [Ips] Update StatSN after sending a Reject PDU Thread-Index: AcTXTMVQTNcrLKV2QGmz/O5ECjdpfwAAGzsw From: "Buck Landry" To: "Gwendal Grignou" , X-OriginalArrivalTime: 01 Dec 2004 02:37:13.0433 (UTC) FILETIME=[AA17E490:01C4D74E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable The final RFC 3720 10.17.3 (as opposed to draft20) states pretty clearly "StatSN is advanced after a Reject." I believe the full text says, >>> 10.17.3. StatSN, ExpCmdSN and MaxCmdSN These fields carry their usual values and are not related to the rejected command. StatSN is advanced after a Reject. <<< Hope this helps, --buck -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org]On Behalf Of Gwendal Grignou Sent: Tuesday, November 30, 2004 7:55 PM To: ips@ietf.org Subject: [Ips] Update StatSN after sending a Reject PDU Hello, I am wondering if the target must increase the connection StatSN after sending a reject PDU. In the RFC, it is stated 10.17.3 StatSN, ExpCmdSN and MaxCmdSN=20 These fields carry their usual values and are not related to the rejected command It is not clear to me if StatSN must be incremented after sending the PDU or not. I would say no, but I would like a confirmation. Thank you, Gwendal. _______________________________________________ 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