From ips-bounces@ietf.org Sat Sep 01 01:48:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRLoG-0005jb-Uk; Sat, 01 Sep 2007 01:46:16 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IRLoF-0005jW-DY for ips-confirm+ok@megatron.ietf.org; Sat, 01 Sep 2007 01:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRLoF-0005jN-0e for ips@ietf.org; Sat, 01 Sep 2007 01:46:15 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRLoD-0003U7-AB for ips@ietf.org; Sat, 01 Sep 2007 01:46:14 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l815kBSD1224536 for ; Sat, 1 Sep 2007 05:46:11 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l815kBdY2244794 for ; Sat, 1 Sep 2007 07:46:11 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l815kBnK030996 for ; Sat, 1 Sep 2007 07:46:11 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l815kBZL030993; Sat, 1 Sep 2007 07:46:11 +0200 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection MIME-Version: 1.0 From: Julian Satran To: David Sheehy Message-ID: Date: Sat, 1 Sep 2007 08:46:10 +0300 X-Mailer: Lotus Domino Web Server Release 7.0.2HF71 November 3, 2006 X-MIMETrack: Serialize by Notes Server on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 01/09/2007 08:46:10, Serialize complete at 01/09/2007 08:46:10, Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 01/09/2007 08:46:10 MIME-Version: 1.0 X-Spam-Score: -1.3 (-) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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="===============2104124078==" Errors-To: ips-bounces@ietf.org --===============2104124078== Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David - I admit I did not use the right word - I should have said not = "visible" but "good" motivation. And the immediate vs. non-immediate shippi= ng can be solved within any of the layers above. I do not even recall a hea= ted debate about it.

Julo

= -----David Sheehy <David=5FSheehy@pmc-sierra.com> wrote: = -----

= To: Julian Satran/Haifa/IBM@IBMIL, Parav Pandit <paravpandit@yahoo.com>=
From: David Sheehy <David=5FSheehy@pmc-sierra.com><= br>Date: 08/31/2007 09:34PM
cc: ips@ietf.org
Subject: RE: [Ips] rationale= to send PDUs in increasing CmdSn on single co nnection

>=20 and=20 there was no visible motivation for out of order commands on a single=20 connection =20
 
On the contrary, there was = plenty of motivation. It was=20 overridden by the desire for simplified implementations over single TCP=20 connections as the Parav conjectured. There are DMA related efficiencies th= at=20 can be realized in situations with a mix of solicited and immediate/unsolic= ited=20 I/O traffic. The folks in favor of this optimization were outvoted by those= who=20 wanted to simplify their single connection based=20 implementations.
 
Dave

From: Julian Satran=20 [mailto:Julian=5FSatran@il.ibm.com]
Sent: Friday, August 31, 2007 8:54=20 AM
To: Parav Pandit
Cc: ips= @ietf.org
Subject: Re:=20 [Ips] rationale to send PDUs in increasing CmdSn on single=20 connection



Parav Pandit <paravpandit@yahoo.com>=20 wrote on 31/08/2007 12:52:04:

> Hi,
>  
> RFC 37= 20,=20 section 3.2.2.1 says
>
> "On any connection, the iSCSI initia= tor=20 MUST send the
> commands in increasing order of CmdSN, except for
= >=20 commands that are retransmitted due to digest error
> recovery and=20 connection recovery. "
>
> (Assuming Single TCP connection ISC= SI=20 session)
>
> 1. I interpret above 3.2.2.1 statement as
>= ;=20 SCSI layer gives SCSI commands to the ISCSI stack in
> the order of C= md-1=20 and Cmd-2.
> Cmd-1 will have CmdSn =3D 10.
> Cmd-2 will have C= mdSn =3D=20 11.
> ISCSI stack CAN send PDUs to the TCP layer in
> following= =20 order ONLY.
> PDU-1 with Cmd-1.
> PDU-2 with Cmd-2.
> >=20 Is this correct interpretation?
> Or
>
Yes
> 2. On a SINGLE connection can ISCSI stack send the
> = PDU-1 with Cmd-2 followed by
> PDU-2 with Cmd-1?
>=20
NO
> Assuming the answer of the question=20 #2 is No,
>
> 3. If there are multiple connections in a sessio= n=20 then
> command MAY any way reach out of order. And targets
> ne= ed to=20 wait for the previous expected commands.
>
> So targets will=20 receive out of order ISCSI PDUs from
> the TCP layer and ISCSI stack = handles them.
>
> So then why initiators have restriction of=20 sending
> command in the increasing order of CmdSn on SINGLE TCP
&= gt;=20 connection?
>=20
To simplify recovery and=20 to...
> Is it to simplify the implementation of targets
> suppo= rting=20 only single TCP connection?
>=20
>

and there was no visible=20 motivation for out of order commands on a single connection

> Regards,
> Parav Pandit
>
>
>
>=        
>=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
>=20 Looking for a deal? Find great prices on flights and hotels with
> Y= ahoo!=20 FareChase.
>=20 http://farechase.yahoo.com/
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
> Ips=20 mailing list
> Ips@ietf.org
>=20 https://www1.ietf.org/m= ailman/listinfo/ips

= --===============2104124078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2104124078==-- From ips-bounces@ietf.org Sat Sep 01 02:19:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRMJ9-0002iw-GK; Sat, 01 Sep 2007 02:18:11 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IRMJ7-0002bD-D3 for ips-confirm+ok@megatron.ietf.org; Sat, 01 Sep 2007 02:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRMJ7-0002b4-3I for ips@ietf.org; Sat, 01 Sep 2007 02:18:09 -0400 Received: from web30113.mail.mud.yahoo.com ([209.191.69.45]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IRMJ5-0003wt-EL for ips@ietf.org; Sat, 01 Sep 2007 02:18:08 -0400 Received: (qmail 43226 invoked by uid 60001); 1 Sep 2007 06:18:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=VwofywbL+OICQoSg7ybDnq1XmPGelOsW3p9/R+y5foOHFqlbgh0eVLYNWG4GtzrmNvb1u9/5wNdfn/BeUD+pr+daJ+zz867m63A6+bMF1EuDDX9B0pI+xIIkt6k6yBNOa98E9hm4V/nued24VZn/YZUOAxlzSYAhL0hZgvbg+t0=; X-YMail-OSG: EwPPkm8VM1m5uih9gnMSh0gj0NkIqQgpTz61OrlAfpUsITliXshnJxewVdM8NT85R.y.sIOIn21JENgcnZ3yZcZMAnvsNA9PfrnLV2Dh_xA0tRhkHESyb4QqyCctmA-- Received: from [59.96.38.13] by web30113.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2007 23:18:06 PDT Date: Fri, 31 Aug 2007 23:18:06 -0700 (PDT) From: Parav Pandit Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection To: David Sheehy , Julian Satran In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <939380.42557.qm@web30113.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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: , Errors-To: ips-bounces@ietf.org Exactly thats the reason which lead me to asko this question. DMA optimization is possible if we can send out of order commands to the TCP layer on single connection. If I take pragmatic approach, Any idea, currently how current single connection target implementation is? I mean, if current targets are smart enough (accept out of order PDUs on single connection- liberal on point 3.2.2.1), then initiators can use their DMA optimization. What do you say? Parav --- David Sheehy wrote: > > and there was no visible motivation for out of > order commands on a single connection > > On the contrary, there was plenty of motivation. It > was overridden by the desire for simplified > implementations over single TCP connections as the > Parav conjectured. There are DMA related > efficiencies that can be realized in situations with > a mix of solicited and immediate/unsolicited I/O > traffic. The folks in favor of this optimization > were outvoted by those who wanted to simplify their > single connection based implementations. > > Dave > > _____ > > From: Julian Satran > [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, August 31, 2007 8:54 AM > To: Parav Pandit > Cc: ips@ietf.org > Subject: Re: [Ips] rationale to send PDUs in > increasing CmdSn on single connection > > > > > Parav Pandit wrote on > 31/08/2007 12:52:04: > > > Hi, > > > > RFC 3720, section 3.2.2.1 says > > > > "On any connection, the iSCSI initiator MUST send > the > > commands in increasing order of CmdSN, except for > > commands that are retransmitted due to digest > error > > recovery and connection recovery. " > > > > (Assuming Single TCP connection ISCSI session) > > > > 1. I interpret above 3.2.2.1 statement as > > SCSI layer gives SCSI commands to the ISCSI stack > in > > the order of Cmd-1 and Cmd-2. > > Cmd-1 will have CmdSn = 10. > > Cmd-2 will have CmdSn = 11. > > ISCSI stack CAN send PDUs to the TCP layer in > > following order ONLY. > > PDU-1 with Cmd-1. > > PDU-2 with Cmd-2. > > > > Is this correct interpretation? > > Or > > > Yes > > 2. On a SINGLE connection can ISCSI stack send the > > > PDU-1 with Cmd-2 followed by > > PDU-2 with Cmd-1? > > > NO > > Assuming the answer of the question #2 is No, > > > > 3. If there are multiple connections in a session > then > > command MAY any way reach out of order. And > targets > > need to wait for the previous expected commands. > > > > So targets will receive out of order ISCSI PDUs > from > > the TCP layer and ISCSI stack handles them. > > > > So then why initiators have restriction of sending > > command in the increasing order of CmdSn on SINGLE > TCP > > connection? > > > To simplify recovery and to... > > Is it to simplify the implementation of targets > > supporting only single TCP connection? > > > > > > and there was no visible motivation for out of order > commands on a single connection > > > Regards, > > Parav Pandit > > > > > > > > > > > ____________________________________________________________________________________ > > Looking for a deal? Find great prices on flights > and hotels with > > Yahoo! FareChase. > > > http://farechase.yahoo.com/ > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ips > > ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Sep 01 11:51:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRVE0-0005mo-O6; Sat, 01 Sep 2007 11:49:28 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IRVE0-0005mW-06 for ips-confirm+ok@megatron.ietf.org; Sat, 01 Sep 2007 11:49:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRVDz-0005mJ-C5 for ips@ietf.org; Sat, 01 Sep 2007 11:49:27 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRVDy-0005rV-1F for ips@ietf.org; Sat, 01 Sep 2007 11:49:27 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l81FnOXH218902 for ; Sat, 1 Sep 2007 15:49:24 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l81FnOKE2347218 for ; Sat, 1 Sep 2007 17:49:24 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l81FnNFX013201 for ; Sat, 1 Sep 2007 17:49:24 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l81FnN6C013198; Sat, 1 Sep 2007 17:49:23 +0200 In-Reply-To: <939380.42557.qm@web30113.mail.mud.yahoo.com> References: <939380.42557.qm@web30113.mail.mud.yahoo.com> To: Parav Pandit MIME-Version: 1.0 Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Julian Satran Message-ID: Date: Sat, 1 Sep 2007 18:49:22 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 01/09/2007 18:49:23, Serialize complete at 01/09/2007 18:49:23 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: David Sheehy , 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="===============2066355609==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============2066355609== Content-Type: multipart/alternative; boundary="=_alternative 0056E6A0C2257349_=" This is a multipart message in MIME format. --=_alternative 0056E6A0C2257349_= Content-Type: text/plain; charset="US-ASCII" As assigning CMD sequence number is the prerogative of the initiator I do not understand the point of send out of order commands. If you want to optimize within an independent RDMA layer at the initiator the assign the numbers there. Initiators sending out-of-order packets will probably be flagged as bad by any of the certification packages. Julo Parav Pandit 01/09/07 09:18 To David Sheehy , Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org Subject RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection Exactly thats the reason which lead me to asko this question. DMA optimization is possible if we can send out of order commands to the TCP layer on single connection. If I take pragmatic approach, Any idea, currently how current single connection target implementation is? I mean, if current targets are smart enough (accept out of order PDUs on single connection- liberal on point 3.2.2.1), then initiators can use their DMA optimization. What do you say? Parav --- David Sheehy wrote: > > and there was no visible motivation for out of > order commands on a single connection > > On the contrary, there was plenty of motivation. It > was overridden by the desire for simplified > implementations over single TCP connections as the > Parav conjectured. There are DMA related > efficiencies that can be realized in situations with > a mix of solicited and immediate/unsolicited I/O > traffic. The folks in favor of this optimization > were outvoted by those who wanted to simplify their > single connection based implementations. > > Dave > > _____ > > From: Julian Satran > [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, August 31, 2007 8:54 AM > To: Parav Pandit > Cc: ips@ietf.org > Subject: Re: [Ips] rationale to send PDUs in > increasing CmdSn on single connection > > > > > Parav Pandit wrote on > 31/08/2007 12:52:04: > > > Hi, > > > > RFC 3720, section 3.2.2.1 says > > > > "On any connection, the iSCSI initiator MUST send > the > > commands in increasing order of CmdSN, except for > > commands that are retransmitted due to digest > error > > recovery and connection recovery. " > > > > (Assuming Single TCP connection ISCSI session) > > > > 1. I interpret above 3.2.2.1 statement as > > SCSI layer gives SCSI commands to the ISCSI stack > in > > the order of Cmd-1 and Cmd-2. > > Cmd-1 will have CmdSn = 10. > > Cmd-2 will have CmdSn = 11. > > ISCSI stack CAN send PDUs to the TCP layer in > > following order ONLY. > > PDU-1 with Cmd-1. > > PDU-2 with Cmd-2. > > > > Is this correct interpretation? > > Or > > > Yes > > 2. On a SINGLE connection can ISCSI stack send the > > > PDU-1 with Cmd-2 followed by > > PDU-2 with Cmd-1? > > > NO > > Assuming the answer of the question #2 is No, > > > > 3. If there are multiple connections in a session > then > > command MAY any way reach out of order. And > targets > > need to wait for the previous expected commands. > > > > So targets will receive out of order ISCSI PDUs > from > > the TCP layer and ISCSI stack handles them. > > > > So then why initiators have restriction of sending > > command in the increasing order of CmdSn on SINGLE > TCP > > connection? > > > To simplify recovery and to... > > Is it to simplify the implementation of targets > > supporting only single TCP connection? > > > > > > and there was no visible motivation for out of order > commands on a single connection > > > Regards, > > Parav Pandit > > > > > > > > > > > ____________________________________________________________________________________ > > Looking for a deal? Find great prices on flights > and hotels with > > Yahoo! FareChase. > > > http://farechase.yahoo.com/ > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ips > > ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0056E6A0C2257349_= Content-Type: text/html; charset="US-ASCII"
As assigning CMD sequence number is the prerogative of the initiator I do not  understand the point of send out of order commands. If you want to optimize within an independent RDMA layer at the initiator the assign the numbers there.  Initiators sending out-of-order packets will probably be flagged as bad by any of the certification packages.

Julo


Parav Pandit <paravpandit@yahoo.com>

01/09/07 09:18

To
David Sheehy <David_Sheehy@pmc-sierra.com>, Julian Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org
Subject
RE: [Ips] rationale to send PDUs in increasing CmdSn on single co        nnection





Exactly thats the reason which lead me to asko this
question.

DMA optimization is possible if we can send out of
order commands to the TCP layer on single connection.

If I take pragmatic approach,
Any idea, currently how current single connection
target implementation is?

I mean, if current targets are smart enough (accept
out of order PDUs on single connection- liberal on
point 3.2.2.1), then initiators can use their DMA
optimization.
What do you say?

Parav


--- David Sheehy <David_Sheehy@pmc-sierra.com> wrote:

> > and there was no visible motivation for out of
> order commands on a single connection
>  
> On the contrary, there was plenty of motivation. It
> was overridden by the desire for simplified
> implementations over single TCP connections as the
> Parav conjectured. There are DMA related
> efficiencies that can be realized in situations with
> a mix of solicited and immediate/unsolicited I/O
> traffic. The folks in favor of this optimization
> were outvoted by those who wanted to simplify their
> single connection based implementations.
>  
> Dave
>
>   _____  
>
> From: Julian Satran
> [mailto:Julian_Satran@il.ibm.com]
> Sent: Friday, August 31, 2007 8:54 AM
> To: Parav Pandit
> Cc: ips@ietf.org
> Subject: Re: [Ips] rationale to send PDUs in
> increasing CmdSn on single connection
>
>
>
>
> Parav Pandit <paravpandit@yahoo.com> wrote on
> 31/08/2007 12:52:04:
>
> > Hi,
> >  
> > RFC 3720, section 3.2.2.1 says
> >
> > "On any connection, the iSCSI initiator MUST send
> the
> > commands in increasing order of CmdSN, except for
> > commands that are retransmitted due to digest
> error
> > recovery and connection recovery. "
> >
> > (Assuming Single TCP connection ISCSI session)
> >
> > 1. I interpret above 3.2.2.1 statement as
> > SCSI layer gives SCSI commands to the ISCSI stack
> in
> > the order of Cmd-1 and Cmd-2.
> > Cmd-1 will have CmdSn = 10.
> > Cmd-2 will have CmdSn = 11.
> > ISCSI stack CAN send PDUs to the TCP layer in
> > following order ONLY.
> > PDU-1 with Cmd-1.
> > PDU-2 with Cmd-2.
> >
> > Is this correct interpretation?
> > Or
> >
> Yes
> > 2. On a SINGLE connection can ISCSI stack send the
>
> > PDU-1 with Cmd-2 followed by
> > PDU-2 with Cmd-1?
> >
> NO
> > Assuming the answer of the question #2 is No,
> >
> > 3. If there are multiple connections in a session
> then
> > command MAY any way reach out of order. And
> targets
> > need to wait for the previous expected commands.
> >
> > So targets will receive out of order ISCSI PDUs
> from
> > the TCP layer and ISCSI stack handles them.
> >
> > So then why initiators have restriction of sending
> > command in the increasing order of CmdSn on SINGLE
> TCP
> > connection?
> >
> To simplify recovery and to...
> > Is it to simplify the implementation of targets
> > supporting only single TCP connection?
> >
> >
>
> and there was no visible motivation for out of order
> commands on a single connection
>
> > Regards,
> > Parav Pandit
> >
> >
> >
> >        
> >
>
____________________________________________________________________________________
> > Looking for a deal? Find great prices on flights
> and hotels with
> > Yahoo! FareChase.
> >  <http://farechase.yahoo.com/>
> http://farechase.yahoo.com/
> >
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> >  <https://www1.ietf.org/mailman/listinfo/ips>
> https://www1.ietf.org/mailman/listinfo/ips
>
>



     ____________________________________________________________________________________
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0056E6A0C2257349_=-- --===============2066355609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2066355609==-- From ips-bounces@ietf.org Tue Sep 04 09:32:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYUe-0005hG-0B; Tue, 04 Sep 2007 09:31:00 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1ISYUc-0005g0-Rl for ips-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 09:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYUc-0005fZ-IC for ips@ietf.org; Tue, 04 Sep 2007 09:30:58 -0400 Received: from exprod8og53.obsmtp.com ([64.18.3.88]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISYUb-0001KF-5h for ips@ietf.org; Tue, 04 Sep 2007 09:30:58 -0400 Received: from source ([12.110.134.31]) by exprod8ob53.obsmtp.com ([64.18.7.12]) with SMTP; Tue, 04 Sep 2007 06:29:37 PDT Received: from pkoning-laptop.equallogic.com.equallogic.com ([172.25.202.120]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 09:27:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18141.23886.879488.863402@pkoning-laptop.equallogic.com> Date: Tue, 4 Sep 2007 09:27:42 -0400 From: Paul Koning To: paravpandit@yahoo.com Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection References: <939380.42557.qm@web30113.mail.mud.yahoo.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 04 Sep 2007 13:27:45.0181 (UTC) FILETIME=[60CE3CD0:01C7EEF7] X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: David_Sheehy@pmc-sierra.com, ips@ietf.org, Julian_Satran@il.ibm.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org >>>>> "Parav" == Parav Pandit writes: Parav> If I take pragmatic approach, Any idea, currently how current Parav> single connection target implementation is? I suspect most of them are single connection. Parav> I mean, if current targets are smart enough (accept out of Parav> order PDUs on single connection- liberal on point 3.2.2.1), Parav> then initiators can use their DMA optimization. What do you Parav> say? Don't. You'd be creating an initiator that violates the protocol spec. You'd have no reason to expect that to work at all. Many targets will check this and call it a protocol violation (you may end up with the connection terminated). Some may not notice but may end up doing the wrong thing. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 04 14:43:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdLk-00055I-K4; Tue, 04 Sep 2007 14:42:08 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1ISdLj-00055C-Ug for ips-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 14:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdLj-000554-L5 for ips@ietf.org; Tue, 04 Sep 2007 14:42:07 -0400 Received: from web51712.mail.re2.yahoo.com ([206.190.39.77]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISdLi-0000Aq-91 for ips@ietf.org; Tue, 04 Sep 2007 14:42:07 -0400 Received: (qmail 90275 invoked by uid 60001); 4 Sep 2007 18:42:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=koyQ6MzSULz4CY9Mh4sqIerbi8bLP9LCA7yhG469b8T5vBKH8MG5NllWRySEwzZEvfzokRlmhZ6Vf3bn1MzF7YptdZ+aZ8Sxa6Uie9P6AIDexy24YPsOAQYOATgUu2XxGLNDSyLINyhODpcejC6VdPi19y+1u/N05KxY/d2gMZ4=; X-YMail-OSG: ihGLf1sVM1n2.gcfvKx6ToAsmGm_Zw2B6xg4fiSjmz2YpHEG66DhV3in6PlndtvTnAVhR2xv.9ZbKyz.LZgYLkHW3BjnNGLOVGALxoguqhcryslThw-- Received: from [15.227.217.76] by web51712.mail.re2.yahoo.com via HTTP; Tue, 04 Sep 2007 11:42:06 PDT Date: Tue, 4 Sep 2007 11:42:06 -0700 (PDT) From: "Mallikarjun C." Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection To: ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <107228.90093.qm@web51712.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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: , Errors-To: ips-bounces@ietf.org Agree with Julian on this. RFC 3720 simply requires that once the CmdSN is assigned to a command, it has to go out in that order on to the wire. Note that RFC 3720 does not mandate where/when CmdSN assignment must be done, other than of course that it is done before the command goes out. I don't see the specific DMA optimizations that the RFC precludes. Mallikarjun --- Julian Satran wrote: > As assigning CMD sequence number is the prerogative > of the initiator I do > not understand the point of send out of order > commands. If you want to > optimize within an independent RDMA layer at the > initiator the assign the > numbers there. Initiators sending out-of-order > packets will probably be > flagged as bad by any of the certification packages. > > Julo > > > > Parav Pandit > 01/09/07 09:18 > > To > David Sheehy , Julian > Satran/Haifa/IBM@IBMIL > cc > ips@ietf.org > Subject > RE: [Ips] rationale to send PDUs in increasing CmdSn > on single co nnection > > > > > > > Exactly thats the reason which lead me to asko this > question. > > DMA optimization is possible if we can send out of > order commands to the TCP layer on single > connection. > > If I take pragmatic approach, > Any idea, currently how current single connection > target implementation is? > > I mean, if current targets are smart enough (accept > out of order PDUs on single connection- liberal on > point 3.2.2.1), then initiators can use their DMA > optimization. > What do you say? > > Parav > > > --- David Sheehy > wrote: > > > > and there was no visible motivation for out of > > order commands on a single connection > > > > On the contrary, there was plenty of motivation. > It > > was overridden by the desire for simplified > > implementations over single TCP connections as the > > Parav conjectured. There are DMA related > > efficiencies that can be realized in situations > with > > a mix of solicited and immediate/unsolicited I/O > > traffic. The folks in favor of this optimization > > were outvoted by those who wanted to simplify > their > > single connection based implementations. > > > > Dave > > > > _____ > > > > From: Julian Satran > > [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, August 31, 2007 8:54 AM > > To: Parav Pandit > > Cc: ips@ietf.org > > Subject: Re: [Ips] rationale to send PDUs in > > increasing CmdSn on single connection > > > > > > > > > > Parav Pandit wrote on > > 31/08/2007 12:52:04: > > > > > Hi, > > > > > > RFC 3720, section 3.2.2.1 says > > > > > > "On any connection, the iSCSI initiator MUST > send > > the > > > commands in increasing order of CmdSN, except > for > > > commands that are retransmitted due to digest > > error > > > recovery and connection recovery. " > > > > > > (Assuming Single TCP connection ISCSI session) > > > > > > 1. I interpret above 3.2.2.1 statement as > > > SCSI layer gives SCSI commands to the ISCSI > stack > > in > > > the order of Cmd-1 and Cmd-2. > > > Cmd-1 will have CmdSn = 10. > > > Cmd-2 will have CmdSn = 11. > > > ISCSI stack CAN send PDUs to the TCP layer in > > > following order ONLY. > > > PDU-1 with Cmd-1. > > > PDU-2 with Cmd-2. > > > > > > Is this correct interpretation? > > > Or > > > > > Yes > > > 2. On a SINGLE connection can ISCSI stack send > the > > > > > PDU-1 with Cmd-2 followed by > > > PDU-2 with Cmd-1? > > > > > NO > > > Assuming the answer of the question #2 is No, > > > > > > 3. If there are multiple connections in a > session > > then > > > command MAY any way reach out of order. And > > targets > > > need to wait for the previous expected commands. > > > > > > So targets will receive out of order ISCSI PDUs > > from > > > the TCP layer and ISCSI stack handles them. > > > > > > So then why initiators have restriction of > sending > > > command in the increasing order of CmdSn on > SINGLE > > TCP > > > connection? > > > > > To simplify recovery and to... > > > Is it to simplify the implementation of targets > > > supporting only single TCP connection? > > > > > > > > > > and there was no visible motivation for out of > order > > commands on a single connection > > > > > Regards, > > > Parav Pandit > > > > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > > Looking for a deal? Find great prices on flights > > and hotels with > > > Yahoo! FareChase. > > > > > http://farechase.yahoo.com/ > > > > > > > > > _______________________________________________ > > > Ips mailing list > > > Ips@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ips > > > > > > > > > ____________________________________________________________________________________ > Luggage? GPS? Comic books? > Check out fitting gifts for grads at Yahoo! Search > http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz > > > _______________________________________________ > 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 > ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 05 09:02:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuUr-00053P-At; Wed, 05 Sep 2007 09:00:41 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1ISuUo-00053I-Qj for ips-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 09:00:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuUo-000534-6O for ips@ietf.org; Wed, 05 Sep 2007 09:00:38 -0400 Received: from web30112.mail.mud.yahoo.com ([209.191.69.44]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISuUn-0004u4-Oj for ips@ietf.org; Wed, 05 Sep 2007 09:00:38 -0400 Received: (qmail 14032 invoked by uid 60001); 5 Sep 2007 13:00:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=BoYm6/rlrSudYHHHu8OQcwFBhDQK97smbDJbysgUeS2Vncq082gwAdqDKxqH++OVZGmxzyDLViuO9fv5XXJFYA/rIlDIoSJqcQ46uMqiLVE94rV06XIdSAL3zWVskJbX2V1Jo/kkklTWg1AX9No0c42ZKmbF2mbjPK8ycUXh8aY=; X-YMail-OSG: jU___n0VM1l0xOjXxb.VPa3CkoUhV7tCriCr8moEL7AUWU1ImThQrYlf_ZJWcLaaNLmjEcCMSFyBY9Hos8svSpHsd4RLcRTuBRp0 Received: from [61.12.16.156] by web30112.mail.mud.yahoo.com via HTTP; Wed, 05 Sep 2007 06:00:37 PDT Date: Wed, 5 Sep 2007 06:00:37 -0700 (PDT) From: Parav Pandit Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection To: Paul Koning In-Reply-To: <18141.23886.879488.863402@pkoning-laptop.equallogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <99152.12495.qm@web30112.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: David_Sheehy@pmc-sierra.com, ips@ietf.org, Julian_Satran@il.ibm.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --- Paul Koning wrote: > >>>>> "Parav" == Parav Pandit > writes: > > Parav> If I take pragmatic approach, Any idea, > currently how current > Parav> single connection target implementation is? > > I suspect most of them are single connection. > > Parav> I mean, if current targets are smart enough > (accept out of > Parav> order PDUs on single connection- liberal on > point 3.2.2.1), > Parav> then initiators can use their DMA > optimization. What do you > Parav> say? > > Don't. > > You'd be creating an initiator that violates the > protocol spec. You'd > have no reason to expect that to work at all. Many > targets will check > this and call it a protocol violation (you may end > up with the > connection terminated). Some may not notice but may > end up doing the > wrong thing. > > paul [Parav] Thanks Paul. I certainly don't want to violate the protocol. I was wondering how current qualified, proven iscsi targets are behaving for this scenario. And you confirmed the same, so will surely adhere to the protocol. Thanks, Parav ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 11 18:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDxP-0003e5-Kc; Tue, 11 Sep 2007 18:11:43 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IVDxO-0003W1-8d for ips-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 18:11:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDxN-0003Sc-De; Tue, 11 Sep 2007 18:11:41 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVDxN-0002jU-27; Tue, 11 Sep 2007 18:11:41 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l8BMBeDZ029220; Tue, 11 Sep 2007 18:11:40 -0400 (EDT) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l8BMArRF013112; Tue, 11 Sep 2007 18:11:38 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 18:11:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Sep 2007 18:11:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: No IPS or RDDP meeting in Vancouver thread-index: Acf0wK7brxm8qonqTbiZ5rwyujvjDQ== To: , X-OriginalArrivalTime: 11 Sep 2007 22:11:22.0174 (UTC) FILETIME=[AFAF2DE0:01C7F4C0] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ips] No IPS or RDDP meeting in Vancouver 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: , Errors-To: ips-bounces@ietf.org The ips and rddp WGs will not meet in Vancouver in December, as there are no active drafts in either WG - all of our drafts are in the RFC Editor Queue. For those wondering when the RDDP and iSER drafts will emerge from the RFC Editor's queue, the answer should be "soon." The SCTP ADDIP draft that was blocking these drafts (due to a normative reference) has been sent to the RFC Editor, and I've seen recent email indicating that the RFC Editor is actively editing the RDDP drafts. Thanks, --David (ips WG chair and rddp WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 17 17:46:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXONK-0005qs-Mt; Mon, 17 Sep 2007 17:43:26 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IXONK-0005qU-0I for ips-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 17:43:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXONJ-0005ni-Lc for ips@ietf.org; Mon, 17 Sep 2007 17:43:25 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXON7-0002ER-Cj for ips@ietf.org; Mon, 17 Sep 2007 17:43:19 -0400 Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 17 Sep 2007 14:42:47 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 28E042AE; Mon, 17 Sep 2007 14:42:48 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 036CB2AE; Mon, 17 Sep 2007 14:42:48 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FRM67499; Mon, 17 Sep 2007 14:41:40 -0700 (PDT) Received: from NT-SJCA-0752.brcm.ad.broadcom.com (nt-sjca-0752 [10.16.192.222]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id D2F5820502; Mon, 17 Sep 2007 14:41:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection Date: Mon, 17 Sep 2007 14:41:29 -0700 Message-ID: <87AC500EEF9B9344B4A8D8A017C2F455013E384D@NT-SJCA-0752.brcm.ad.broadcom.com> In-Reply-To: <99152.12495.qm@web30112.mail.mud.yahoo.com> Thread-Topic: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection Thread-Index: AcfvvQTQF8dRxrxFSEOGRf3IqSgUBQJs8QEw References: <18141.23886.879488.863402@pkoning-laptop.equallogic.com> <99152.12495.qm@web30112.mail.mud.yahoo.com> From: "Pat Thaler" To: "Parav Pandit" , "Paul Koning" X-WSS-ID: 6AF02B5D44G2255289-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: David_Sheehy@pmc-sierra.com, ips@ietf.org, Julian_Satran@il.ibm.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The focus of comments seems to have been around single connection with the implication that multi-connection already has to handle out of order and the restriction is doing nothing for multi-connections sessions. This is incorrect. Even when there are multiple connections, the requirement to have increasing order on a connection restricts the behavior the receiver will see. For example, when there are two connections and packets 1 through 4 have been sent, the receiver might see: Connection: A B 1 =20 3 4 2 But would not see: A B 1 =20 3 =20 2 4 For a session with N connections, the receiver only has to look N places (the front of what was received from each connection) for the next CmdSN. If one removes the in-order per connection rule, the receiver would have to look for the next CmdSN in the whole set of received commands. It would be incorrect to assume that any multi-connection iSCSI implementation would work with the restriction removed. Some may have been implemented for the subset of out of order behavior that occurs within the current rules. They may handle deviations from that behavior for recovery but with less efficiency so that it is undesireable to purposely cause that condition. Pat -----Original Message----- From: Parav Pandit [mailto:paravpandit@yahoo.com]=20 Sent: Wednesday, September 05, 2007 6:01 AM To: Paul Koning Cc: David_Sheehy@pmc-sierra.com; ips@ietf.org; Julian_Satran@il.ibm.com Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection --- Paul Koning wrote: > >>>>> "Parav" =3D=3D Parav Pandit > writes: >=20 > Parav> If I take pragmatic approach, Any idea, > currently how current > Parav> single connection target implementation is? >=20 > I suspect most of them are single connection. >=20 > Parav> I mean, if current targets are smart enough > (accept out of > Parav> order PDUs on single connection- liberal on > point 3.2.2.1), > Parav> then initiators can use their DMA > optimization. What do you > Parav> say? >=20 > Don't. >=20 > You'd be creating an initiator that violates the > protocol spec. You'd > have no reason to expect that to work at all. Many > targets will check > this and call it a protocol violation (you may end > up with the > connection terminated). Some may not notice but may > end up doing the > wrong thing. >=20 > paul [Parav] Thanks Paul. I certainly don't want to violate the protocol. I was wondering how current qualified, proven iscsi targets are behaving for this scenario. And you confirmed the same, so will surely adhere to the protocol. Thanks, Parav =20 ________________________________________________________________________ ____________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.=20 http://mobile.yahoo.com/go?refer=3D1GNXIC _______________________________________________ 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 Sep 19 07:53:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXy4I-0007PB-HC; Wed, 19 Sep 2007 07:50:10 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IXy4H-0007On-OG for ips-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 07:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXy4H-0007K1-BI for ips@ietf.org; Wed, 19 Sep 2007 07:50:09 -0400 Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXy46-0007gy-Q9 for ips@ietf.org; Wed, 19 Sep 2007 07:50:05 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 19 Sep 2007 04:49:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.20,273,1186383600"; d="scan'208";a="298444522" Received: from orsmsx335.jf.intel.com ([10.22.226.40]) by orsmga001.jf.intel.com with ESMTP; 19 Sep 2007 04:49:43 -0700 Received: from orsmsx414.amr.corp.intel.com ([10.22.226.41]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 04:49:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Sep 2007 04:49:39 -0700 Message-ID: In-Reply-To: <87AC500EEF9B9344B4A8D8A017C2F455013E384D@NT-SJCA-0752.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple connection - login Thread-Index: AcfvvQTQF8dRxrxFSEOGRf3IqSgUBQJs8QEwAE9yiSA= References: <18141.23886.879488.863402@pkoning-laptop.equallogic.com><99152.12495.qm@web30112.mail.mud.yahoo.com> <87AC500EEF9B9344B4A8D8A017C2F455013E384D@NT-SJCA-0752.brcm.ad.broadcom.com> From: "Deuskar, Prafulla" To: X-OriginalArrivalTime: 19 Sep 2007 11:49:42.0419 (UTC) FILETIME=[2A9A3E30:01C7FAB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ips] Multiple connection - login 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: , Errors-To: ips-bounces@ietf.org All, Section 3.2.3 of RFC says that: "The purpose of the iSCSI login is to enable a TCP connection for iSCSI use, authentication of the parties, negotiation of the session's parameters and marking of the connection as belonging to an iSCSI session." When we do a login for non-leading connection do we renegotiate session parameters? Thanks, Prafulla _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 19 12:21:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2H3-0001zJ-Gm; Wed, 19 Sep 2007 12:19:37 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IY2H1-0001z3-KC for ips-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 12:19:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2H1-0001yF-4D for ips@ietf.org; Wed, 19 Sep 2007 12:19:35 -0400 Received: from mtagate8.de.ibm.com ([195.212.29.157]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY2H0-0004sZ-Ef for ips@ietf.org; Wed, 19 Sep 2007 12:19:35 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id l8JGJWsw451060 for ; Wed, 19 Sep 2007 16:19:32 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l8JGJXmN2048196 for ; Wed, 19 Sep 2007 18:19:33 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l8JGJXC2022716 for ; Wed, 19 Sep 2007 18:19:33 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l8JGJX76022710 for ; Wed, 19 Sep 2007 18:19:33 +0200 In-Reply-To: References: <18141.23886.879488.863402@pkoning-laptop.equallogic.com><99152.12495.qm@web30112.mail.mud.yahoo.com> <87AC500EEF9B9344B4A8D8A017C2F455013E384D@NT-SJCA-0752.brcm.ad.broadcom.com> To: "Deuskar, Prafulla" MIME-Version: 1.0 Subject: Re: [Ips] Multiple connection - login X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Julian Satran Message-ID: Date: Wed, 19 Sep 2007 18:19:30 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 19/09/2007 18:19:32, Serialize complete at 19/09/2007 18:19:32 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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="===============0290816272==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0290816272== Content-Type: multipart/alternative; boundary="=_alternative 0059AB12C225735B_=" This is a multipart message in MIME format. --=_alternative 0059AB12C225735B_= Content-Type: text/plain; charset="US-ASCII" Any of login's can renegotiate any parameter that is not called-out specifically as being "leading-only". For the "standard keys" as defined in 3270 that is an empty set (all the session-wide keys are LO) but newly defined keys and vendor specific parameters might be renegotiable with every new connection or even during the life of a connection. Julo From: "Deuskar, Prafulla" To: Date: 19/09/07 14:12 Subject: [Ips] Multiple connection - login All, Section 3.2.3 of RFC says that: "The purpose of the iSCSI login is to enable a TCP connection for iSCSI use, authentication of the parties, negotiation of the session's parameters and marking of the connection as belonging to an iSCSI session." When we do a login for non-leading connection do we renegotiate session parameters? Thanks, Prafulla _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0059AB12C225735B_= Content-Type: text/html; charset="US-ASCII"
Any of login's can renegotiate any parameter that is not called-out specifically as being "leading-only".
For the "standard keys" as defined in 3270  that is an empty set (all the session-wide keys are LO) but newly defined keys and vendor specific  parameters might be renegotiable with every new connection or even during the life of a connection.

Julo


From: "Deuskar, Prafulla" <prafulla.deuskar@intel.com>
To: <ips@ietf.org>
Date: 19/09/07 14:12
Subject: [Ips] Multiple connection - login




All,

Section 3.2.3 of RFC says that:

"The purpose of the iSCSI login is to enable a TCP connection for
iSCSI use, authentication of the parties, negotiation of the
session's parameters and marking of the connection as belonging to an
iSCSI session."

When we do a login for non-leading connection do we renegotiate session
parameters?

Thanks,
Prafulla


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0059AB12C225735B_=-- --===============0290816272== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0290816272==-- From ips-bounces@ietf.org Wed Sep 19 12:42:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2dE-0002n3-Qn; Wed, 19 Sep 2007 12:42:32 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IY2dD-0002la-LK for ips-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 12:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2dD-0002lS-8h for ips@ietf.org; Wed, 19 Sep 2007 12:42:31 -0400 Received: from smtpoutm.mac.com ([17.148.16.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY2d7-0006vn-02 for ips@ietf.org; Wed, 19 Sep 2007 12:42:31 -0400 Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpoutm.mac.com (Xserve/smtpout010/MantshX 4.0) with ESMTP id l8JGg9pT010629; Wed, 19 Sep 2007 09:42:09 -0700 (PDT) Received: from [17.151.81.25] ([17.151.81.25]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id l8JGg7eB010123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Sep 2007 09:42:08 -0700 (PDT) Message-Id: <6FE00560-130A-48AF-9F22-13FC001AA942@mac.com> From: William Studenmund To: "Deuskar, Prafulla" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v905) Subject: Re: [Ips] Multiple connection - login Date: Wed, 19 Sep 2007 09:42:22 -0700 References: <18141.23886.879488.863402@pkoning-laptop.equallogic.com> <99152.12495.qm@web30112.mail.mud.yahoo.com> <87AC500EEF9B9344B4A8D8A017C2F455013E384D@NT-SJCA-0752.brcm.ad.broadcom.com> X-Mailer: Apple Mail (2.905) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Ips X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Sep 19, 2007, at 4:49 AM, Deuskar, Prafulla wrote: > All, > > Section 3.2.3 of RFC says that: > > "The purpose of the iSCSI login is to enable a TCP connection for > iSCSI use, authentication of the parties, negotiation of the > session's parameters and marking of the connection as belonging to an > iSCSI session." > > When we do a login for non-leading connection do we renegotiate > session > parameters? No. That's why some keys are marked "Leading-Only". Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 21 14:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYnQX-0004Wt-4E; Fri, 21 Sep 2007 14:40:33 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IYnQV-0004VW-7w for ips-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 14:40:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYnQU-0004VO-Ub for ips@ietf.org; Fri, 21 Sep 2007 14:40:30 -0400 Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYnQO-0002Ov-Lu for ips@ietf.org; Fri, 21 Sep 2007 14:40:30 -0400 Received: from mercury.inside.istor.com ([192.168.50.30]) by stork.inside.istor.com with ESMTP; 21 Sep 2007 11:40:16 -0700 X-IronPort-AV: i="4.20,284,1186383600"; d="scan'208"; a="4062166:sNHT19266510" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Sep 2007 11:40:15 -0700 Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D591@MERCURY.inside.istor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NOP-IN question Thread-Index: Acf8ftmwaqfsmzU5RQurQLZhp63Tsw== From: "Ken Craig" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ips] NOP-IN question 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: , Errors-To: ips-bounces@ietf.org During my Target development I convinced myself that somewhere in the RFC I read that only one Target originated NOP IN was allowed on the wire at a time per Connection. However I can no longer find anything like that in the latest RFC or addendums. I would like to know if I was dreaming or can someone point me to a place somewhere where the statement is made. Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 26 13:29:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaafn-0000Kk-5V; Wed, 26 Sep 2007 13:27:43 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Iaafm-0000Kf-Re for ips-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 13:27:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaafm-0000KJ-Gj for ips@ietf.org; Wed, 26 Sep 2007 13:27:42 -0400 Received: from fmailhost02.isp.att.net ([207.115.11.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaafm-0006ep-2Q for ips@ietf.org; Wed, 26 Sep 2007 13:27:42 -0400 Received: from ivvtdkv0981 (adsl-074-245-052-054.sip.jax.bellsouth.net[74.245.52.54]) by bellsouth.net (frfwmhc02) with SMTP id <20070926172739H0200k0pi9e>; Wed, 26 Sep 2007 17:27:41 +0000 X-Originating-IP: [74.245.52.54] Message-ID: <002b01c80062$8b6de810$0602a8c0@ivivity.com> From: "Eddy Quicksall" To: "Parav Pandit" , "Paul Koning" References: <99152.12495.qm@web30112.mail.mud.yahoo.com> Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn on single connection Date: Wed, 26 Sep 2007 13:27:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: David_Sheehy@pmc-sierra.com, ips@ietf.org, Julian_Satran@il.ibm.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org With my target, if I receive CmdSN's out of order I will re-order them before they proceed to the SCSI layer. Since this is necessary for multi-connections then it just falls out for single connections. Also, don't forget that if the Queue Algorithm Modifier is 1 (which it usually is) then simple commands can execute in any order regardless of the CmdSN (i.e. once it reaches the SCSI layer). So just give the increasing CmdSN and the target will, on a single connection, immediately forward the command to the SCSI layer and then the optimizations you are thinking of will most likely take place. Eddy ----- Original Message ----- From: "Parav Pandit" To: "Paul Koning" Cc: ; ; Sent: Wednesday, September 05, 2007 9:00 AM Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single connection > > --- Paul Koning wrote: > >> >>>>> "Parav" == Parav Pandit >> writes: >> >> Parav> If I take pragmatic approach, Any idea, >> currently how current >> Parav> single connection target implementation is? >> >> I suspect most of them are single connection. >> > >> Parav> I mean, if current targets are smart enough >> (accept out of >> Parav> order PDUs on single connection- liberal on >> point 3.2.2.1), >> Parav> then initiators can use their DMA >> optimization. What do you >> Parav> say? >> >> Don't. >> >> You'd be creating an initiator that violates the >> protocol spec. You'd >> have no reason to expect that to work at all. Many >> targets will check >> this and call it a protocol violation (you may end >> up with the >> connection terminated). Some may not notice but may >> end up doing the >> wrong thing. >> >> paul > > [Parav] Thanks Paul. I certainly don't want to violate > the protocol. I was wondering how current qualified, > proven iscsi targets are behaving for this scenario. > And you confirmed the same, so will surely adhere to > the protocol. > > Thanks, > Parav > > > > > ____________________________________________________________________________________ > Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, > news, photos & more. > http://mobile.yahoo.com/go?refer=1GNXIC > > > _______________________________________________ > 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 Sep 26 20:20:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iah60-0000U9-Aa; Wed, 26 Sep 2007 20:19:12 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Iah5z-0000Tr-Lv for ips-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 20:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iah5z-0000Qs-CB for ips@ietf.org; Wed, 26 Sep 2007 20:19:11 -0400 Received: from mail-gw3.adaptec.com ([162.62.93.58]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iah5n-0004ss-5p for ips@ietf.org; Wed, 26 Sep 2007 20:19:05 -0400 Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id 574F0232A77; Wed, 26 Sep 2007 17:18:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] NOP-IN question Date: Wed, 26 Sep 2007 17:18:15 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309902C5D084@aime2k302.adaptec.com> In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D591@MERCURY.inside.istor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] NOP-IN question Thread-Index: Acf8ftmwaqfsmzU5RQurQLZhp63TswEHBDiA References: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D591@MERCURY.inside.istor.com> From: "Sandars, Ken" To: "Ken Craig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi Ken, I can't recall that limit being suggested, nor can I find anything in the docs. Given the number of reasons a Nop-In may be generated it seems like an unusual hurdle to have introduced (ping response, target-initiated ping, target soliciting ExpStatSN, target advertising new CmdSN counter values). Cheers, Ken Sandars -----Original Message----- From: Ken Craig [mailto:kcraig@istor.com]=20 Sent: Saturday, 22 September 2007 04:40 To: ips@ietf.org Subject: [Ips] NOP-IN question During my Target development I convinced myself that somewhere in the RFC I read that only one Target originated NOP IN was allowed on the wire at a time per Connection. However I can no longer find anything like that in the latest RFC or addendums. I would like to know if I was dreaming or can someone point me to a place somewhere where the statement is made. Thanks, Ken Craig _______________________________________________ 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 Sep 27 00:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iakr1-00079y-Fe; Thu, 27 Sep 2007 00:19:59 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Iakr0-0006xZ-02 for ips-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 00:19:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iakqz-0006jL-E4 for ips@ietf.org; Thu, 27 Sep 2007 00:19:57 -0400 Received: from mail1.pillardata.com ([63.251.178.136]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iakqx-0001GK-5j for ips@ietf.org; Thu, 27 Sep 2007 00:19:55 -0400 Received: from coex02.trans.corp ([172.18.24.19]) by mail1.pillardata.com with ESMTP; 26 Sep 2007 22:19:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Sep 2007 22:20:35 -0600 Message-ID: <16236EEEF4D4264DA31C2E35E3607CFE0A3959FF@coex02.trans.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: updating iSNS registration for portal IP address change thread-index: AcgAvcBAThd202XjSketUbfIP0UXAQ== From: "Paul Hughes" To: "IP Storage Mailing List (E-mail)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [Ips] updating iSNS registration for portal IP address change 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="===============0867960469==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0867960469== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C800BD.C31E11B1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C800BD.C31E11B1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am trying to determine the proper way to update an iSNS server when the IP address of an iSCSI target port changes. In my case, I have a multi-ported iSCSI target that registers a single Storage Node object and multiple Portal and Portal Group objects. One method is to re-register the entire Network Entity using DevAttrReg with the replace flag set. This method seems rather disruptive as SCNs will be generated for the de-registered objects and additional SCNs are generated for registration of the new objects. I assume this means that iSCSI initiators in the target's Discovery Domain might logout all sessions with the target's portals only to re-login a short time later. Is this true? I'd like to avoid causing logouts on any portals that retain their original IP address. Alternately, I can de-register the Portal object for the old IP address of the target port using DevDereg and then register a new Portal object for the new IP address using DevAttrReg. However, I don't believe it's possible to de-register the old Portal Group objects without de-registering the Storage Node object. In my case, I believe that de-registering the Storage Node object would be as disruptive as doing a replacement registration of the entity, since the target has only one Storage Node object associated with all of its portal groups. Thanks for any help on this. Paul ------_=_NextPart_001_01C800BD.C31E11B1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable updating iSNS registration for portal IP address change

I am trying to determine the proper way = to update an iSNS server when the IP address of an iSCSI target port = changes.  In my case, I have a multi-ported iSCSI target that = registers a single Storage Node object and multiple Portal and Portal = Group objects.

One method is to re-register the entire = Network Entity using DevAttrReg with the replace flag set.  This = method seems rather disruptive as SCNs will be generated for the = de-registered objects and additional SCNs are generated for registration = of the new objects.  I assume this means that iSCSI initiators in = the target's Discovery Domain might logout all sessions with the = target's portals only to re-login a short time later.  Is this = true?  I'd like to avoid causing logouts on any portals that retain = their original IP address.

Alternately, I can de-register the = Portal object for the old IP address of the target port using DevDereg = and then register a new Portal object for the new IP address using = DevAttrReg.  However, I don’t believe it's possible to = de-register the old Portal Group objects without de-registering the = Storage Node object.  In my case, I believe that de-registering the = Storage Node object would be as disruptive as doing a replacement = registration of the entity, since the target has only one Storage Node = object associated with all of its portal groups.

Thanks for any help on this.

Paul

------_=_NextPart_001_01C800BD.C31E11B1-- --===============0867960469== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0867960469==-- From ips-bounces@ietf.org Thu Sep 27 05:23:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iapa0-0002GJ-Gs; Thu, 27 Sep 2007 05:22:44 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IapZz-0002GC-QD for ips-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 05:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IapZz-0002G4-Fg for ips@ietf.org; Thu, 27 Sep 2007 05:22:43 -0400 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IapZo-00004q-9t for ips@ietf.org; Thu, 27 Sep 2007 05:22:43 -0400 Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8R9MD3n020467 for ; Thu, 27 Sep 2007 09:22:17 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JP000J01SME7Q00@mail-apac.sun.com> (original mail from Victor.Li@Sun.COM) for ips@ietf.org; Thu, 27 Sep 2007 17:22:13 +0800 (SGT) Received: from [129.158.144.124] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JP0009BSSP0O266@mail-apac.sun.com>; Thu, 27 Sep 2007 17:22:13 +0800 (SGT) Date: Thu, 27 Sep 2007 17:22:50 +0800 From: Victor Li Subject: Re: [Ips] updating iSNS registration for portal IP address change In-reply-to: <16236EEEF4D4264DA31C2E35E3607CFE0A3959FF@coex02.trans.corp> To: Paul Hughes Message-id: <46FB766A.3090809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=windows-1252 References: <16236EEEF4D4264DA31C2E35E3607CFE0A3959FF@coex02.trans.corp> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sineb-mail-2.sun.com id l8R9MD3n020467 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "IP Storage Mailing List \(E-mail\)" 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: , Errors-To: ips-bounces@ietf.org Paul Hughes wrote: > > I am trying to determine the proper way to update an iSNS server when=20 > the IP address of an iSCSI target port changes. In my case, I have a=20 > multi-ported iSCSI target that registers a single Storage Node object=20 > and multiple Portal and Portal Group objects. > > One method is to re-register the entire Network Entity using=20 > DevAttrReg with the replace flag set. This method seems rather=20 > disruptive as SCNs will be generated for the de-registered objects and=20 > additional SCNs are generated for registration of the new objects. I=20 > assume this means that iSCSI initiators in the target's Discovery=20 > Domain might logout all sessions with the target's portals only to=20 > re-login a short time later. Is this true? I'd like to avoid causing=20 > logouts on any portals that retain their original IP address. > > Alternately, I can de-register the Portal object for the old IP=20 > address of the target port using DevDereg and then register a new=20 > Portal object for the new IP address using DevAttrReg. However, I=20 > don=92t believe it's possible to de-register the old Portal Group=20 > objects without de-registering the Storage Node object. > It seems this is the only way with minimal effort. The old Portal Group=20 objects will become dummy objects and remain in the server before the=20 Storage Node or Network Entity object is de-registered. But if you=20 change the IP address of the target portal back, you will just need to=20 re-register the Portal object, no need to re-register the Portal Group=20 object, the old one will be re-used. Regards, Victor > > In my case, I believe that de-registering the Storage Node object=20 > would be as disruptive as doing a replacement registration of the=20 > entity, since the target has only one Storage Node object associated=20 > with all of its portal groups. > > Thanks for any help on this. > > Paul > > -----------------------------------------------------------------------= - > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > =20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips