From ips-bounces@ietf.org Thu Oct 18 17:32: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 1Iicy2-0000u4-J8; Thu, 18 Oct 2007 17:31:46 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Iicy1-0000t6-E1 for ips-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 17:31:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicy0-0000ie-GT for ips@ietf.org; Thu, 18 Oct 2007 17:31:44 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iicxr-0001oC-UG for ips@ietf.org; Thu, 18 Oct 2007 17:31:36 -0400 Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 18 Oct 2007 14:31:25 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 0C34F2AE; Thu, 18 Oct 2007 14:31:25 -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 E01A32AE; Thu, 18 Oct 2007 14:31:24 -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 FUZ01683; Thu, 18 Oct 2007 14:31:08 -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 DA84620502; Thu, 18 Oct 2007 14:31:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] NOP-IN question Date: Thu, 18 Oct 2007 14:30:33 -0700 Message-ID: <87AC500EEF9B9344B4A8D8A017C2F45501987D03@NT-SJCA-0752.brcm.ad.broadcom.com> In-Reply-To: <368FBF3D8437A748BA8222526BF9309902C5D084@aime2k302.adaptec.com> Thread-Topic: [Ips] NOP-IN question Thread-Index: Acf8ftmwaqfsmzU5RQurQLZhp63TswEHBDiABEwXTEA= References: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D591@MERCURY.inside.istor.com> <368FBF3D8437A748BA8222526BF9309902C5D084@aime2k302.adaptec.com> From: "Pat Thaler" To: "Sandars, Ken" , "Ken Craig" , ips@ietf.org X-WSS-ID: 6B090F274QC2250620-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Ken, There are MUSTs that require a target to send NOP-IN at times. See 10.4.11 on updating MaxCmdSN and 10.19 on resonding to an initiator ping. A requirement to have only one "on the wire" wouldn't be consistant with that. Also, since StatSN isn't advanced for a NOP initiated by the target and the one sent to update SN values gets no response from the initiator, the target doesn't know whether that type of SN is still in transit. Possibly at one time there was text about not sending too many of the target-initiated ping NOP-In PDUs but I don't see anything in the RFC. Regards, Pat=20 -----Original Message----- From: Sandars, Ken [mailto:ken_sandars@adaptec.com]=20 Sent: Wednesday, September 26, 2007 5:18 PM To: Ken Craig; ips@ietf.org Subject: RE: [Ips] NOP-IN question 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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Oct 19 11:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IitOY-0005cq-Pl; Fri, 19 Oct 2007 11:04:14 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IitOY-0005cj-0O for ips-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 11:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IitOX-0005ca-6y for ips@ietf.org; Fri, 19 Oct 2007 11:04:13 -0400 Received: from fmailhost02.isp.att.net ([207.115.11.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IitOQ-0002iE-SF for ips@ietf.org; Fri, 19 Oct 2007 11:04:13 -0400 Received: from ivvtdkv0981 (adsl-074-245-052-054.sip.jax.bellsouth.net[74.245.52.54]) by bellsouth.net (frfwmhc02) with SMTP id <20071019150352H0200sfagae>; Fri, 19 Oct 2007 15:03:53 +0000 X-Originating-IP: [74.245.52.54] Message-ID: <003a01c81261$455b7b10$0602a8c0@ivivity.com> From: "Eddy Quicksall" To: "Parav Pandit" , "Julian Satran" References: <921981.18764.qm@web30108.mail.mud.yahoo.com> Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn onsingle connection Date: Fri, 19 Oct 2007 11:03:54 -0400 MIME-Version: 1.0 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.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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="===============0385505974==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0385505974== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C8123F.BD2DBCB0" This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C8123F.BD2DBCB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, below you said "no" to #2. But is there a restriction in the RFC = (maybe I just don't remember it)? I agree it has no practical value but = I have used it to test my re-ordering logic with only one connection. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Parav Pandit=20 Cc: ips@ietf.org=20 Sent: Friday, August 31, 2007 11:53 AM Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn onsingle = connection Parav Pandit wrote on 31/08/2007 12:52:04: > Hi, > =20 > RFC 3720, section 3.2.2.1 says=20 >=20 > "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. " >=20 > (Assuming Single TCP connection ISCSI session) >=20 > 1. I interpret above 3.2.2.1 statement as=20 > SCSI layer gives SCSI commands to the ISCSI stack in > the order of Cmd-1 and Cmd-2.=20 > Cmd-1 will have CmdSn =3D 10. > Cmd-2 will have CmdSn =3D 11. > ISCSI stack CAN send PDUs to the TCP layer in > following order ONLY. > PDU-1 with Cmd-1. > PDU-2 with Cmd-2. >=20 > Is this correct interpretation? > Or >=20 Yes=20 > 2. On a SINGLE connection can ISCSI stack send the=20 > PDU-1 with Cmd-2 followed by=20 > PDU-2 with Cmd-1? >=20 NO > Assuming the answer of the question #2 is No, >=20 > 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. >=20 > So targets will receive out of order ISCSI PDUs from > the TCP layer and ISCSI stack handles them. >=20 > So then why initiators have restriction of sending > command in the increasing order of CmdSn on SINGLE TCP > connection? >=20 To simplify recovery and to... > Is it to simplify the implementation of targets > supporting only single TCP connection? >=20 >=20 and there was no visible motivation for out of order commands on a = single connection=20 > Regards, > Parav Pandit >=20 >=20 >=20 > =20 > = _________________________________________________________________________= ___________ > Looking for a deal? Find great prices on flights and hotels with=20 > Yahoo! FareChase. > http://farechase.yahoo.com/ >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0037_01C8123F.BD2DBCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian, below you said "no" to #2. But is = there a=20 restriction in the RFC (maybe I just don't remember it)? I agree it has = no=20 practical value but I have used it to test my re-ordering logic with = only one=20 connection.
 
Eddy
----- Original Message -----
From:=20 Julian Satran
Sent: Friday, August 31, 2007 = 11:53=20 AM
Subject: Re: [Ips] rationale to = send PDUs=20 in increasing CmdSn onsingle connection



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

> Hi,
>  
> RFC 3720, = section=20 3.2.2.1 says
>
> "On any connection, the iSCSI initiator = MUST=20 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 ISCSI=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=20 Cmd-1 and Cmd-2.
> Cmd-1 will have CmdSn =3D 10.
> Cmd-2 = will have=20 CmdSn =3D 11.
> ISCSI stack CAN send PDUs to the TCP layer = in
>=20 following order ONLY.
> PDU-1 with Cmd-1.
> PDU-2 with=20 Cmd-2.
>
> Is this correct interpretation?
>=20 Or
>
Yes
> 2. On a = SINGLE=20 connection can ISCSI stack send the
> PDU-1 with Cmd-2 followed = by=20
> PDU-2 with Cmd-1?
>
NO
>=20 Assuming the answer of the question #2 is No,
>
> 3. If = there are=20 multiple connections in a session then
> command MAY any way = reach out=20 of order. And targets
> need to wait for the previous expected=20 commands.
>
> So targets will receive out of order ISCSI = PDUs=20 from
> the TCP layer and ISCSI stack handles them.
> =
> So=20 then why initiators have restriction of sending
> command in the = increasing order of CmdSn on SINGLE TCP
> connection?
>=20
To simplify recovery and = to...
> Is it=20 to simplify the implementation of targets
> supporting only = single TCP=20 connection?
>
>=20

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

>=20 Regards,
> Parav Pandit
>
>
>
> =    =20    
>=20 = _________________________________________________________________________= ___________
>=20 Looking for a deal? Find great prices on flights and hotels with =
>=20 Yahoo! FareChase.
> http://farechase.yahoo.com/
>=20
>
> = _______________________________________________
> Ips=20 mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0037_01C8123F.BD2DBCB0-- --===============0385505974== 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 --===============0385505974==-- From ips-bounces@ietf.org Fri Oct 19 13:07:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivJu-0004b1-6f; Fri, 19 Oct 2007 13:07:34 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IivJs-0004Uy-N2 for ips-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 13:07:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivJr-0004Q5-Jp for ips@ietf.org; Fri, 19 Oct 2007 13:07:31 -0400 Received: from smtpoutm.mac.com ([17.148.16.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IivJq-00007H-2w for ips@ietf.org; Fri, 19 Oct 2007 13:07:31 -0400 Received: from mac.com (asmtp010-s [10.150.69.73]) by smtpoutm.mac.com (Xserve/smtpout004/MantshX 4.0) with ESMTP id l9JH7NwJ025511; Fri, 19 Oct 2007 10:07:24 -0700 (PDT) Received: from [17.151.103.69] ([17.151.103.69]) (authenticated bits=0) by mac.com (Xserve/asmtp010/MantshX 4.0) with ESMTP id l9JH7K0F005903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Oct 2007 10:07:21 -0700 (PDT) Message-Id: <91576639-ADC9-4BEC-92D4-B96A418F5709@mac.com> From: William Studenmund To: Eddy Quicksall In-Reply-To: <003a01c81261$455b7b10$0602a8c0@ivivity.com> Mime-Version: 1.0 (Apple Message framework v911) Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn onsingle connection X-Priority: 3 Date: Fri, 19 Oct 2007 10:07:20 -0700 References: <921981.18764.qm@web30108.mail.mud.yahoo.com> <003a01c81261$455b7b10$0602a8c0@ivivity.com> X-Mailer: Apple Mail (2.911) X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: Ips , Julian Satran 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="===============1653068914==" Errors-To: ips-bounces@ietf.org --===============1653068914== Content-Type: multipart/alternative; boundary=Apple-Mail-13--241924354 --Apple-Mail-13--241924354 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 19, 2007, at 8:03 AM, Eddy Quicksall wrote: > Julian, below you said "no" to #2. But is there a restriction in the > RFC (maybe I just don't remember it)? I agree it has no practical > value but I have used it to test my re-ordering logic with only one > connection. Parav quoted a MUST from the RFC on this, so I'd call that a restriction. :-) I agree that it's a reasonable thing to do to test re-ordering logic. But I think that test environments don't count in that to be a good test of error handling, they _must_ break the spec. :-) Otherwise it's exceptionally difficult to reproducibly test how devices handle error conditions. :-) Take care, Bill > ---- Original Message ----- > From: Julian Satran > To: Parav Pandit > Cc: ips@ietf.org > Sent: Friday, August 31, 2007 11:53 AM > Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn > onsingle 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 --Apple-Mail-13--241924354 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 19, 2007, at = 8:03 AM, Eddy Quicksall wrote:

Julian, below you said "no" to #2. But is there a = restriction in the RFC (maybe I just don't remember it)? I agree it has = no practical value but I have used it to test my re-ordering logic with = only one connection.

Parav quoted a MUST from = the RFC on this, so I'd call that a restriction. :-)

I agree that it's a = reasonable thing to do to test re-ordering logic. But I think that test = environments don't count in that to be a good test of error handling, = they _must_ break the spec. :-) Otherwise it's exceptionally difficult = to reproducibly test how devices handle error conditions. = :-)

Take = care,

Bill

---- = Original Message -----
Sent: Friday, August 31, 2007 = 11:53 AM
Subject: Re: [Ips] rationale to send = PDUs in increasing CmdSn onsingle = 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 =3D 10.
> Cmd-2 will have CmdSn =3D 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 
= --Apple-Mail-13--241924354-- --===============1653068914== 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 --===============1653068914==-- From ips-bounces@ietf.org Fri Oct 19 17:24:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IizJt-0002Pm-Ub; Fri, 19 Oct 2007 17:23:49 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IizJr-0002Lu-VV for ips-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 17:23:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IizJq-00024b-Pg for ips@ietf.org; Fri, 19 Oct 2007 17:23:46 -0400 Received: from mtagate8.de.ibm.com ([195.212.29.157]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IizJl-0007YP-FQ for ips@ietf.org; Fri, 19 Oct 2007 17:23:42 -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 l9JLNdZf383202 for ; Fri, 19 Oct 2007 21:23:39 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 l9JLNeew2302036 for ; Fri, 19 Oct 2007 23:23:40 +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 l9JLNdeK007086 for ; Fri, 19 Oct 2007 23:23:39 +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 l9JLNdqx007083; Fri, 19 Oct 2007 23:23:39 +0200 In-Reply-To: <91576639-ADC9-4BEC-92D4-B96A418F5709@mac.com> References: <921981.18764.qm@web30108.mail.mud.yahoo.com> <003a01c81261$455b7b10$0602a8c0@ivivity.com> <91576639-ADC9-4BEC-92D4-B96A418F5709@mac.com> To: William Studenmund MIME-Version: 1.0 Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn onsingle connection X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Julian Satran Message-ID: Date: Fri, 19 Oct 2007 23:23:34 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 19/10/2007 23:23:39, Serialize complete at 19/10/2007 23:23:39 X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: Ips , 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: , Content-Type: multipart/mixed; boundary="===============0013665879==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0013665879== Content-Type: multipart/alternative; boundary="=_alternative 00758158C2257379_=" This is a multipart message in MIME format. --=_alternative 00758158C2257379_= Content-Type: text/plain; charset="US-ASCII" yes it is must and besides being pointless sending out of order would break some assumptions about detecting missing items (as Pat has nicely outlined in her note). Julo From: William Studenmund To: Eddy Quicksall Cc: Parav Pandit , Julian Satran/Haifa/IBM@IBMIL, Ips Date: 19/10/07 19:07 Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn onsingle connection On Oct 19, 2007, at 8:03 AM, Eddy Quicksall wrote: Julian, below you said "no" to #2. But is there a restriction in the RFC (maybe I just don't remember it)? I agree it has no practical value but I have used it to test my re-ordering logic with only one connection. Parav quoted a MUST from the RFC on this, so I'd call that a restriction. :-) I agree that it's a reasonable thing to do to test re-ordering logic. But I think that test environments don't count in that to be a good test of error handling, they _must_ break the spec. :-) Otherwise it's exceptionally difficult to reproducibly test how devices handle error conditions. :-) Take care, Bill ---- Original Message ----- From: Julian Satran To: Parav Pandit Cc: ips@ietf.org Sent: Friday, August 31, 2007 11:53 AM Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn onsingle 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 --=_alternative 00758158C2257379_= Content-Type: text/html; charset="US-ASCII"
yes it is must and besides being pointless sending out of order would break some assumptions about detecting missing items (as Pat has nicely outlined in her note).

Julo


From: William Studenmund <wrstuden@mac.com>
To: Eddy Quicksall <Quicksall_iSCSI@Bellsouth.net>
Cc: Parav Pandit <paravpandit@yahoo.com>, Julian Satran/Haifa/IBM@IBMIL, Ips <ips@ietf.org>
Date: 19/10/07 19:07
Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn        onsingle connection




On Oct 19, 2007, at 8:03 AM, Eddy Quicksall wrote:

Julian, below you said "no" to #2. But is there a restriction in the RFC (maybe I just don't remember it)? I agree it has no practical value but I have used it to test my re-ordering logic with only one connection.

Parav quoted a MUST from the RFC on this, so I'd call that a restriction. :-)

I agree that it's a reasonable thing to do to test re-ordering logic. But I think that test environments don't count in that to be a good test of error handling, they _must_ break the spec. :-) Otherwise it's exceptionally difficult to reproducibly test how devices handle error conditions. :-)

Take care,

Bill

---- Original Message -----
From: Julian Satran
To: Parav Pandit
Cc: ips@ietf.org
Sent: Friday, August 31, 2007 11:53 AM
Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn onsingle 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
--=_alternative 00758158C2257379_=-- --===============0013665879== 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 --===============0013665879==-- From ips-bounces@ietf.org Mon Oct 22 09:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijx8T-0006lv-A8; Mon, 22 Oct 2007 09:16:01 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Ijx8R-0006hb-Cs for ips-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 09:15:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijx8Q-0006Z1-IS for ips@ietf.org; Mon, 22 Oct 2007 09:15:58 -0400 Received: from fmailhost01.isp.att.net ([204.127.217.101]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijx8N-0008Me-HX for ips@ietf.org; Mon, 22 Oct 2007 09:15:56 -0400 Received: from ivvtdkv0981 (adsl-074-245-052-054.sip.jax.bellsouth.net[74.245.52.54]) by bellsouth.net (frfwmhc01) with SMTP id <20071022131553H0100j6qf4e>; Mon, 22 Oct 2007 13:15:54 +0000 X-Originating-IP: [74.245.52.54] Message-ID: <003801c814ad$acd81840$0602a8c0@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" , "Julian Satran" References: <921981.18764.qm@web30108.mail.mud.yahoo.com><003a01c81261$455b7b10$0602a8c0@ivivity.com><91576639-ADC9-4BEC-92D4-B96A418F5709@mac.com> Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn onsingleconnection Date: Mon, 22 Oct 2007 09:15:53 -0400 MIME-Version: 1.0 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.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: Ips X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0112821079==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0112821079== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C8148C.251D3FF0" This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C8148C.251D3FF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Boy, that was dumb of me, I didn't even notice that statement in the = very email I sent out. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: William Studenmund=20 Cc: Ips ; Eddy Quicksall=20 Sent: Friday, October 19, 2007 5:23 PM Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn = onsingleconnection yes it is must and besides being pointless sending out of order would = break some assumptions about detecting missing items (as Pat has nicely = outlined in her note).=20 Julo=20 From: William Studenmund =20 To: Eddy Quicksall =20 Cc: Parav Pandit , Julian = Satran/Haifa/IBM@IBMIL, Ips =20 Date: 19/10/07 19:07 =20 Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn = onsingle connection=20 -------------------------------------------------------------------------= ----- On Oct 19, 2007, at 8:03 AM, Eddy Quicksall wrote:=20 Julian, below you said "no" to #2. But is there a restriction in the = RFC (maybe I just don't remember it)? I agree it has no practical value = but I have used it to test my re-ordering logic with only one = connection.=20 Parav quoted a MUST from the RFC on this, so I'd call that a = restriction. :-)=20 I agree that it's a reasonable thing to do to test re-ordering logic. = But I think that test environments don't count in that to be a good test = of error handling, they _must_ break the spec. :-) Otherwise it's = exceptionally difficult to reproducibly test how devices handle error = conditions. :-)=20 Take care,=20 Bill=20 ---- Original Message -----=20 From: Julian Satran=20 To: Parav Pandit=20 Cc: ips@ietf.org=20 Sent: Friday, August 31, 2007 11:53 AM=20 Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn onsingle = connection=20 Parav Pandit wrote on 31/08/2007 12:52:04: > Hi, > =20 > RFC 3720, section 3.2.2.1 says=20 >=20 > "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. " >=20 > (Assuming Single TCP connection ISCSI session) >=20 > 1. I interpret above 3.2.2.1 statement as=20 > SCSI layer gives SCSI commands to the ISCSI stack in > the order of Cmd-1 and Cmd-2.=20 > Cmd-1 will have CmdSn =3D 10. > Cmd-2 will have CmdSn =3D 11. > ISCSI stack CAN send PDUs to the TCP layer in > following order ONLY. > PDU-1 with Cmd-1. > PDU-2 with Cmd-2. >=20 > Is this correct interpretation? > Or >=20 Yes=20 > 2. On a SINGLE connection can ISCSI stack send the=20 > PDU-1 with Cmd-2 followed by=20 > PDU-2 with Cmd-1? >=20 NO > Assuming the answer of the question #2 is No, >=20 > 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. >=20 > So targets will receive out of order ISCSI PDUs from > the TCP layer and ISCSI stack handles them. >=20 > So then why initiators have restriction of sending > command in the increasing order of CmdSn on SINGLE TCP > connection? >=20 To simplify recovery and to... > Is it to simplify the implementation of targets > supporting only single TCP connection? >=20 >=20 and there was no visible motivation for out of order commands on a = single connection=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0035_01C8148C.251D3FF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Boy, that was dumb of me, I didn't even notice that=20 statement in the very email I sent out.
 
Eddy
----- Original Message -----
From:=20 Julian Satran
Sent: Friday, October 19, 2007 = 5:23=20 PM
Subject: Re: [Ips] rationale to = send PDUs=20 in increasing CmdSn onsingleconnection


yes it is must and = besides=20 being pointless sending out of order would break some assumptions = about=20 detecting missing items (as Pat has nicely outlined in her = note).=20

Julo


From:=20 William Studenmund <wrstuden@mac.com> =
To:=20 Eddy Quicksall <Quicksall_iSCSI@Bellsouth.n= et>=20
Cc:=20 Parav Pandit <paravpandit@yahoo.com>,=20 Julian Satran/Haifa/IBM@IBMIL, Ips=20 <ips@ietf.org>=20
Date:=20 19/10/07 19:07=20
Subject:=20 Re: [Ips] rationale to send = PDUs in=20 increasing CmdSn        onsingle=20 connection




On Oct 19, 2007, at 8:03 AM, Eddy Quicksall = wrote:

Julian, below you said "no" to = #2. But is=20 there a restriction in the RFC (maybe I just don't remember it)? I = agree it=20 has no practical value but I have used it to test my re-ordering logic = with=20 only one connection.

Parav quoted a MUST = from the=20 RFC on this, so I'd call that a restriction. :-)

I=20 agree that it's a reasonable thing to do to test re-ordering logic. = But I=20 think that test environments don't count in that to be a good test of = error=20 handling, they _must_ break the spec. :-) Otherwise it's exceptionally = difficult to reproducibly test how devices handle error conditions. = :-)=20

Take care,

Bill=20

---- Original Message -----
From: Julian Satran
To:=20 Parav=20 Pandit
Cc: ips@ietf.org
Sent: Friday,=20 August 31, 2007 11:53 AM
Subject: Re: = [Ips]=20 rationale to send PDUs in increasing CmdSn onsingle connection=20



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

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

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

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0035_01C8148C.251D3FF0-- --===============0112821079== 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 --===============0112821079==-- From ips-bounces@ietf.org Wed Oct 24 11:20:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iki25-0007qv-Tt; Wed, 24 Oct 2007 11:20:33 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Iki23-0007ny-Qn for ips-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 11:20:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iki22-0007js-Vs for ips@ietf.org; Wed, 24 Oct 2007 11:20:31 -0400 Received: from mail7.sea5.speakeasy.net ([69.17.117.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iki1w-0001vT-N0 for ips@ietf.org; Wed, 24 Oct 2007 11:20:30 -0400 Received: (qmail 32301 invoked from network); 24 Oct 2007 15:20:10 -0000 Received: from imac.asomi.com (HELO [66.92.48.27]) (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 24 Oct 2007 15:20:10 -0000 In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D591@MERCURY.inside.istor.com> References: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D591@MERCURY.inside.istor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2AC10BDD-22BD-4A36-9627-0A4555FFB73C@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [Ips] NOP-IN question Date: Wed, 24 Oct 2007 08:20:08 -0700 To: Ken Craig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 On Sep 21, 2007, at 11:40 AM, Ken Craig wrote: > 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 > > Section 8.1 of the iSER draft discusses the need to regulate Unexpected messages sent over an iSER connection, and defines a 'MaxOutstandingUnexpectedPDUs' key to regulate this behavior. An RDMA receiver (iSER or not) must pre-post untagged buffers. If it fails to do so the connection is torn down when the N+1st untagged message shows up. How it does so is left to each ULP. The 'MaxOutstandingUnexpectedPDUs' key enables iSER receivers to safely provision their untagged buffer pool (in combination with the existing logic that tells them how many expected PDUs to allow for). With plain iSCSI there is a presumption that an excessive number of unexpected messages will *stall* the connection, but not tear it down. Therefore there is no need for any explicit requirements on avoiding this situation. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Oct 31 18:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMSM-0001gS-7c; Wed, 31 Oct 2007 18:54:38 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1InMSL-0001ff-3W for ips-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 18:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMSK-0001fV-Po; Wed, 31 Oct 2007 18:54:36 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InMSH-0001FV-Uf; Wed, 31 Oct 2007 18:54:36 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 99B0AE9EF0; Wed, 31 Oct 2007 15:54:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071031225433.99B0AE9EF0@bosco.isi.edu> Date: Wed, 31 Oct 2007 15:54:33 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 5047 on DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI) 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 A new Request for Comments is now available in online RFC libraries. RFC 5047 Title: DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI) Author: M. Chadalapaka, J. Hufferd, J. Satran, H. Shah Status: Informational Date: October 2007 Mailbox: cbm@rose.hp.com, jhufferd@brocade.com, Julian_Satran@il.ibm.com, hemal@broadcom.com Pages: 49 Characters: 107970 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-iwarp-da-05.txt URL: http://www.rfc-editor.org/rfc/rfc5047.txt The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols. Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access (RDMA)-capable IP fabrics in the future comprising TCP, the Stream Control Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand. This memo provides information for the Internet community. This document is a product of the IP Storage Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Oct 31 18:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMSV-0001rS-2p; Wed, 31 Oct 2007 18:54:47 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1InMST-0001qV-4a for ips-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 18:54:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMSS-0001qN-PV; Wed, 31 Oct 2007 18:54:44 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMSS-0004ce-Ay; Wed, 31 Oct 2007 18:54:44 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 68E7CE9EF2; Wed, 31 Oct 2007 15:54:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071031225440.68E7CE9EF2@bosco.isi.edu> Date: Wed, 31 Oct 2007 15:54:40 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 5048 on Internet Small Computer System Interface (iSCSI) Corrections and Clarifications 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 A new Request for Comments is now available in online RFC libraries. RFC 5048 Title: Internet Small Computer System Interface (iSCSI) Corrections and Clarifications Author: M. Chadalapaka, Ed. Status: Standards Track Date: October 2007 Mailbox: cbm@rose.hp.com Pages: 38 Characters: 80149 Updates: RFC3720 See-Also: I-D Tag: draft-ietf-ips-iscsi-impl-guide-09.txt URL: http://www.rfc-editor.org/rfc/rfc5048.txt The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. [STANDARDS TRACK] This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Oct 31 18:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMSB-0001UA-Sz; Wed, 31 Oct 2007 18:54:27 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1InMS8-0001Rk-Vd for ips-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 18:54:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMS8-0001RQ-Ic; Wed, 31 Oct 2007 18:54:24 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMS8-0004by-2o; Wed, 31 Oct 2007 18:54:24 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id BD3D7E9EEE; Wed, 31 Oct 2007 15:54:23 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071031225423.BD3D7E9EEE@bosco.isi.edu> Date: Wed, 31 Oct 2007 15:54:23 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 5046 on Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) 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 A new Request for Comments is now available in online RFC libraries. RFC 5046 Title: Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) Author: M. Ko, M. Chadalapaka, J. Hufferd, U. Elzur, H. Shah, P. Thaler Status: Standards Track Date: October 2007 Mailbox: mako@us.ibm.com, cbm@rose.hp.com, jhufferd@brocade.com, Uri@Broadcom.com, hemal@broadcom.com, pthaler@broadcom.com Pages: 85 Characters: 202216 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-iser-06.txt URL: http://www.rfc-editor.org/rfc/rfc5046.txt Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol, such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. [STANDARDS TRACK] This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips