From exim@www1.ietf.org Sun Nov 2 21:20:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03452 for ; Sun, 2 Nov 2003 21:20:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGUKB-0007Ww-Ip for ips-archive@odin.ietf.org; Sun, 02 Nov 2003 21:20:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA32KBiZ028941 for ips-archive@odin.ietf.org; Sun, 2 Nov 2003 21:20:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGUKA-0007Wf-3z for ips-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 21:20:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03444 for ; Sun, 2 Nov 2003 21:19:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGUK7-00060K-00 for ips-web-archive@ietf.org; Sun, 02 Nov 2003 21:20:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGUK7-00060G-00 for ips-web-archive@ietf.org; Sun, 02 Nov 2003 21:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGUK3-0007Vk-6j; Sun, 02 Nov 2003 21:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGUJT-0007UE-AN for ips@optimus.ietf.org; Sun, 02 Nov 2003 21:19:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03367 for ; Sun, 2 Nov 2003 21:19:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGUJQ-0005yh-00 for ips@ietf.org; Sun, 02 Nov 2003 21:19:24 -0500 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1AGUJP-0005yO-00 for ips@ietf.org; Sun, 02 Nov 2003 21:19:23 -0500 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 2 Nov 2003 19:18:49 -0700 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Sun, 02 Nov 2003 19:18:47 -0700 Received: from SNEXCH01.mcdata.com ([172.19.161.13]) by MC4EXCH03.mcdata.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 2 Nov 2003 19:18:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A1B0.CEEBAF9E" Date: Sun, 2 Nov 2003 18:18:45 -0800 Message-ID: <501EA67E9359C645A10C42EB5B52480D35F51F@SNEXCH01.mcdata.com> Thread-Topic: iSNS boot information Thread-Index: AcOgh8eaL3f6U/XZQUeycWDsFqg1iABJ3yWg From: "Kevin Gibbons" To: Cc: X-OriginalArrivalTime: 03 Nov 2003 02:18:47.0062 (UTC) FILETIME=[CFE39360:01C3A1B0] Subject: [Ips] RE: iSNS boot information Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A1B0.CEEBAF9E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Josh, the latest drafts of the documents referenced would be: 1) Using DHCP to discover the iSNS http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-10.txt =20 2) Using the Discovery Domain boot list option http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-21.txt please see Section 6.11.2.9, Discovery Domain Features. =20 Please let me know if you have any questions. Regards, Kevin =20 -----Original Message----- From: jvillago@jw.org [mailto:jvillago@jw.org]=20 Sent: Saturday, November 01, 2003 6:53 AM To: Kevin Gibbons Cc: ips@ece.cmu.edu Subject: iSNS boot information =09 =09 Hi Kevin,=20 I found the following post to be very interesting. We're trying to boot an iSCSI initiator using iSNS. Where is the document referenced below? The link no longer works. Any other information you may have would be quite useful. Thanks. Josh=20 =09 ------------------------------------------------------------------------ --------=20 To: ips@ece.cmu.edu=20 Subject: iSCSI Boot: use of iSNS=20 From: Kevin Gibbons =20 Date: Wed, 19 Mar 2003 10:48:33 -0800=20 Content-Type: text/plain=20 Sender: owner-ips@ece.cmu.edu=20 =09 ------------------------------------------------------------------------ --------=20 At the IPS WG session at IETF 56, we discussed the iSCSI Boot draft. It=20 involved how to find the iSCSI target to boot from, as well as security=20 issues for the process. The following is a process using DHCP and iSNS to=20 find the appropriate iSCSI target to use for boot:=20 1) use DHCP to find the iSNS Server. Please see:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-05.txt =20 2) query the iSNS server to find the Discovery Domain Feature "Boot List=20 Enabled" for the specified iSCSI node or entity. Please see:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-18.txt =20 ---=20 6.10.2.9 Discovery Domain Features=20 The Discovery Domain Features is a bitmap indicating the features of=20 this DD. The bit positions are defined below. A bit set to 1=20 indicates the DD has the corresponding characteristics.=20 Bit Position DD Feature=20 ------------ ----------=20 31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)=20 All Others RESERVED=20 =20 Boot List: this feature indicates that the targets in this DD provide=20 boot capabilities for the member initiators, as described in [iSCSI-=20 boot].=20 ---=20 Couple items:=20 1) The iSNS Server provides the ability to distribute security policies.=20 2) The size of an iSNS Client may vary. However, the code to query the iSNS=20 server for a boot-list enabled DD based on an iSCSI name is not very=20 complex. Most of the complexity in iSNSP is on the server side. 3) SLPv2 and multicast are other alternative methods to DHCP to find the=20 iSNS server. Additionally, SLPv2 is an alternative to iSNS for locating the=20 target to boot from, which is already described in iSCSI-boot.=20 SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent=20 responsible for delivering the message to the intended recipient, you are herby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY=20 PROHIBITED. Anyone who receives confidential and privileged information in error should= =20 notify us immediately by telephone and mail the original message to us at= the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions=20 apply to that information. (gate01) ------_=_NextPart_001_01C3A1B0.CEEBAF9E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Josh,
    the latest drafts of the documents referenced= would=20 be:
1)=20 Using DHCP to discover the iSNS
    h= ttp://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-10.txt
 
2)=20 Using the Discovery Domain boot list option
    http://= www.ietf.org/internet-drafts/draft-ietf-ips-isns-21.txt please=20 see Section 6.11.2.9, Discovery Domain Features.
 
Please=20 let me know if you have any questions.
    Regards, Kevin

 
-----Original Message-----
From:= jvillago@jw.org=20 [mailto:jvillago@jw.org]
Sent: Saturday, November 01, 2003= 6:53=20 AM
To: Kevin Gibbons
Cc:=20 ips@ece.cmu.edu
Subject: iSNS boot= information

Hi Kevin,

I found the following post to be very=20 interesting. We're trying to boot an iSCSI initiator using iSNS. Where is= the=20 document referenced below? The link no longer works. Any other= information you=20 may have would be quite useful. Thanks.

Josh

-------------------------------------------------------------------= -------------=20

To: ips@ece.cmu.edu
Subject: iSCSI Boot: use of iSNS=
From: Kevin Gibbons= <kgibbons@NishanSystems.com>=20
Date: Wed, 19 Mar 2003 10:48:33= -0800=20
Content-Type: text/plain=20
Sender: owner-ips@ece.cmu.edu=20

-------------------------------------------------------------------= -------------=20

At the IPS WG session at IETF 56, we= discussed=20 the iSCSI Boot draft.  It
involved how to find the iSCSI target to boot= from, as=20 well as security
issues for the= =20 process.  The following is a process using DHCP and iSNS to=20
find the appropriate iSCSI target to= use for=20 boot:
1) use DHCP to find the= iSNS=20 Server.  Please see:=20
        <= U>http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-05= .txt=20

2) query the iSNS server to find the= Discovery=20 Domain Feature "Boot List
Enabled" for=20 the specified iSCSI node or entity.  Please see:=20
        http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-18.txt=20
---
6.10.2.9 Discovery Domain Features=
   The Discovery Domain Features is a= bitmap=20 indicating the features of
   this DD.  The bit positions= are=20 defined below.  A bit set to 1
   indicates the DD has the= corresponding=20 characteristics.

      = Bit=20 Position     DD Feature
      =20 ------------     ----------
         =20 31 (Lsb)      Boot List Enabled (1)/Boot List=20 Disabled (0)
        All=20 Others      RESERVED
   
   Boot List: this feature indicates= that the=20 targets in this DD provide
   boot capabilities for the member=20 initiators, as described in [iSCSI-
   boot].
---
Couple=20 items:
1) The iSNS Server= provides the=20 ability to distribute security policies.
2) The size of an iSNS Client may vary. = However,=20 the code to query the iSNS
server for=20 a boot-list enabled DD based on an iSCSI name is not very=
complex.  Most of the complexity in iSNSP= is on=20 the server side.
3) SLPv2 and=20 multicast are other alternative methods to DHCP to find the=
iSNS server.  Additionally, SLPv2 is an=20 alternative to iSNS for locating the
target to boot from, which is already described= in=20 iSCSI-boot. 

SPECIAL NOTICE=
=20

All information transmitted hereby is intended only for the use of the=20
addressee(s) named  above and may contain confidential and privileged=20
information. Any unauthorized  review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader of
this message is not the intended recipient(s) or the employee or agent=20
responsible for delivering the message to the intended recipient, you
are herby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY=20
PROHIBITED.

Anyone who receives confidential and privileged information in error should=
=20
notify us immediately by telephone and mail the original message to us at=
 the
above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions=20
apply to that information. (gate01)
------_=_NextPart_001_01C3A1B0.CEEBAF9E-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 3 17:43:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00047 for ; Mon, 3 Nov 2003 17:43:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnPh-0006ix-UY for ips-archive@odin.ietf.org; Mon, 03 Nov 2003 17:43:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Mh9hD025843 for ips-archive@odin.ietf.org; Mon, 3 Nov 2003 17:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnPh-0006ik-Nz for ips-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 17:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29982 for ; Mon, 3 Nov 2003 17:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnPd-0007PL-00 for ips-web-archive@ietf.org; Mon, 03 Nov 2003 17:43:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGnPd-0007PF-00 for ips-web-archive@ietf.org; Mon, 03 Nov 2003 17:43:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnPY-0006hY-U5; Mon, 03 Nov 2003 17:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmye-00035l-NW for ips@optimus.ietf.org; Mon, 03 Nov 2003 17:15:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27504 for ; Mon, 3 Nov 2003 17:15:01 -0500 (EST) From: jvillago@jw.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGmyc-0006Rs-00 for ips@ietf.org; Mon, 03 Nov 2003 17:15:10 -0500 Received: from smtp1mail.jw.org ([208.210.221.75] helo=ns.wtbts.org) by ietf-mx with smtp (Exim 4.12) id 1AGmyb-0006Pp-00 for ips@ietf.org; Mon, 03 Nov 2003 17:15:09 -0500 Received: from xweb1.jw.org by ns.wtbts.org via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 3 Nov 2003 22:15:09 UT Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A257.DF356B92" Date: Mon, 3 Nov 2003 17:14:38 -0500 Message-ID: <3F0FBCC958823C46B79116B1EF0DCEBB0D0DBC02@bexch10.usa.wtbts.net> Thread-Topic: iSNS boot information Thread-Index: AcOgh8eaL3f6U/XZQUeycWDsFqg1iABJ3yWgAClpc9A= To: Cc: X-OriginalArrivalTime: 03 Nov 2003 22:14:39.0115 (UTC) FILETIME=[DF71FDB0:01C3A257] Subject: [Ips] RE: iSNS boot information Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A257.DF356B92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kevin, =20 Thank you very much! After reading Section 6.11.2.9, I'm assuming what we're trying to do should work. Our scenario is as follows: =20 Boot Windows XP w/ Microsoft's iSCSI driver MS iSNS Server =20 We want our PC's to receive it's DCHP address along with first boot LUN from iSNS in order to boot MS XP directly from it. Is this possible with the current implementations addressed below? =20 =20 Josh =20 -----Original Message----- From: Kevin Gibbons [mailto:kevin.gibbons@mcdata.com]=20 Sent: Sunday, November 02, 2003 9:19 PM To: Villagomez, Joshua Cc: ips@ietf.org Subject: RE: iSNS boot information Josh, the latest drafts of the documents referenced would be: 1) Using DHCP to discover the iSNS =09 http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-10.txt =20 2) Using the Discovery Domain boot list option =09 http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-21.txt please see Section 6.11.2.9, Discovery Domain Features. =20 Please let me know if you have any questions. Regards, Kevin =09 =20 -----Original Message----- From: jvillago@jw.org [mailto:jvillago@jw.org]=20 Sent: Saturday, November 01, 2003 6:53 AM To: Kevin Gibbons Cc: ips@ece.cmu.edu Subject: iSNS boot information =09 =09 Hi Kevin,=20 I found the following post to be very interesting. We're trying to boot an iSCSI initiator using iSNS. Where is the document referenced below? The link no longer works. Any other information you may have would be quite useful. Thanks. Josh=20 =09 ------------------------------------------------------------------------ --------=20 To: ips@ece.cmu.edu=20 Subject: iSCSI Boot: use of iSNS=20 From: Kevin Gibbons =20 Date: Wed, 19 Mar 2003 10:48:33 -0800=20 Content-Type: text/plain=20 Sender: owner-ips@ece.cmu.edu=20 =09 ------------------------------------------------------------------------ --------=20 At the IPS WG session at IETF 56, we discussed the iSCSI Boot draft. It=20 involved how to find the iSCSI target to boot from, as well as security=20 issues for the process. The following is a process using DHCP and iSNS to=20 find the appropriate iSCSI target to use for boot:=20 1) use DHCP to find the iSNS Server. Please see:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-05.txt =20 2) query the iSNS server to find the Discovery Domain Feature "Boot List=20 Enabled" for the specified iSCSI node or entity. Please see:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-18.txt =20 ---=20 6.10.2.9 Discovery Domain Features=20 The Discovery Domain Features is a bitmap indicating the features of=20 this DD. The bit positions are defined below. A bit set to 1=20 indicates the DD has the corresponding characteristics.=20 Bit Position DD Feature=20 ------------ ----------=20 31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)=20 All Others RESERVED=20 =20 Boot List: this feature indicates that the targets in this DD provide=20 boot capabilities for the member initiators, as described in [iSCSI-=20 boot].=20 ---=20 Couple items:=20 1) The iSNS Server provides the ability to distribute security policies.=20 2) The size of an iSNS Client may vary. However, the code to query the iSNS=20 server for a boot-list enabled DD based on an iSCSI name is not very=20 complex. Most of the complexity in iSNSP is on the server side.=20 3) SLPv2 and multicast are other alternative methods to DHCP to find the=20 iSNS server. Additionally, SLPv2 is an alternative to iSNS for locating the=20 target to boot from, which is already described in iSCSI-boot.=20 SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent=20 responsible for delivering the message to the intended recipient, you are herby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY=20 PROHIBITED. Anyone who receives confidential and privileged information in error should=20 notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions=20 apply to that information. (gate01) ------_=_NextPart_001_01C3A257.DF356B92 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Kevin,
 
Thank you very=20 much! After reading Section 6.11.2.9, I'm assuming what we're trying to = do=20 should work. Our scenario is as follows:
 
Boot Windows XP=20 w/ Microsoft's iSCSI driver
MS = iSNS=20 Server
 
We = want our=20 PC's to receive it's DCHP address along with first boot LUN from iSNS in = order=20 to boot MS XP directly from it. Is this possible with the current=20 implementations addressed below?
 
 

Josh

 


-----Original = Message-----
From: Kevin=20 Gibbons [mailto:kevin.gibbons@mcdata.com]
Sent: Sunday, = November 02,=20 2003 9:19 PM
To: Villagomez, Joshua
Cc:=20 ips@ietf.org
Subject: RE: iSNS boot = information

Josh,
    the latest drafts of the documents referenced = would=20 be:
1)=20 Using DHCP to discover the iSNS
    http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-10.txt=
 
2)=20 Using the Discovery Domain boot list option
    h= ttp://www.ietf.org/internet-drafts/draft-ietf-ips-isns-21.txt pl= ease=20 see Section 6.11.2.9, Discovery Domain Features.
 
Please let me know if you have any = questions.
    Regards, Kevin

 
-----Original Message-----
From:=20 jvillago@jw.org [mailto:jvillago@jw.org]
Sent: Saturday, = November=20 01, 2003 6:53 AM
To: Kevin Gibbons
Cc:=20 ips@ece.cmu.edu
Subject: iSNS boot=20 information

Hi Kevin,

I found the following post to be = very=20 interesting. We're trying to boot an iSCSI initiator using iSNS. = Where is=20 the document referenced below? The link no longer works. Any other=20 information you may have would be quite useful. Thanks.

Josh

------------------------------------------------------------------= --------------=20

To: ips@ece.cmu.edu =
Subject: iSCSI Boot: use of iSNS =
From: Kevin Gibbons=20 <kgibbons@NishanSystems.com>
Date: Wed, 19 Mar 2003 10:48:33 -0800=20
Content-Type: text/plain=20
Sender: = owner-ips@ece.cmu.edu=20

------------------------------------------------------------------= --------------=20

At the IPS WG session at IETF 56, = we=20 discussed the iSCSI Boot draft.  It
involved how to find the iSCSI target to = boot from,=20 as well as security
issues = for the=20 process.  The following is a process using DHCP and iSNS = to=20
find the appropriate iSCSI target = to use=20 for boot:
1) use DHCP to = find the=20 iSNS Server.  Please see:=20
        http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsop= tion-05.txt=20

2) query the iSNS server to find = the=20 Discovery Domain Feature "Boot List
Enabled" for the specified iSCSI node or=20 entity.  Please see:=20
        <= U>http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-1= 8.txt=20
---
6.10.2.9 Discovery Domain Features =
   The Discovery Domain Features = is a=20 bitmap indicating the features of
   this DD.  The bit = positions are=20 defined below.  A bit set to 1
   indicates the DD has the = corresponding=20 characteristics.

       Bit=20 Position     DD Feature
      =20 ------------     ----------
         =20 31 (Lsb)      Boot List Enabled (1)/Boot = List=20 Disabled (0)
        = All=20 Others      RESERVED
   
   Boot List: this feature = indicates that=20 the targets in this DD provide
   boot capabilities for the = member=20 initiators, as described in [iSCSI-
   boot].
---
Couple=20 items:
1) The iSNS Server = provides=20 the ability to distribute security policies.
2) The size of an iSNS Client may = vary. =20 However, the code to query the iSNS
server for a boot-list enabled DD based on = an iSCSI=20 name is not very
complex.  Most=20 of the complexity in iSNSP is on the server side.
3) SLPv2 and multicast are other = alternative methods=20 to DHCP to find the
iSNS=20 server.  Additionally, SLPv2 is an alternative to iSNS for = locating=20 the
target to boot from, = which is=20 already described in iSCSI-boot. 

SPECIAL NOTICE=20

All information transmitted hereby is intended only for the use of the=20
addressee(s) named  above and may contain confidential and privileged=20
information. Any unauthorized  review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader =
of
this message is not the intended recipient(s) or the employee or agent=20
responsible for delivering the message to the intended recipient, you
are herby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY=20
PROHIBITED.

Anyone who receives confidential and privileged information in error =
should=20
notify us immediately by telephone and mail the original message to us =
at the
above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions=20
apply to that information. (gate01)
=00 ------_=_NextPart_001_01C3A257.DF356B92-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 3 22:30:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11775 for ; Mon, 3 Nov 2003 22:30:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrtb-0002bx-9E for ips-archive@odin.ietf.org; Mon, 03 Nov 2003 22:30:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA43UJT8010033 for ips-archive@odin.ietf.org; Mon, 3 Nov 2003 22:30:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrtb-0002bk-4H for ips-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 22:30:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11748 for ; Mon, 3 Nov 2003 22:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGrtX-0004IV-00 for ips-web-archive@ietf.org; Mon, 03 Nov 2003 22:30:15 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AGrtW-0004IL-00 for ips-web-archive@ietf.org; Mon, 03 Nov 2003 22:30:14 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AGrtV-0008Jc-SN for ips-web-archive@ietf.org; Mon, 03 Nov 2003 22:30:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrtK-0002ZP-KG; Mon, 03 Nov 2003 22:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrt2-0002Y1-IH for ips@optimus.ietf.org; Mon, 03 Nov 2003 22:29:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11709 for ; Mon, 3 Nov 2003 22:29:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGrsz-0004Fj-00 for ips@ietf.org; Mon, 03 Nov 2003 22:29:41 -0500 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1AGrsy-0004FU-00 for ips@ietf.org; Mon, 03 Nov 2003 22:29:40 -0500 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Nov 2003 20:29:11 -0700 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Mon, 03 Nov 2003 20:29:10 -0700 Received: from SNEXCH01.mcdata.com ([172.19.161.13]) by MC4EXCH03.mcdata.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Nov 2003 20:29:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A283.CE7F0E06" Date: Mon, 3 Nov 2003 19:29:08 -0800 Message-ID: <501EA67E9359C645A10C42EB5B52480D36123B@SNEXCH01.mcdata.com> Thread-Topic: iSNS boot information Thread-Index: AcOgh8eaL3f6U/XZQUeycWDsFqg1iABJ3yWgAClpc9AACrYtcA== From: "Kevin Gibbons" To: Cc: , "Joe Souza" , "Charles Monia" X-OriginalArrivalTime: 04 Nov 2003 03:29:10.0031 (UTC) FILETIME=[CF6341F0:01C3A283] Subject: [Ips] RE: iSNS boot information Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A283.CE7F0E06 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Josh, based on the draft specifications, your proposed design will work. =20 The DHCP Server can provide a client both an IP-Address and the primary, and optionally a secondary, iSNS Server address. The client can then obtain the boot target from the iSNS Server by querying for the Discovery Domain marked as bootlist. =20 A couple notes: 1) the iSNS DHC server option number has not yet been defined by IANA. Any option number used now may change if/when the draft is ratified as an RFC. 2) the DHC server would need to be properly configured to return the appropriate iSNS Server address. =20 Regards, Kevin -----Original Message----- From: jvillago@jw.org [mailto:jvillago@jw.org]=20 Sent: Monday, November 03, 2003 2:15 PM To: Kevin Gibbons Cc: ips@ietf.org Subject: RE: iSNS boot information =09 =09 Kevin, =20 Thank you very much! After reading Section 6.11.2.9, I'm assuming what we're trying to do should work. Our scenario is as follows: =20 Boot Windows XP w/ Microsoft's iSCSI driver MS iSNS Server =20 We want our PC's to receive it's DCHP address along with first boot LUN from iSNS in order to boot MS XP directly from it. Is this possible with the current implementations addressed below? =20 =20 Josh =20 =09 -----Original Message----- From: Kevin Gibbons [mailto:kevin.gibbons@mcdata.com]=20 Sent: Sunday, November 02, 2003 9:19 PM To: Villagomez, Joshua Cc: ips@ietf.org Subject: RE: iSNS boot information =09 =09 Josh, the latest drafts of the documents referenced would be: 1) Using DHCP to discover the iSNS =09 http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-10.txt =20 2) Using the Discovery Domain boot list option =09 http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-21.txt please see Section 6.11.2.9, Discovery Domain Features. =20 Please let me know if you have any questions. Regards, Kevin =09 =20 -----Original Message----- From: jvillago@jw.org [mailto:jvillago@jw.org]=20 Sent: Saturday, November 01, 2003 6:53 AM To: Kevin Gibbons Cc: ips@ece.cmu.edu Subject: iSNS boot information =09 =09 Hi Kevin,=20 I found the following post to be very interesting. We're trying to boot an iSCSI initiator using iSNS. Where is the document referenced below? The link no longer works. Any other information you may have would be quite useful. Thanks. Josh=20 =09 ------------------------------------------------------------------------ --------=20 To: ips@ece.cmu.edu=20 Subject: iSCSI Boot: use of iSNS=20 From: Kevin Gibbons Date: Wed, 19 Mar 2003 10:48:33 -0800=20 Content-Type: text/plain=20 Sender: owner-ips@ece.cmu.edu=20 =09 ------------------------------------------------------------------------ --------=20 At the IPS WG session at IETF 56, we discussed the iSCSI Boot draft. It=20 involved how to find the iSCSI target to boot from, as well as security=20 issues for the process. The following is a process using DHCP and iSNS to=20 find the appropriate iSCSI target to use for boot:=20 1) use DHCP to find the iSNS Server. Please see:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-05.txt =20 2) query the iSNS server to find the Discovery Domain Feature "Boot List=20 Enabled" for the specified iSCSI node or entity. Please see:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-18.txt =20 ---=20 6.10.2.9 Discovery Domain Features=20 The Discovery Domain Features is a bitmap indicating the features of=20 this DD. The bit positions are defined below. A bit set to 1=20 indicates the DD has the corresponding characteristics.=20 Bit Position DD Feature=20 ------------ ----------=20 31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)=20 All Others RESERVED=20 =20 Boot List: this feature indicates that the targets in this DD provide=20 boot capabilities for the member initiators, as described in [iSCSI-=20 boot].=20 ---=20 Couple items:=20 1) The iSNS Server provides the ability to distribute security policies.=20 2) The size of an iSNS Client may vary. However, the code to query the iSNS=20 server for a boot-list enabled DD based on an iSCSI name is not very=20 complex. Most of the complexity in iSNSP is on the server side.=20 3) SLPv2 and multicast are other alternative methods to DHCP to find the=20 iSNS server. Additionally, SLPv2 is an alternative to iSNS for locating the=20 target to boot from, which is already described in iSCSI-boot.=20 SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent=20 responsible for delivering the message to the intended recipient, you are herby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY=20 PROHIBITED. Anyone who receives confidential and privileged information in error should=20 notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions=20 apply to that information. (gate01) ------_=_NextPart_001_01C3A283.CE7F0E06 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Josh,
    based on the draft specifications, your = proposed=20 design will work.
 
    The DHCP Server can provide a client = both an=20 IP-Address and the primary, and optionally a secondary, iSNS Server = address.  The client can then obtain the boot target from = the=20 iSNS Server by querying for the Discovery Domain marked as=20 bootlist.
 
    A couple notes:
1) the iSNS DHC server option number has not yet been = defined by=20 IANA.  Any option number used now may change if/when the draft = is=20 ratified as an RFC.
2) the=20 DHC server would need to be properly configured to return the = appropriate iSNS=20 Server address.
 
    Regards, Kevin
-----Original Message-----
From: = jvillago@jw.org=20 [mailto:jvillago@jw.org]
Sent: Monday, November 03, 2003 = 2:15=20 PM
To: Kevin Gibbons
Cc: = ips@ietf.org
Subject:=20 RE: iSNS boot information

Kevin,
 
Thank you=20 very much! After reading Section 6.11.2.9, I'm assuming what we're = trying to=20 do should work. Our scenario is as follows:
 
Boot Windows=20 XP w/ Microsoft's iSCSI driver
MS iSNS=20 Server
 
We want our=20 PC's to receive it's DCHP address along with first boot LUN from iSNS = in order=20 to boot MS XP directly from it. Is this possible with the current=20 implementations addressed below?
 
 

Josh

 


-----Original = Message-----
From:=20 Kevin Gibbons [mailto:kevin.gibbons@mcdata.com]
Sent: = Sunday,=20 November 02, 2003 9:19 PM
To: Villagomez, = Joshua
Cc:=20 ips@ietf.org
Subject: RE: iSNS boot = information

Josh,
    the latest drafts of the documents = referenced would=20 be:
1)=20 Using DHCP to discover the iSNS
    http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-10.txt=
 
2)=20 Using the Discovery Domain boot list option
    h= ttp://www.ietf.org/internet-drafts/draft-ietf-ips-isns-21.txt pl= ease=20 see Section 6.11.2.9, Discovery Domain Features.
 
Please let me know if you have any = questions.
    Regards, Kevin

 
-----Original Message-----
From:=20 jvillago@jw.org [mailto:jvillago@jw.org]
Sent: = Saturday,=20 November 01, 2003 6:53 AM
To: Kevin = Gibbons
Cc:=20 ips@ece.cmu.edu
Subject: iSNS boot=20 information

Hi Kevin,

I found the following post to be = very=20 interesting. We're trying to boot an iSCSI initiator using iSNS. = Where is=20 the document referenced below? The link no longer works. Any other = information you may have would be quite useful. Thanks.

Josh

------------------------------------------------------------------= --------------=20

To: ips@ece.cmu.edu =
Subject: iSCSI Boot: use of iSNS =
From: Kevin Gibbons=20 <kgibbons@NishanSystems.com>
Date: Wed, 19 Mar 2003 10:48:33 -0800=20
Content-Type: text/plain =
Sender: = owner-ips@ece.cmu.edu=20

------------------------------------------------------------------= --------------=20

At the IPS WG session at IETF = 56, we=20 discussed the iSCSI Boot draft.  It
involved how to find the iSCSI target to = boot from,=20 as well as security
issues for the=20 process.  The following is a process using DHCP and iSNS = to=20
find the appropriate iSCSI = target to use=20 for boot:
1) use DHCP to = find the=20 iSNS Server.  Please see:=20
        http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsop= tion-05.txt=20

2) query the iSNS server to find = the=20 Discovery Domain Feature "Boot List
Enabled" for the specified iSCSI node or=20 entity.  Please see:=20
        <= U>http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-1= 8.txt=20
---
6.10.2.9 Discovery Domain Features =
   The Discovery Domain = Features is a=20 bitmap indicating the features of
   this DD.  The bit = positions are=20 defined below.  A bit set to 1
   indicates the DD has the = corresponding=20 characteristics.

       Bit=20 Position     DD Feature
      =20 ------------     ----------
         =20 31 (Lsb)      Boot List Enabled (1)/Boot = List=20 Disabled (0)
        All=20 Others      RESERVED
   
   Boot List: this feature = indicates that=20 the targets in this DD provide
   boot capabilities for the = member=20 initiators, as described in [iSCSI-
   boot].
---
Couple=20 items:
1) The iSNS = Server provides=20 the ability to distribute security policies.
2) The size of an iSNS Client may = vary. =20 However, the code to query the iSNS
server for a boot-list enabled DD based = on an iSCSI=20 name is not very
complex. =20 Most of the complexity in iSNSP is on the server side. =
3) SLPv2 and multicast are other = alternative=20 methods to DHCP to find the
iSNS=20 server.  Additionally, SLPv2 is an alternative to iSNS for = locating=20 the
target to boot from, = which is=20 already described in iSCSI-boot. 

SPECIAL NOTICE=20

All information transmitted hereby is intended only for the use of the=20
addressee(s) named  above and may contain confidential and privileged=20
information. Any unauthorized  review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader =
of
this message is not the intended recipient(s) or the employee or agent=20
responsible for delivering the message to the intended recipient, you
are herby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY=20
PROHIBITED.

Anyone who receives confidential and privileged information in error =
should=20
notify us immediately by telephone and mail the original message to us =
at the
above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions=20
apply to that information. (gate01)
<= /HTML> =00 ------_=_NextPart_001_01C3A283.CE7F0E06-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Nov 5 13:13:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15574 for ; Wed, 5 Nov 2003 13:13:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHS9i-0001lT-Lc for ips-archive@odin.ietf.org; Wed, 05 Nov 2003 13:13:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5IDMAJ006779 for ips-archive@odin.ietf.org; Wed, 5 Nov 2003 13:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHS9i-0001lG-Fo for ips-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 13:13:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15569 for ; Wed, 5 Nov 2003 13:13:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHS9b-00008y-00 for ips-web-archive@ietf.org; Wed, 05 Nov 2003 13:13:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHS9b-00008r-00 for ips-web-archive@ietf.org; Wed, 05 Nov 2003 13:13:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHS9N-0001k0-OD; Wed, 05 Nov 2003 13:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHS8l-0001jh-Qk for ips@optimus.ietf.org; Wed, 05 Nov 2003 13:12:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15527 for ; Wed, 5 Nov 2003 13:12:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHS8j-00008L-00 for ips@ietf.org; Wed, 05 Nov 2003 13:12:21 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AHS8j-00007j-00 for ips@ietf.org; Wed, 05 Nov 2003 13:12:21 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Nov 2003 10:11:50 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 5 Nov 2003 10:11:50 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 05 Nov 2003 10:11:41 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Nov 2003 10:11:46 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 5 Nov 2003 10:10:50 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 5 Nov 2003 10:11:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [Ips] RE: iSNS boot information Date: Wed, 5 Nov 2003 10:11:47 -0800 Message-ID: Thread-Topic: [Ips] RE: iSNS boot information thread-index: AcOgh8eaL3f6U/XZQUeycWDsFqg1iABJ3yWgAClpc9AAXL5yEA== From: "Alan Warwick" To: , Cc: , "Joe Souza" , "Suzanne Morgan" X-OriginalArrivalTime: 05 Nov 2003 18:11:23.0911 (UTC) FILETIME=[38DA1970:01C3A3C8] Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A3C8.462196C8" ------_=_NextPart_001_01C3A3C8.462196C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Josh, =20 The Microsoft iSCSI initiator only supports boot by using an iSCSI HBA card that has int 13 extensions. Booting from the software initiator is not supported. However given an iSCSI HBA card that supports these drafts there is no reason why this would not work. =20 =20 Alan Warwick Microsoft ________________________________ From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of jvillago@jw.org Sent: Monday, November 03, 2003 2:15 PM To: kevin.gibbons@mcdata.com Cc: ips@ietf.org Subject: [Ips] RE: iSNS boot information =20 Kevin, =20 Thank you very much! After reading Section 6.11.2.9, I'm assuming what we're trying to do should work. Our scenario is as follows: =20 Boot Windows XP w/ Microsoft's iSCSI driver MS iSNS Server =20 We want our PC's to receive it's DCHP address along with first boot LUN from iSNS in order to boot MS XP directly from it. Is this possible with the current implementations addressed below? =20 =20 Josh =20 -----Original Message----- From: Kevin Gibbons [mailto:kevin.gibbons@mcdata.com]=20 Sent: Sunday, November 02, 2003 9:19 PM To: Villagomez, Joshua Cc: ips@ietf.org Subject: RE: iSNS boot information Josh, the latest drafts of the documents referenced would be: 1) Using DHCP to discover the iSNS =09 http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-10.txt =20 2) Using the Discovery Domain boot list option =09 http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-21.txt please see Section 6.11.2.9, Discovery Domain Features. =20 Please let me know if you have any questions. Regards, Kevin =09 =20 -----Original Message----- From: jvillago@jw.org [mailto:jvillago@jw.org]=20 Sent: Saturday, November 01, 2003 6:53 AM To: Kevin Gibbons Cc: ips@ece.cmu.edu Subject: iSNS boot information Hi Kevin,=20 I found the following post to be very interesting. We're trying to boot an iSCSI initiator using iSNS. Where is the document referenced below? The link no longer works. Any other information you may have would be quite useful. Thanks. Josh=20 =09 ------------------------------------------------------------------------ --------=20 To: ips@ece.cmu.edu=20 Subject: iSCSI Boot: use of iSNS=20 From: Kevin Gibbons =20 Date: Wed, 19 Mar 2003 10:48:33 -0800=20 Content-Type: text/plain=20 Sender: owner-ips@ece.cmu.edu=20 =09 ------------------------------------------------------------------------ --------=20 At the IPS WG session at IETF 56, we discussed the iSCSI Boot draft. It=20 involved how to find the iSCSI target to boot from, as well as security=20 issues for the process. The following is a process using DHCP and iSNS to=20 find the appropriate iSCSI target to use for boot:=20 1) use DHCP to find the iSNS Server. Please see:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-05.txt=20 2) query the iSNS server to find the Discovery Domain Feature "Boot List=20 Enabled" for the specified iSCSI node or entity. Please see:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-18.txt=20 ---=20 6.10.2.9 Discovery Domain Features=20 The Discovery Domain Features is a bitmap indicating the features of=20 this DD. The bit positions are defined below. A bit set to 1=20 indicates the DD has the corresponding characteristics.=20 Bit Position DD Feature=20 ------------ ----------=20 31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)=20 All Others RESERVED=20 =20 Boot List: this feature indicates that the targets in this DD provide=20 boot capabilities for the member initiators, as described in [iSCSI-=20 boot].=20 ---=20 Couple items:=20 1) The iSNS Server provides the ability to distribute security policies.=20 2) The size of an iSNS Client may vary. However, the code to query the iSNS=20 server for a boot-list enabled DD based on an iSCSI name is not very=20 complex. Most of the complexity in iSNSP is on the server side.=20 3) SLPv2 and multicast are other alternative methods to DHCP to find the=20 iSNS server. Additionally, SLPv2 is an alternative to iSNS for locating the=20 target to boot from, which is already described in iSCSI-boot.=20 SPECIAL NOTICE=20 =20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent=20 responsible for delivering the message to the intended recipient, you are herby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY=20 PROHIBITED. =20 Anyone who receives confidential and privileged information in error should=20 notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions=20 apply to that information. (gate01) =20 ------_=_NextPart_001_01C3A3C8.462196C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Josh,

=

 

The Microsoft iSCSI initiator = only supports boot by using an iSCSI HBA card that has int 13 extensions. Booting from = the software initiator is not supported.  However given an iSCSI HBA = card that supports these drafts there is no reason why this would not = work.

 

 

Alan = Warwick

Microsoft=

From: = ips-admin@ietf.org [mailto:ips-admin@ietf.org] On = Behalf Of jvillago@jw.org
Sent: Monday, November 03, = 2003 2:15 PM
To: = kevin.gibbons@mcdata.com
Cc: ips@ietf.org
Subject: [Ips] RE: iSNS = boot information

 

Kevin,

 

Thank you very much! After reading Section 6.11.2.9, I'm = assuming what we're trying to do should work. Our scenario is as = follows:

 

Boot Windows XP w/ Microsoft's iSCSI = driver

MS iSNS Server

 

We want our PC's to receive it's DCHP address along with first = boot LUN from iSNS in order to boot MS XP directly from it. Is this possible with = the current implementations addressed below?

 

 

Josh

 


-----Original Message-----
From: Kevin Gibbons [mailto:kevin.gibbons@mcdata.com]
Sent: Sunday, November 02, = 2003 9:19 PM
To: Villagomez, = Joshua
Cc: ips@ietf.org
Subject: RE: iSNS boot = information

Josh,

    the latest = drafts of the documents referenced would be:

1) Using DHCP to discover the = iSNS

 

2) Using the Discovery Domain boot = list option

    h= ttp://www.ietf.org/internet-drafts/draft-ietf-ips-isns-21.txt pl= ease see Section 6.11.2.9, Discovery Domain = Features.

 

Please let me know if you have any questions.

    Regards, = Kevin


 

-----Original = Message-----
From: jvillago@jw.org [mailto:jvillago@jw.org]
Sent: Saturday, November = 01, 2003 6:53 AM
To: Kevin Gibbons
Cc: ips@ece.cmu.edu
Subject: iSNS boot = information

Hi Kevin,

I found the following post to be very interesting. We're trying to boot an iSCSI initiator using iSNS. Where is the document referenced below? The link = no longer works. Any other information you may have would be quite useful. = Thanks.

Josh

----------------------------------------------= ----------------------------------

To: ips@ece.cmu.edu
Subject: iSCSI Boot: use of iSNS
From: Kevin Gibbons <kgibbons@NishanSystems.com>
Date: Wed, 19 Mar 2003 10:48:33 -0800
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu

----------------------------------------------= ----------------------------------

At the IPS WG session at IETF 56, we discussed = the iSCSI Boot draft.  It
involved how to find the iSCSI target to boot from, as well as security =
issues for the process.  The following is a process using DHCP and = iSNS to
find the appropriate iSCSI target to use for boot:
1) use DHCP to find the iSNS Server.  Please see:
        http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-05.txt=

2) query the iSNS server to find the Discovery Domain Feature "Boot List =
Enabled" for the specified iSCSI node or entity.  Please see: =
        h= ttp://www.ietf.org/internet-drafts/draft-ietf-ips-isns-18.txt
---
6.10.2.9 Discovery Domain Features
   The Discovery Domain Features is a bitmap indicating the = features of
   this DD.  The bit positions are defined below.  A = bit set to 1
   indicates the DD has the corresponding characteristics. =

       Bit Position     DD Feature
       = ------------     ----------
          31 (Lsb)      Boot List Enabled (1)/Boot List = Disabled (0)
        All Others      RESERVED
   
   Boot List: this feature indicates that the targets in this = DD provide
   boot capabilities for the member initiators, as described = in [iSCSI-
   boot].
---
Couple items:
1) The iSNS Server provides the ability to distribute security policies. =
2) The size of an iSNS Client may vary.  However, the code to query = the iSNS
server for a boot-list enabled DD based on an iSCSI name is not very =
complex.  Most of the complexity in iSNSP is on the server side. =
3) SLPv2 and multicast are other alternative methods to DHCP to find the =
iSNS server.  Additionally, SLPv2 is an alternative to iSNS for = locating the
target to boot from, which is already described in iSCSI-boot. = 

SPECIAL NOTICE 
 
All information transmitted hereby is intended only for =
the use of the 
addressee(s) named  above and may contain =
confidential and privileged 
information. Any unauthorized  review, use, =
disclosure or distribution
of confidential and privileged information is prohibited. =
If the reader of
this message is not the intended recipient(s) or the =
employee or agent 
responsible for delivering the message to the intended =
recipient, you
are herby notified that you must not read this =
transmission and that
disclosure, copying, printing, distribution or use of any =
of the
information contained in or attached to this transmission =
is STRICTLY 
PROHIBITED.
 
Anyone who receives confidential and privileged =
information in error should 
notify us immediately by telephone and mail the original =
message to us at the
above address and destroy all copies.  To the extent =
any portion of this
communication contains public information, no such =
restrictions 
apply to that information. =
(gate01)

 

------_=_NextPart_001_01C3A3C8.462196C8-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Nov 5 17:47:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28086 for ; Wed, 5 Nov 2003 17:47:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWQg-0003zQ-D3 for ips-archive@odin.ietf.org; Wed, 05 Nov 2003 17:47:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5MlAmk015336 for ips-archive@odin.ietf.org; Wed, 5 Nov 2003 17:47:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWQg-0003zH-8j for ips-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 17:47:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28032 for ; Wed, 5 Nov 2003 17:46:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWQd-00054Y-00 for ips-web-archive@ietf.org; Wed, 05 Nov 2003 17:47:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHWQd-00054V-00 for ips-web-archive@ietf.org; Wed, 05 Nov 2003 17:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWQY-0003tn-HE; Wed, 05 Nov 2003 17:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWQD-0003sO-Km for ips@optimus.ietf.org; Wed, 05 Nov 2003 17:46:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28009; Wed, 5 Nov 2003 17:46:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWQA-00053w-00; Wed, 05 Nov 2003 17:46:38 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx with esmtp (Exim 4.12) id 1AHWQA-00053t-00; Wed, 05 Nov 2003 17:46:38 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel8.hp.com (Postfix) with ESMTP id 1B4851C02BCE; Wed, 5 Nov 2003 17:46:38 -0500 (EST) Received: from swathi.rose.hp.com (dhcp-roseor-bdi217.rose.hp.com [15.23.138.217]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id OAA00614; Wed, 5 Nov 2003 14:46:36 -0800 (PST) Message-Id: <6.0.0.22.1.20031105142251.02a97c90@rosemail.rose.hp.com> X-Sender: cbm@rosemail.rose.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 05 Nov 2003 14:46:31 -0800 To: Black_David@emc.com, ips@ietf.org, rddp@ietf.org From: "Mallikarjun C." Subject: Re: [Ips] iSCSI over RDMA (iSER and DA) Internet Drafts Cc: nfsv4@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Thanks David. >and solicit interest in working on them (e.g., >organize an informal meeting [aka "bar BOF"] to discuss >further). Sorry for the cross-post, but I'd like to hear in short order (< 24 hours) from all those who can attend an informal iSER/DA discussion/presentation *if one is organized* along the lines of what David suggested. I know it's perhaps too late for such a poll, but if enough folks respond within a day, some of us would like to take the time to present, educate and be educated. Please send me a short email *offline* if you can attend. All the folks on this distribution are welcome. If I see enough responses, I will send an annoucement with logistics by 11/6 evening PT. In the absence of such a separate discussion, of course, the 5 minute agenda time in the RDDP meeting will be the only discussion time as a group on iSER/DA (excluding the hallway conversations). Thanks. Mallikarjun At 11:01 AM 10/24/2003, Black_David@emc.com wrote: >On the IPS list, Mallikarjun asked: > > > Could you please recommend the most optimal course > > of action to request and enhance the WG charter? > >IETF being IETF, the world of "rough consensus and >running code", I have no idea what "the most optimal >course of action" would be, or whether it even exists :-). > >The scope of an IETF WG's activities and the items on >which it works are managed by the Area Directors and >the IESG via the WG's charter, among other means. My >understanding of the Transport ADs' views is that the >IP Storage WG has been very successful in what the WG >set out to do, and the time has come to finish up the >current work, declare victory and move on (with the WG >either going dormant or being concluded). Of course the >ADs always reserve the right to change their minds based >on new information, etc., and my understanding may be >less than perfect. > >The people advocating addition of work on iSCSI over RDMA >seem to be spending a lot of energy on where the work should >be done (process) and much less on whether and why it should >be done (technical merits). In my experience, these two topics >are best pursued in the opposite order. Specifically, the first >decision (ADs and IESG as appropriate) should be whether the >work is to be done and with what scope; if that is decided >in the affirmative, then matters of where and how can then >be worked out in a reasonable fashion. > >Given this, I do have some advice to offer: >(1) A promising path towards undertaking iSCSI over RDMA work > in the IETF involves a BOF, e.g., in Seoul. Those > interested in such a BOF should approach the Transport > Area Directors about organizing and holding one (but > first read the material on BOFs in RFC 2418). By the > time of the Seoul meeting week, the rddp WG should be > done or close to done with most of the drafts on which > iSCSI over RDMA depends, providing a firmer foundation > for the proposed work. >- One of the things that inclines ADs and the IESG towards > approval of work is the existence of an open community of > people interested in the work, the broader the better. > IETF meeting weeks are a good opportunity to solicit > interest in possible work towards forming/broadening such > a community (e.g., hallway discussion). In furtherance > of this, in my role as RDDP WG chair I have already promised > the iSER/DA draft authors a 5 minute slot in the RDDP WG > meeting in Minneapolis to briefly describe what the drafts > are about and solicit interest in working on them (e.g., > organize an informal meeting [aka "bar BOF"] to discuss > further). > >For those who are new to this topic, the iSER and DA drafts >on the topic of iSCSI over RDMA are: > >http://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt >http://www.ietf.org/internet-drafts/draft-chadalapaka-iwarp-da-00.txt > >Thanks, >--David (IPS WG co-chair, 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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 6 20:26:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11495 for ; Thu, 6 Nov 2003 20:26:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvNq-0003BJ-6L for ips-archive@odin.ietf.org; Thu, 06 Nov 2003 20:25:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA71Ps6g012226 for ips-archive@odin.ietf.org; Thu, 6 Nov 2003 20:25:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvNp-0003B7-W7 for ips-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 20:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11492 for ; Thu, 6 Nov 2003 20:25:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvNn-00046K-00 for ips-web-archive@ietf.org; Thu, 06 Nov 2003 20:25:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHvNn-00046G-00 for ips-web-archive@ietf.org; Thu, 06 Nov 2003 20:25:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvN0-000370-A8; Thu, 06 Nov 2003 20:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvMv-00036Y-Vn for ips@optimus.ietf.org; Thu, 06 Nov 2003 20:24:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11460 for ; Thu, 6 Nov 2003 20:24:46 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvMt-00045k-00 for ips@ietf.org; Thu, 06 Nov 2003 20:24:55 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AHvMt-00045h-00 for ips@ietf.org; Thu, 06 Nov 2003 20:24:55 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id AE8BA40136; Thu, 6 Nov 2003 20:24:55 -0500 (EST) Date: Thu, 6 Nov 2003 16:21:41 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: ips@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ips] Handling error during packet transmission Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Ok, here's an error that I admit is a bit extreme. What do you (a target or initiator) do if you have sent the header for a PDU and then realize, say due to ECC memory error detection, that you can't send the rest of the PDU? Say the target is servicing a SCSI READ command. It sets up a PDU for transmission. Assume we're on a link where we aren't sending jumbo grams and the PDU will mean multiple ethernet frames. Now say that there is a (detected) data corruption event during the transmission of the PDU. Like a double bit error on ECC system memory for instance. The point is the PDU header has gone out but we don't have all the data. And assume that when we go to try and recover the data, we find out we can't easily get it (it wasn't say a PCI transfer error that re-running the transfer will recover). We decide we don't want to stall the TCP connection getting it. What do we do? If we had data digests, one option would be to fill the rest of the PDU with nonsense (zeros?), and deliberately send a bad digest. If we didn't have digests, would it be reasonable to send garbage (zeros?) to fill the PDU, then abort the command with a CHECK CONDITION and indicate an underrun that didn't include the unsent PDU data? As an example, we successfully send 8K of data, then we are sending a DATA-IN PDU with 8k, and run into the error after 4k. We abort the command, and indicate that only 12k of data were sent. ? Yes, this shouldn't happen, but what do you do if it does? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 6 21:35:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13465 for ; Thu, 6 Nov 2003 21:35:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwSz-0006Bk-BB for ips-archive@odin.ietf.org; Thu, 06 Nov 2003 21:35:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA72ZHCc023788 for ips-archive@odin.ietf.org; Thu, 6 Nov 2003 21:35:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwSy-0006BV-W7 for ips-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 21:35:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13456 for ; Thu, 6 Nov 2003 21:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHwSw-0004yH-00 for ips-web-archive@ietf.org; Thu, 06 Nov 2003 21:35:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHwSv-0004yE-00 for ips-web-archive@ietf.org; Thu, 06 Nov 2003 21:35:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwSk-000691-JZ; Thu, 06 Nov 2003 21:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwDt-0005bo-Dj for ips@optimus.ietf.org; Thu, 06 Nov 2003 21:19:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13024 for ; Thu, 6 Nov 2003 21:19:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHwDq-0004lc-00 for ips@ietf.org; Thu, 06 Nov 2003 21:19:38 -0500 Received: from [66.155.203.134] (helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1AHwDq-0004l5-00 for ips@ietf.org; Thu, 06 Nov 2003 21:19:38 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hA72J3pU025192 for ; Thu, 6 Nov 2003 21:19:03 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hA72J2g6025187; Thu, 6 Nov 2003 21:19:02 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id hA72J0708801; Thu, 6 Nov 2003 21:19:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16299.276.966000.678905@gargle.gargle.HOWL> Date: Thu, 6 Nov 2003 21:19:00 -0500 From: Paul Koning To: wrstuden@wasabisystems.com Cc: ips@ietf.org Subject: Re: [Ips] Handling error during packet transmission References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "wrstuden" == wrstuden writes: wrstuden> Ok, here's an error that I admit is a bit extreme. What do wrstuden> you (a target or initiator) do if you have sent the header wrstuden> for a PDU and then realize, say due to ECC memory error wrstuden> detection, that you can't send the rest of the PDU? wrstuden> ... wrstuden> What do we do? wrstuden> If we had data digests, one option would be to fill the wrstuden> rest of the PDU with nonsense (zeros?), and deliberately wrstuden> send a bad digest. Agreed. wrstuden> If we didn't have digests, would it be reasonable to send wrstuden> garbage (zeros?) to fill the PDU, then abort the command wrstuden> with a CHECK CONDITION and indicate an underrun that didn't wrstuden> include the unsent PDU data? I don't like that; the garbage you sent might be delivered to user buffers and mistaken for real data. Better just to abort the connection. This sort of thing should be extremely rare; there is no need to make recovery from it efficient. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 6 21:41:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13704 for ; Thu, 6 Nov 2003 21:41:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwYe-000738-S7 for ips-archive@odin.ietf.org; Thu, 06 Nov 2003 21:41:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA72f8fq027092 for ips-archive@odin.ietf.org; Thu, 6 Nov 2003 21:41:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwYe-00070f-MS for ips-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 21:41:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13652 for ; Thu, 6 Nov 2003 21:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHwYb-00052z-00 for ips-web-archive@ietf.org; Thu, 06 Nov 2003 21:41:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHwYb-00052w-00 for ips-web-archive@ietf.org; Thu, 06 Nov 2003 21:41:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwYY-0006wI-2V; Thu, 06 Nov 2003 21:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwYW-0006vv-55 for ips@optimus.ietf.org; Thu, 06 Nov 2003 21:41:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13649 for ; Thu, 6 Nov 2003 21:40:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHwYT-00052r-00 for ips@ietf.org; Thu, 06 Nov 2003 21:40:57 -0500 Received: from astound-64-85-224-253.ca.astound.net ([64.85.224.253] helo=master.linux-ide.org) by ietf-mx with esmtp (Exim 4.12) id 1AHwYS-00052o-00 for ips@ietf.org; Thu, 06 Nov 2003 21:40:56 -0500 Received: from localhost (andre@localhost) by master.linux-ide.org (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id hA72dG004264; Thu, 6 Nov 2003 18:39:16 -0800 Date: Thu, 6 Nov 2003 18:39:16 -0800 (PST) From: Andre Hedrick To: Paul Koning cc: wrstuden@wasabisystems.com, ips@ietf.org Subject: Re: [Ips] Handling error during packet transmission In-Reply-To: <16299.276.966000.678905@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Paul and Bill, I agree w/ Paul that loading the PDU with garbage is a bad idea. One may not be able to tell the difference between a crypto fs on top. If junk is going to be sent, logic dictates a defined pattern is to be adopted. Then the question comes, what is the granularity of the pattern? Comments? Andre Hedrick LAD Storage Consulting Group On Thu, 6 Nov 2003, Paul Koning wrote: > >>>>> "wrstuden" == wrstuden writes: > > wrstuden> Ok, here's an error that I admit is a bit extreme. What do > wrstuden> you (a target or initiator) do if you have sent the header > wrstuden> for a PDU and then realize, say due to ECC memory error > wrstuden> detection, that you can't send the rest of the PDU? > wrstuden> ... > wrstuden> What do we do? > > wrstuden> If we had data digests, one option would be to fill the > wrstuden> rest of the PDU with nonsense (zeros?), and deliberately > wrstuden> send a bad digest. > > Agreed. > > wrstuden> If we didn't have digests, would it be reasonable to send > wrstuden> garbage (zeros?) to fill the PDU, then abort the command > wrstuden> with a CHECK CONDITION and indicate an underrun that didn't > wrstuden> include the unsent PDU data? > > I don't like that; the garbage you sent might be delivered to user > buffers and mistaken for real data. > > Better just to abort the connection. This sort of thing should be > extremely rare; there is no need to make recovery from it efficient. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 6 21:57:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13956 for ; Thu, 6 Nov 2003 21:57:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwo9-0007Qr-5N for ips-archive@odin.ietf.org; Thu, 06 Nov 2003 21:57:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA72v9it028563 for ips-archive@odin.ietf.org; Thu, 6 Nov 2003 21:57:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwo8-0007Pa-VO for ips-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 21:57:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13946 for ; Thu, 6 Nov 2003 21:56:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHwo5-0005DB-00 for ips-web-archive@ietf.org; Thu, 06 Nov 2003 21:57:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHwo5-0005D8-00 for ips-web-archive@ietf.org; Thu, 06 Nov 2003 21:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwo1-0007NG-Jd; Thu, 06 Nov 2003 21:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHwna-0007Mq-AC for ips@optimus.ietf.org; Thu, 06 Nov 2003 21:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13943 for ; Thu, 6 Nov 2003 21:56:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHwnX-0005D3-00 for ips@ietf.org; Thu, 06 Nov 2003 21:56:31 -0500 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1AHwnW-0005D0-00 for ips@ietf.org; Thu, 06 Nov 2003 21:56:30 -0500 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 536F4244F04 for ; Thu, 6 Nov 2003 21:56:39 -0500 (EST) Date: Thu, 6 Nov 2003 20:56:00 -0600 Subject: Re: [Ips] Handling error during packet transmission Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Caitlin Bestler To: ips@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <16299.276.966000.678905@gargle.gargle.HOWL> Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, November 6, 2003, at 08:19 PM, Paul Koning wrote: > wrstuden> If we had data digests, one option would be to fill the > wrstuden> rest of the PDU with nonsense (zeros?), and deliberately > wrstuden> send a bad digest. > > Agreed. > > wrstuden> If we didn't have digests, would it be reasonable to send > wrstuden> garbage (zeros?) to fill the PDU, then abort the command > wrstuden> with a CHECK CONDITION and indicate an underrun that didn't > wrstuden> include the unsent PDU data? > > I don't like that; the garbage you sent might be delivered to user > buffers and mistaken for real data. > > Better just to abort the connection. This sort of thing should be > extremely rare; there is no need to make recovery from it efficient. Why not simply send bad TCP frames? In other words, send a bad digest down one layer. It's better than aborting the connection. Admittedly, you are jumping a few layers. But if you can detect a data error mid packet I would suspect that the implementation is already just a little bit rototilled. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 00:58:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18194 for ; Fri, 7 Nov 2003 00:58:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzdH-0005yx-GH for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 00:58:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA75w7lg022994 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 00:58:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzdH-0005yn-CQ for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 00:58:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18191 for ; Fri, 7 Nov 2003 00:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHzdE-00076I-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 00:58:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHzdE-00076F-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 00:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzdC-0005xm-5h; Fri, 07 Nov 2003 00:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzd9-0005xH-Sr for ips@optimus.ietf.org; Fri, 07 Nov 2003 00:57:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18188; Fri, 7 Nov 2003 00:57:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHzd6-00076A-00; Fri, 07 Nov 2003 00:57:56 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1AHzd5-000763-00; Fri, 07 Nov 2003 00:57:56 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA75vExm067688; Fri, 7 Nov 2003 05:57:14 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA75vDmm228372; Fri, 7 Nov 2003 06:57:14 +0100 In-Reply-To: To: Caitlin Bestler Cc: ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] Handling error during packet transmission MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Julian Satran Message-ID: Date: Fri, 7 Nov 2003 07:57:00 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/11/2003 07:57:14, Serialize complete at 07/11/2003 07:57:14 Content-Type: multipart/alternative; boundary="=_alternative 00209CA8C2256DD7_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00209CA8C2256DD7_= Content-Type: text/plain; charset="US-ASCII" Bill, You have now more advise that you would have cared for. Aborting TCP packets (since they are not replaced) won't get you very far. We have decided early on that the underlying transport is reliable and (as TCP does) we did not provide for an abort. For some streaming operations that might have been a mistake. Regards, Julo Caitlin Bestler Sent by: ips-admin@ietf.org 07/11/2003 04:56 To ips@ietf.org cc Subject Re: [Ips] Handling error during packet transmission On Thursday, November 6, 2003, at 08:19 PM, Paul Koning wrote: > wrstuden> If we had data digests, one option would be to fill the > wrstuden> rest of the PDU with nonsense (zeros?), and deliberately > wrstuden> send a bad digest. > > Agreed. > > wrstuden> If we didn't have digests, would it be reasonable to send > wrstuden> garbage (zeros?) to fill the PDU, then abort the command > wrstuden> with a CHECK CONDITION and indicate an underrun that didn't > wrstuden> include the unsent PDU data? > > I don't like that; the garbage you sent might be delivered to user > buffers and mistaken for real data. > > Better just to abort the connection. This sort of thing should be > extremely rare; there is no need to make recovery from it efficient. Why not simply send bad TCP frames? In other words, send a bad digest down one layer. It's better than aborting the connection. Admittedly, you are jumping a few layers. But if you can detect a data error mid packet I would suspect that the implementation is already just a little bit rototilled. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00209CA8C2256DD7_= Content-Type: text/html; charset="US-ASCII"
Bill,

You have now more advise that you would have cared for. Aborting TCP packets (since they are not replaced) won't get you very far.
We have decided early on that the underlying transport is reliable and (as TCP does) we did not provide for an abort.
For some streaming operations that might have been a mistake.

Regards,
Julo


Caitlin Bestler <cait@asomi.com>
Sent by: ips-admin@ietf.org

07/11/2003 04:56

To
ips@ietf.org
cc
Subject
Re: [Ips] Handling error during packet transmission






On Thursday, November 6, 2003, at 08:19 PM, Paul Koning wrote:

>  wrstuden> If we had data digests, one option would be to fill the
>  wrstuden> rest of the PDU with nonsense (zeros?), and deliberately
>  wrstuden> send a bad digest.
>
> Agreed.
>
>  wrstuden> If we didn't have digests, would it be reasonable to send
>  wrstuden> garbage (zeros?)  to fill the PDU, then abort the command
>  wrstuden> with a CHECK CONDITION and indicate an underrun that didn't
>  wrstuden> include the unsent PDU data?
>
> I don't like that; the garbage you sent might be delivered to user
> buffers and mistaken for real data.
>
> Better just to abort the connection.  This sort of thing should be
> extremely rare; there is no need to make recovery from it efficient.

Why not simply send bad TCP frames? In other words, send a bad digest
down one layer. It's better than aborting the connection.

Admittedly, you are jumping a few layers. But if you can detect a
data error mid packet I would suspect that the implementation is
already just a little bit rototilled.


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00209CA8C2256DD7_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 05:48:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09586 for ; Fri, 7 Nov 2003 05:48:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI4A2-0007le-Uq for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 05:48:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7AmE9j029854 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 05:48:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI4A2-0007lR-QL for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 05:48:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09576 for ; Fri, 7 Nov 2003 05:48:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI49z-0002r4-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 05:48:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI49y-0002r1-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 05:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI49p-0007jF-3b; Fri, 07 Nov 2003 05:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI49e-0007j2-1W for ips@optimus.ietf.org; Fri, 07 Nov 2003 05:47:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09571 for ; Fri, 7 Nov 2003 05:47:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI49a-0002qw-00 for ips@ietf.org; Fri, 07 Nov 2003 05:47:46 -0500 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx with esmtp (Exim 4.12) id 1AI49Z-0002ql-00 for ips@ietf.org; Fri, 07 Nov 2003 05:47:45 -0500 Received: from RLTEMPLE (vpn10-95-10-3.wrsec.fr [10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id CAA03798 for ; Fri, 7 Nov 2003 02:47:05 -0800 (PST) From: "Rod Harrison" To: Subject: RE: [Ips] Handling error during packet transmission Date: Fri, 7 Nov 2003 10:47:14 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Paul, this is rare enough to employ the big hammer. Tear the connection down with an RST segment and let the initiator recover. I wouldn't even bother adding logic to send a bad digest if they are in use, doesn't happen often enough. - Rod -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of Julian Satran Sent: Friday, November 07, 2003 5:57 AM To: Caitlin Bestler Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] Handling error during packet transmission Bill, You have now more advise that you would have cared for. Aborting TCP packets (since they are not replaced) won't get you very far. We have decided early on that the underlying transport is reliable and (as TCP does) we did not provide for an abort. For some streaming operations that might have been a mistake. Regards, Julo Caitlin Bestler Sent by: ips-admin@ietf.org 07/11/2003 04:56 Toips@ietf.org cc SubjectRe: [Ips] Handling error during packet transmission On Thursday, November 6, 2003, at 08:19 PM, Paul Koning wrote: > wrstuden> If we had data digests, one option would be to fill the > wrstuden> rest of the PDU with nonsense (zeros?), and deliberately > wrstuden> send a bad digest. > > Agreed. > > wrstuden> If we didn't have digests, would it be reasonable to send > wrstuden> garbage (zeros?) to fill the PDU, then abort the command > wrstuden> with a CHECK CONDITION and indicate an underrun that didn't > wrstuden> include the unsent PDU data? > > I don't like that; the garbage you sent might be delivered to user > buffers and mistaken for real data. > > Better just to abort the connection. This sort of thing should be > extremely rare; there is no need to make recovery from it efficient. Why not simply send bad TCP frames? In other words, send a bad digest down one layer. It's better than aborting the connection. Admittedly, you are jumping a few layers. But if you can detect a data error mid packet I would suspect that the implementation is already just a little bit rototilled. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 10:04:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16768 for ; Fri, 7 Nov 2003 10:04:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI89j-0001tX-3z for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 10:04:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7F4BRm007279 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 10:04:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI89j-0001tK-02 for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 10:04:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16700 for ; Fri, 7 Nov 2003 10:03:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI89g-00067Q-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 10:04:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI89g-00067K-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 10:04:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI89Z-0001oY-TT; Fri, 07 Nov 2003 10:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI85g-0001bh-SJ for ips@optimus.ietf.org; Fri, 07 Nov 2003 10:00:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16487 for ; Fri, 7 Nov 2003 09:59:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI85e-00063V-00 for ips@ietf.org; Fri, 07 Nov 2003 09:59:58 -0500 Received: from [66.155.203.134] (helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1AI85e-00063N-00 for ips@ietf.org; Fri, 07 Nov 2003 09:59:58 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hA7ExRpW031352 for ; Fri, 7 Nov 2003 09:59:27 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hA7ExRg6031347; Fri, 7 Nov 2003 09:59:27 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id hA7ExQ832725; Fri, 7 Nov 2003 09:59:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16299.45902.440113.623321@gargle.gargle.HOWL> Date: Fri, 7 Nov 2003 09:59:26 -0500 From: Paul Koning To: cait@asomi.com Cc: ips@ietf.org Subject: Re: [Ips] Handling error during packet transmission References: <16299.276.966000.678905@gargle.gargle.HOWL> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Caitlin" == Caitlin Bestler writes: Caitlin> On Thursday, November 6, 2003, at 08:19 PM, Paul Koning Caitlin> wrote: wrstuden> If we had data digests, one option would be to fill the wrstuden> rest of the PDU with nonsense (zeros?), and deliberately wrstuden> send a bad digest. >> Agreed. >> wrstuden> If we didn't have digests, would it be reasonable to send wrstuden> garbage (zeros?) to fill the PDU, then abort the command wrstuden> with a CHECK CONDITION and indicate an underrun that didn't wrstuden> include the unsent PDU data? >> I don't like that; the garbage you sent might be delivered to user >> buffers and mistaken for real data. >> >> Better just to abort the connection. This sort of thing should be >> extremely rare; there is no need to make recovery from it >> efficient. Caitlin> Why not simply send bad TCP frames? In other words, send a Caitlin> bad digest down one layer. It's better than aborting the Caitlin> connection. That will not work at all. If you send a TCP packet with a bad TCP checksum, it will be discarded by the receiver, which doesn't ACK it and doesn't accept subsequent packets (because they are out of order). The sender would normally retransmit such dropped packets. If the packet has a forced back checksum, then the connection cannot make progress. In other words, the effect is identical to dropping the connection right away, except far more clumsily and less reliably. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 10:04:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16798 for ; Fri, 7 Nov 2003 10:04:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI89q-0001u3-R1 for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 10:04:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7F4IOd007309 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 10:04:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI89q-0001to-IS for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 10:04:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16708 for ; Fri, 7 Nov 2003 10:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI89g-00067O-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 10:04:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI89g-00067J-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 10:04:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI89Z-0001oO-8r; Fri, 07 Nov 2003 10:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzuf-0006zj-SL for ips@optimus.ietf.org; Fri, 07 Nov 2003 01:16:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18527 for ; Fri, 7 Nov 2003 01:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHzuc-0007Gy-00 for ips@ietf.org; Fri, 07 Nov 2003 01:16:02 -0500 Received: from yeah-baby.shagadelic.org ([208.176.2.162]) by ietf-mx with esmtp (Exim 4.12) id 1AHzuc-0007Gj-00 for ips@ietf.org; Fri, 07 Nov 2003 01:16:02 -0500 Received: from wasabisystems.com (localhost [127.0.0.1]) by yeah-baby.shagadelic.org (Postfix) with ESMTP id DD2C31E081A; Thu, 6 Nov 2003 22:15:38 -0800 (PST) Date: Thu, 6 Nov 2003 22:15:41 -0800 Subject: Re: [Ips] Handling error during packet transmission Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ips@ietf.org To: Caitlin Bestler From: Jason Thorpe In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, November 6, 2003, at 06:56 PM, Caitlin Bestler wrote: > Why not simply send bad TCP frames? In other words, send a bad digest > down one layer. It's better than aborting the connection. I don't see how that helps. If you send a bad TCP packet, the iSCSI application layer won't see that. The problem is that you have to somehow notify the peer iSCSI application. I think Paul's suggestion of just shooting the connection in the head is a reasonable one. > Admittedly, you are jumping a few layers. But if you can detect a > data error mid packet I would suspect that the implementation is > already just a little bit rototilled. It's easier to detect an error mid-packet than you might think. A trap occurs, the thread that caused the trap is identified, and a notification is sent to that thread that something bad happened. Most operating systems I'm familiar with have had this capability for quite some time. -- Jason R. Thorpe _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 11:03:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20144 for ; Fri, 7 Nov 2003 11:03:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI94m-00052I-LW for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 11:03:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7G38wq019357 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 11:03:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI94m-000528-Gj for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 11:03:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20100 for ; Fri, 7 Nov 2003 11:02:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI94j-0006pa-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 11:03:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI94j-0006pX-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 11:03:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI94g-0004zk-PX; Fri, 07 Nov 2003 11:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI942-0004wi-O4 for ips@optimus.ietf.org; Fri, 07 Nov 2003 11:02:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20087 for ; Fri, 7 Nov 2003 11:02:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI93z-0006pK-00 for ips@ietf.org; Fri, 07 Nov 2003 11:02:19 -0500 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1AI93z-0006ob-00 for ips@ietf.org; Fri, 07 Nov 2003 11:02:19 -0500 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 6BE86244AB4; Fri, 7 Nov 2003 11:02:26 -0500 (EST) Date: Fri, 7 Nov 2003 10:01:56 -0600 Subject: Re: [Ips] Handling error during packet transmission Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ips@ietf.org To: Paul Koning From: Caitlin Bestler In-Reply-To: <16299.45902.440113.623321@gargle.gargle.HOWL> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, November 7, 2003, at 08:59 AM, Paul Koning wrote: > Caitlin> Why not simply send bad TCP frames? In other words, send a > Caitlin> bad digest down one layer. It's better than aborting the > Caitlin> connection. > > That will not work at all. If you send a TCP packet with a bad TCP > checksum, it will be discarded by the receiver, which doesn't ACK it > and doesn't accept subsequent packets (because they are out of > order). The sender would normally retransmit such dropped packets. > If the packet has a forced back checksum, then the connection cannot > make progress. In other words, the effect is identical to dropping > the connection right away, except far more clumsily and less > reliably. > > paul If you are cleanly layered, the entire iSCSI packet was probably validated *before* you started transmitting. If you are not cleanly layered, there is nothing to keep you from refetching the content for the retransmit. Generating a bad TCP checksum is just acknowledging that what was earlier in the packet was a "bad copy". The retransmit should of course be of the correct content. If your layering allows you to generate a bad TCP checksum, the odds are that it would also allow you to fix the buffer for the retransmit. Of course that assumes a very embedded implementation. But any reaction that is taking place *during* the transmission of a packet is likely to be in an embedded implementation. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 11:17:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20584 for ; Fri, 7 Nov 2003 11:17:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9IK-0006NR-E0 for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 11:17:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7GH7Ku024506 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 11:17:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9IJ-0006N9-2r for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 11:17:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20575 for ; Fri, 7 Nov 2003 11:16:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9II-00070I-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 11:17:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI9IH-00070F-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 11:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9IC-0006M8-Sa; Fri, 07 Nov 2003 11:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9HT-0006L0-JA for ips@optimus.ietf.org; Fri, 07 Nov 2003 11:16:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20564 for ; Fri, 7 Nov 2003 11:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9HS-0006zv-00 for ips@ietf.org; Fri, 07 Nov 2003 11:16:14 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1AI9HR-0006zs-00 for ips@ietf.org; Fri, 07 Nov 2003 11:16:14 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel10.hp.com (Postfix) with ESMTP id BFA821C01B2E for ; Fri, 7 Nov 2003 08:16:06 -0800 (PST) Received: from mk731915.cup.hp.com ([15.8.80.111]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id hA7G8em16813 for ; Fri, 7 Nov 2003 08:08:40 -0800 (PST) Message-Id: <5.1.0.14.2.20031107080620.021f0868@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Nov 2003 08:07:18 -0800 To: ips@ietf.org From: Michael Krause Subject: Re: [Ips] Handling error during packet transmission In-Reply-To: References: <16299.45902.440113.623321@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , At 10:01 AM 11/7/2003 -0600, Caitlin Bestler wrote: >On Friday, November 7, 2003, at 08:59 AM, Paul Koning wrote: > >> Caitlin> Why not simply send bad TCP frames? In other words, send a >> Caitlin> bad digest down one layer. It's better than aborting the >> Caitlin> connection. >> >>That will not work at all. If you send a TCP packet with a bad TCP >>checksum, it will be discarded by the receiver, which doesn't ACK it >>and doesn't accept subsequent packets (because they are out of >>order). The sender would normally retransmit such dropped packets. >>If the packet has a forced back checksum, then the connection cannot >>make progress. In other words, the effect is identical to dropping >>the connection right away, except far more clumsily and less >>reliably. >> >> paul > >If you are cleanly layered, the entire iSCSI packet was probably >validated *before* you started transmitting. > >If you are not cleanly layered, there is nothing to keep you from >refetching the content for the retransmit. Generating a bad TCP >checksum is just acknowledging that what was earlier in the packet >was a "bad copy". The retransmit should of course be of the correct >content. > >If your layering allows you to generate a bad TCP checksum, the >odds are that it would also allow you to fix the buffer for the >retransmit. > >Of course that assumes a very embedded implementation. But any >reaction that is taking place *during* the transmission of a packet >is likely to be in an embedded implementation. Still seems simpler (especially as this may be a rare condition) to simply drop the connection and start anew which is just an application of KISS that will work across any implementation. Mike _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 11:29:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20950 for ; Fri, 7 Nov 2003 11:29:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9Ty-0006gy-1n for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 11:29:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7GTA9r025718 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 11:29:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9Tx-0006gj-U6 for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 11:29:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20922 for ; Fri, 7 Nov 2003 11:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9Tw-00078g-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 11:29:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI9Tw-00078d-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 11:29:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9Tp-0006ej-Ou; Fri, 07 Nov 2003 11:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9DS-0006Ic-3T for ips@optimus.ietf.org; Fri, 07 Nov 2003 11:12:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20493 for ; Fri, 7 Nov 2003 11:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9DR-0006x1-00 for ips@ietf.org; Fri, 07 Nov 2003 11:12:05 -0500 Received: from [66.155.203.134] (helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1AI9DQ-0006wo-00 for ips@ietf.org; Fri, 07 Nov 2003 11:12:04 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hA7GBXpW032726 for ; Fri, 7 Nov 2003 11:11:33 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hA7GBXg6032721; Fri, 7 Nov 2003 11:11:33 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id hA7GBXE06424; Fri, 7 Nov 2003 11:11:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16299.50228.793005.258196@gargle.gargle.HOWL> Date: Fri, 7 Nov 2003 11:11:32 -0500 From: Paul Koning To: cait@asomi.com Cc: ips@ietf.org Subject: Re: [Ips] Handling error during packet transmission References: <16299.45902.440113.623321@gargle.gargle.HOWL> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Caitlin" == Caitlin Bestler writes: Caitlin> On Friday, November 7, 2003, at 08:59 AM, Paul Koning wrote: Caitlin> Why not simply send bad TCP frames? In other words, send a Caitlin> bad digest down one layer. It's better than aborting the Caitlin> connection. >> That will not work at all. If you send a TCP packet with a bad >> TCP checksum, it will be discarded by the receiver, which doesn't >> ACK it and doesn't accept subsequent packets (because they are out >> of order). The sender would normally retransmit such dropped >> packets. If the packet has a forced back checksum, then the >> connection cannot make progress. In other words, the effect is >> identical to dropping the connection right away, except far more >> clumsily and less reliably. >> >> paul Caitlin> If you are cleanly layered, the entire iSCSI packet was Caitlin> probably validated *before* you started transmitting. Caitlin> If you are not cleanly layered, there is nothing to keep you Caitlin> from refetching the content for the retransmit. Generating a Caitlin> bad TCP checksum is just acknowledging that what was earlier Caitlin> in the packet was a "bad copy". The retransmit should of Caitlin> course be of the correct content. If you can re-fetch and get good content, you should just do that. No need to confuse the protocol with weird messages; recovery is completely an internal matter. I was assuming the question had to do with the case where the error was NOT recoverable. In that case you have to fail the I/O in mid-transfer. The way to do that, for cases where the problem is seen in a place where the protocol doesn't provide for a way to abort cleanly, is to reset the TCP connection. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 12:44:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26364 for ; Fri, 7 Nov 2003 12:44:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAee-0003Iw-Rl for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 12:44:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7HiGcJ012696 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 12:44:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAee-0003Ih-Mh for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 12:44:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26333 for ; Fri, 7 Nov 2003 12:44:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAed-0000Hg-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 12:44:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIAec-0000Hd-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 12:44:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAeO-0003HZ-Tu; Fri, 07 Nov 2003 12:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAe6-0003H5-Iu for ips@optimus.ietf.org; Fri, 07 Nov 2003 12:43:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26312 for ; Fri, 7 Nov 2003 12:43:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAe4-0000HN-00 for ips@ietf.org; Fri, 07 Nov 2003 12:43:40 -0500 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1AIAe3-0000HC-00 for ips@ietf.org; Fri, 07 Nov 2003 12:43:39 -0500 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id C63BE245BCF; Fri, 7 Nov 2003 12:43:44 -0500 (EST) Date: Fri, 7 Nov 2003 11:43:16 -0600 Subject: Re: [Ips] Handling error during packet transmission Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ips@ietf.org To: Paul Koning From: Caitlin Bestler In-Reply-To: <16299.50228.793005.258196@gargle.gargle.HOWL> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, November 7, 2003, at 10:11 AM, Paul Koning wrote: > I was assuming the question had to do with the case where the error > was NOT recoverable. In that case you have to fail the I/O in > mid-transfer. The way to do that, for cases where the problem is seen > in a place where the protocol doesn't provide for a way to abort > cleanly, is to reset the TCP connection. Agreed, if the error cannot be recovered then the connection is doomed anyway. If however, you could re-read the sector and get a good copy, using TCP to give you the time to do that re-read may be a better solution. Of course you already need to be structured in a certain way to do this. I certainly would not recommend removing layer separation *for* this purpose. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 13:49:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28916 for ; Fri, 7 Nov 2003 13:49:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBfF-0007PI-PW for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 13:48:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7ImvFk028466 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 13:48:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBfF-0007Oz-HX for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 13:48:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28872 for ; Fri, 7 Nov 2003 13:48:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBfD-0001AV-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 13:48:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIBfC-0001A9-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 13:48:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBeL-0007IB-KE; Fri, 07 Nov 2003 13:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBdk-0007Fl-6Z for ips@optimus.ietf.org; Fri, 07 Nov 2003 13:47:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28832 for ; Fri, 7 Nov 2003 13:47:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBdh-00019n-00 for ips@ietf.org; Fri, 07 Nov 2003 13:47:21 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1AIBdh-00019Z-00 for ips@ietf.org; Fri, 07 Nov 2003 13:47:21 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel9.hp.com (Postfix) with ESMTP id 760CD1C00A78; Tue, 11 Nov 2003 15:45:34 -0500 (EST) Received: from swathi.rose.hp.com (dhcp-roseor-bdi217.rose.hp.com [15.23.138.217]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id KAA18490; Fri, 7 Nov 2003 10:47:13 -0800 (PST) Message-Id: <6.0.0.22.1.20031107103247.02a32ab0@rosemail.rose.hp.com> X-Sender: cbm@rosemail.rose.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 07 Nov 2003 10:47:11 -0800 To: wrstuden@wasabisystems.com, ips@ietf.org From: "Mallikarjun C." Subject: Re: [Ips] Handling error during packet transmission In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Bill, I think you have all the different possible solutions identified. My take is that the choice is one of implementation/solution considerations - such as how fault-tolerant you want to be, how many other I/Os are likely active on the connection at any time, how expensive it is to recover the other I/Os if connection is dropped, how flexible is your code, can the target fence the malfunctioning physical memory and continue on or the session has to be killed anyway...etc. Given that the SCSI initiator cannot make any assumptions about the contents of a posted Data-in buffer unless it receives a successful completion from the target, the only spec requirement in the scenario you describe is that the target must not send a successful SCSI status. Mallikarjun At 04:21 PM 11/6/2003, wrstuden@wasabisystems.com wrote: >Ok, here's an error that I admit is a bit extreme. > >What do you (a target or initiator) do if you have sent the header for a >PDU and then realize, say due to ECC memory error detection, that you >can't send the rest of the PDU? > >Say the target is servicing a SCSI READ command. It sets up a PDU for >transmission. Assume we're on a link where we aren't sending jumbo grams >and the PDU will mean multiple ethernet frames. Now say that there is a >(detected) data corruption event during the transmission of the PDU. Like >a double bit error on ECC system memory for instance. The point is the PDU >header has gone out but we don't have all the data. > >And assume that when we go to try and recover the data, we find out we >can't easily get it (it wasn't say a PCI transfer error that re-running >the transfer will recover). We decide we don't want to stall the TCP >connection getting it. > >What do we do? > >If we had data digests, one option would be to fill the rest of the >PDU with nonsense (zeros?), and deliberately send a bad digest. > >If we didn't have digests, would it be reasonable to send garbage (zeros?) >to fill the PDU, then abort the command with a CHECK CONDITION and >indicate an underrun that didn't include the unsent PDU data? > >As an example, we successfully send 8K of data, then we are sending a >DATA-IN PDU with 8k, and run into the error after 4k. We abort the >command, and indicate that only 12k of data were sent. ? > >Yes, this shouldn't happen, but what do you do if it does? > >Take care, > >Bill > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 14:09:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29739 for ; Fri, 7 Nov 2003 14:09:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIByh-0000MQ-PX for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 14:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7J93fO001380 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 14:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIByh-0000MB-FR for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 14:09:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29718 for ; Fri, 7 Nov 2003 14:08:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIByf-0001Rb-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 14:09:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIBye-0001RY-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 14:09:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIByf-0000LE-Cw; Fri, 07 Nov 2003 14:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBye-0000L1-DU for ips@optimus.ietf.org; Fri, 07 Nov 2003 14:09:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29715 for ; Fri, 7 Nov 2003 14:08:48 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIByb-0001RU-00 for ips@ietf.org; Fri, 07 Nov 2003 14:08:58 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1AIByb-0001RR-00 for ips@ietf.org; Fri, 07 Nov 2003 14:08:57 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 5BB1E25787 for ; Fri, 7 Nov 2003 12:08:56 -0700 (MST) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by relcos1.cos.agilent.com (Postfix) with SMTP id 34E267E for ; Fri, 7 Nov 2003 12:08:56 -0700 (MST) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 07 Nov 2003 12:08:55 -0700 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Nov 2003 12:08:55 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0132E05D1@axcs04.cos.agilent.com> To: ips@ietf.org Date: Fri, 7 Nov 2003 12:08:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Ips] Authentication Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , I just noticed a contradiction between 8.2 and 11.1 8.2 says: "During login, the target MUST authenticate the initiator and the initiator MAY authenticate the target." which is saying that authentication must be used on each login to authenticate the initiator. 11.1 says: "Authentication is OPTIONAL to use but MUST be supported by the target and initiator." which is saying that authentication does not have to be used on every login. An AuthMeth key of None is defined which is consistant with this. Other material in 11.1 indicates that when authentication is done the the initiator is always authenticated and the target MAY be authenticated. 5.3 is consistant with 11.1 since it says that the Login Phase MAY include a SecurityNegotiation Phase. Pat _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 15:37:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06655 for ; Fri, 7 Nov 2003 15:37:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDLv-0006YY-O0 for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 15:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Kb7ia025191 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 15:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDLv-0006Y6-7I for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:37:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06645 for ; Fri, 7 Nov 2003 15:36:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDLt-0002b9-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 15:37:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDLt-0002b6-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 15:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDLp-0006Vh-1v; Fri, 07 Nov 2003 15:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDKv-0006So-Py for ips@optimus.ietf.org; Fri, 07 Nov 2003 15:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06623 for ; Fri, 7 Nov 2003 15:35:42 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDKh-0002ab-00 for ips@ietf.org; Fri, 07 Nov 2003 15:35:51 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1AIDKh-0002aY-00 for ips@ietf.org; Fri, 07 Nov 2003 15:35:51 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 995A26B25; Fri, 7 Nov 2003 13:35:47 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 7202E7E; Fri, 7 Nov 2003 13:35:47 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Ips] Handling error during packet transmission Date: Fri, 7 Nov 2003 13:35:44 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0132E05D4@axcs04.cos.agilent.com> Thread-Topic: [Ips] Handling error during packet transmission Thread-Index: AcOlQHqFkRVMdneET4ypTDKtvhiIOQALeoaA To: , Cc: Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Paul, I agree. Similar logic applies to corrupting the digest when digests are = enabled. It doesn't stop the command - it just invokes whatever recovery = level is available and if the recovery can't succeed because data isn't = available, then the sesion will have to be closed and restarted. Pat -----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Friday, November 07, 2003 6:59 AM To: cait@asomi.com Cc: ips@ietf.org Subject: Re: [Ips] Handling error during packet transmission >>>>> "Caitlin" =3D=3D Caitlin Bestler writes: Caitlin> On Thursday, November 6, 2003, at 08:19 PM, Paul Koning Caitlin> wrote: wrstuden> If we had data digests, one option would be to fill the wrstuden> rest of the PDU with nonsense (zeros?), and deliberately wrstuden> send a bad digest. >> Agreed. >>=20 wrstuden> If we didn't have digests, would it be reasonable to send wrstuden> garbage (zeros?) to fill the PDU, then abort the command wrstuden> with a CHECK CONDITION and indicate an underrun that didn't wrstuden> include the unsent PDU data? >> I don't like that; the garbage you sent might be delivered to user >> buffers and mistaken for real data. >>=20 >> Better just to abort the connection. This sort of thing should be >> extremely rare; there is no need to make recovery from it >> efficient. Caitlin> Why not simply send bad TCP frames? In other words, send a Caitlin> bad digest down one layer. It's better than aborting the Caitlin> connection. That will not work at all. If you send a TCP packet with a bad TCP checksum, it will be discarded by the receiver, which doesn't ACK it and doesn't accept subsequent packets (because they are out of order). The sender would normally retransmit such dropped packets. If the packet has a forced back checksum, then the connection cannot make progress. In other words, the effect is identical to dropping the connection right away, except far more clumsily and less reliably.=20 paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 15:46:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06957 for ; Fri, 7 Nov 2003 15:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDUZ-0007JC-9W for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 15:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Kk3VM028088 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 15:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDUZ-0007Ix-4q for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:46:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06952 for ; Fri, 7 Nov 2003 15:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDUX-0002hF-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 15:46:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDUX-0002hC-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 15:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDUX-0007FW-By; Fri, 07 Nov 2003 15:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDTl-00079B-6h for ips@optimus.ietf.org; Fri, 07 Nov 2003 15:45:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06899 for ; Fri, 7 Nov 2003 15:45:01 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDTj-0002f2-00 for ips@ietf.org; Fri, 07 Nov 2003 15:45:11 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1AIDTi-0002ev-00 for ips@ietf.org; Fri, 07 Nov 2003 15:45:10 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 0C0D1269A6; Fri, 7 Nov 2003 13:45:08 -0700 (MST) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by relcos1.cos.agilent.com (Postfix) with SMTP id D94FA7E; Fri, 7 Nov 2003 13:45:07 -0700 (MST) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 07 Nov 2003 13:45:06 -0700 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Nov 2003 13:45:05 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0132E05D5@axcs04.cos.agilent.com> To: cbm@rose.hp.com, wrstuden@wasabisystems.com, ips@ietf.org Subject: RE: [Ips] Handling error during packet transmission Date: Fri, 7 Nov 2003 13:45:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Mallikarjun, Sending an unsucccessful status applies if it is a SCSI Read. What if it s a SCSI Write - that is, the initiator is sending the data? Can it solve the problem by aborting the task? Regards, Pat -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Friday, November 07, 2003 10:47 AM To: wrstuden@wasabisystems.com; ips@ietf.org Subject: Re: [Ips] Handling error during packet transmission Bill, I think you have all the different possible solutions identified. My take is that the choice is one of implementation/solution considerations - such as how fault-tolerant you want to be, how many other I/Os are likely active on the connection at any time, how expensive it is to recover the other I/Os if connection is dropped, how flexible is your code, can the target fence the malfunctioning physical memory and continue on or the session has to be killed anyway...etc. Given that the SCSI initiator cannot make any assumptions about the contents of a posted Data-in buffer unless it receives a successful completion from the target, the only spec requirement in the scenario you describe is that the target must not send a successful SCSI status. Mallikarjun At 04:21 PM 11/6/2003, wrstuden@wasabisystems.com wrote: >Ok, here's an error that I admit is a bit extreme. > >What do you (a target or initiator) do if you have sent the header for a >PDU and then realize, say due to ECC memory error detection, that you >can't send the rest of the PDU? > >Say the target is servicing a SCSI READ command. It sets up a PDU for >transmission. Assume we're on a link where we aren't sending jumbo grams >and the PDU will mean multiple ethernet frames. Now say that there is a >(detected) data corruption event during the transmission of the PDU. Like >a double bit error on ECC system memory for instance. The point is the PDU >header has gone out but we don't have all the data. > >And assume that when we go to try and recover the data, we find out we >can't easily get it (it wasn't say a PCI transfer error that re-running >the transfer will recover). We decide we don't want to stall the TCP >connection getting it. > >What do we do? > >If we had data digests, one option would be to fill the rest of the >PDU with nonsense (zeros?), and deliberately send a bad digest. > >If we didn't have digests, would it be reasonable to send garbage (zeros?) >to fill the PDU, then abort the command with a CHECK CONDITION and >indicate an underrun that didn't include the unsent PDU data? > >As an example, we successfully send 8K of data, then we are sending a >DATA-IN PDU with 8k, and run into the error after 4k. We abort the >command, and indicate that only 12k of data were sent. ? > >Yes, this shouldn't happen, but what do you do if it does? > >Take care, > >Bill > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 15:57:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07344 for ; Fri, 7 Nov 2003 15:57:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDfD-0007uG-GW for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 15:57:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Kv3aJ030386 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 15:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDfD-0007u1-BG for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:57:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07336 for ; Fri, 7 Nov 2003 15:56:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDfB-0002p1-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 15:57:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDfB-0002oy-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 15:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDfA-0007t4-Pp; Fri, 07 Nov 2003 15:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDeN-0007rL-OW for ips@optimus.ietf.org; Fri, 07 Nov 2003 15:56:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07329 for ; Fri, 7 Nov 2003 15:55:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDeL-0002oi-00 for ips@ietf.org; Fri, 07 Nov 2003 15:56:09 -0500 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AIDeK-0002oA-00 for ips@ietf.org; Fri, 07 Nov 2003 15:56:08 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA7Ku9or030584 for ; Fri, 7 Nov 2003 20:56:10 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA7Kl2b12728 for ; Fri, 7 Nov 2003 20:47:02 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110712553524117 ; Fri, 07 Nov 2003 12:55:35 -0800 Received: from fmsmsx404.amr.corp.intel.com ([132.233.42.208]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Nov 2003 12:55:35 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Ips] Full Feature Phase and Digests Date: Fri, 7 Nov 2003 12:55:34 -0800 Message-ID: Thread-Topic: [Ips] Full Feature Phase and Digests Thread-Index: AcOgMB1/9tFBryWIQsWEI4JDzl0EZQFPASdg From: "Yao, Xuebin" To: , "dan yo" Cc: X-OriginalArrivalTime: 07 Nov 2003 20:55:35.0360 (UTC) FILETIME=[7D996C00:01C3A571] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >> I.e. Only iSCSI op codes 0x00, 0x01, 0x02, 0x04, 0x05, 0x010, 0x1c-0x1e >>(maybe) for the initiator, and 0x20, 0x21, 0x22, 0x24, 0x25, 0x31, 0x32, >>0x3c-0x3e (maybe), 0x3f for the target (anything not Logout or Login) will >>have the Digests and they must have them if stated in Login of the >>session? >> >> Am I right? >Not quite. Think of digests as each controled by a boolean, which is set >at the end of login processing (if digests were negotiated of course). If >the header_digest boolean is set, all PDUs must have a header. If the >data_digest boolean is set, all PDUs with data segments must have data >digests. >The difference between the two views is a matter of how the receive logic >is built. If you're in FFP and doing header digests, you evaluate the >digest before you look at the opcode. You have to do this because until >you know the header digest is ok, you can't trust the opcode! Is that always the case? Think about the situation of iSCSI target receive logic for iSCSI requests with posssible AHS. According to iSCSI spec, header digest covers both BHS and AHS segments. Since AHS could come with variable length, without looking at opcode (to determine if you would expect an AHS) and TotalAHSLength field, the header_digest would not be possibly validated correctly for the incoming PDUs containing AHS.=20 Agree that "until you know the header digest is OK, you can't trust the opcode". However, even you look at the opcode/AHSLength to determine if AHS presents, you don't have to trust them until header_digest (include AHS segment) is verified OK.=20 Otherwise, you may choose to always validate the header_digest for BHS at first without look at the opcode, if it is not OK, then you have to double check if AHS presents and if so, need to re-validate digest again. =20 I think it depends on implementation choice. Agree? Xuebin -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of wrstuden@wasabisystems.com Sent: Friday, October 31, 2003 9:20 PM To: dan yo Cc: ips@ietf.org Subject: Re: [Ips] Full Feature Phase and Digests On Wed, 29 Oct 2003, dan yo wrote: > Hi, > I have a question on whether digest (header and data) can appear before > the FFP. As far as I know, No. > I found the same question from the archive but couldn't find the answer, could someone confirm. Thanks. > Dan > > An earlier email from archive: > > I am not sure if this is the place for me to ask this question, so > forgive me if I am out of line. > Is there a difference between S5: LOGGED_IN and Full Feature Phase > (a.k.a. full-feature phase in some parts of the document; it would be > nice if they were all the same; I am not a regex guru)? Yes. S6 (IN_LOGOUT) and S7 (LOGOUT_REQUESTED) are also in Full Feature Phase. I think S8 (CLEANUP_WAIT) also would be FFP, but I'm not sure how many PDUs get transmitted. > If so, and I understand the digest section, neither the logout or login > PDU's will have digests on them. I believe this holds even after the > first connection of the session, because later connections are not yet > in Full Feature Phase (S5). I think the better way to think about this is to consider when the PDU was sent. The connection enters FFP: (initiator) after processing the Login Response that correctly (*) transitions out of login; (target) after sending the Login Response that transitions out of login. (*) The initiator should make sure it is happy with the Login RSP of course. For instance, if it hadn't set 'T' on the Login Request, it shouldn't honor 'T' on the RSP. As logout PDUs are sent after transitioning out of login, they should have digests. > I.e. Only iSCSI op codes 0x00, 0x01, 0x02, 0x04, 0x05, 0x010, 0x1c-0x1e (maybe) for the initiator, and 0x20, 0x21, 0x22, 0x24, 0x25, 0x31, 0x32, 0x3c-0x3e (maybe), 0x3f for the target (anything not Logout or Login) will have the Digests and they must have them if stated in Login of the session? > > Am I right? Not quite. Think of digests as each controled by a boolean, which is set at the end of login processing (if digests were negotiated of course). If the header_digest boolean is set, all PDUs must have a header. If the data_digest boolean is set, all PDUs with data segments must have data digests. The difference between the two views is a matter of how the receive logic is built. If you're in FFP and doing header digests, you evaluate the digest before you look at the opcode. You have to do this because until you know the header digest is ok, you can't trust the opcode! Think about the case where transmission corruption changed the opcode for a PDU, and made an FFP-phase PDU look like a login PDU. If we looked at the opcode before the header digest and made a decision based on opcode, we would look at this as a Login PDU, not pull the digest out of the command stream, and look at potentially erronious ahs and data segment length values. And then start processing commands that may not have been commands. :-) That's how an initiator and a target need to think about this. That said, I know that Data Transit make protocol analyzers. For an analyzer, I think it's fine to know that Login PDUs don't have digests, and everything else does. The only place this makes a difference is the corner case where an initiator sends a Login Request PDU after FFP. If header digests have been negotiated, it needs to add a header digest, then the target will reject the PDU. ;-) Since this is an error case, if an analyzer doesn't carry state for the whole connection, it's ok for it to not know FFP and then just make a choice based on opcode. Ethereal does this, and it's fine. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 17:34:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11455 for ; Fri, 7 Nov 2003 17:34:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFB9-0007Lz-HD for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 17:34:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7MY7vl028261 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 17:34:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFB9-0007Lk-AX for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 17:34:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11396 for ; Fri, 7 Nov 2003 17:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFB6-0004GQ-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 17:34:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIFB6-0004GN-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 17:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFB3-0007KR-Jq; Fri, 07 Nov 2003 17:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFA8-0007JI-Ej for ips@optimus.ietf.org; Fri, 07 Nov 2003 17:33:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11346 for ; Fri, 7 Nov 2003 17:32:51 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFA5-0004Er-00 for ips@ietf.org; Fri, 07 Nov 2003 17:33:01 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AIFA5-0004En-00 for ips@ietf.org; Fri, 07 Nov 2003 17:33:01 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 2221D40142; Fri, 7 Nov 2003 17:33:00 -0500 (EST) Date: Fri, 7 Nov 2003 13:29:45 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Yao, Xuebin" Cc: dan yo , ips@ietf.org Subject: RE: [Ips] Full Feature Phase and Digests In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , On Fri, 7 Nov 2003, Yao, Xuebin wrote: > >The difference between the two views is a matter of how the receive > logic > >is built. If you're in FFP and doing header digests, you evaluate the > >digest before you look at the opcode. You have to do this because until > >you know the header digest is ok, you can't trust the opcode! > > Is that always the case? Think about the situation of iSCSI target > receive logic for iSCSI requests with posssible AHS. According to iSCSI I hadn't touched on AHS. Good to bring up. > spec, header digest covers both BHS and AHS segments. Since AHS could > come with variable length, without looking at opcode (to determine if > you would expect an AHS) and TotalAHSLength field, the header_digest > would not be possibly validated correctly for the incoming PDUs > containing AHS. You would have to look at TotalAHSLength in order to find the digest. > Agree that "until you know the header digest is OK, you can't trust the > opcode". However, even you look at the opcode/AHSLength to determine if > AHS presents, you don't have to trust them until header_digest (include > AHS segment) is verified OK. > > Otherwise, you may choose to always validate the header_digest for BHS > at first without look at the opcode, if it is not OK, then you have to > double check if AHS presents and if so, need to re-validate digest > again. I think it would never be correct to blindly digest-check the BHS w/o considering TotalAHSLength, as you will never know where the digest is supposed to be. :-) I also think your consideration of the opcode in the receive logic is incorrect. The receive logic should only worry about the framing of packets, and leave validation to the next software layer. Yes, a write PDU with an AHS is wrong, but it is not the same kind of wrong as a PDU with a bad header digest. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 18:08:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12805 for ; Fri, 7 Nov 2003 18:08:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFi4-0000wv-6R for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 18:08:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7N88GF003643 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 18:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFi3-0000wg-S9 for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 18:08:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12747 for ; Fri, 7 Nov 2003 18:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFi1-0004bS-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 18:08:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIFi0-0004bP-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 18:08:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFhx-0000ur-Sb; Fri, 07 Nov 2003 18:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFZk-0000OQ-MP for ips@optimus.ietf.org; Fri, 07 Nov 2003 17:59:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12163 for ; Fri, 7 Nov 2003 17:59:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFZh-0004Ww-00 for ips@ietf.org; Fri, 07 Nov 2003 17:59:30 -0500 Received: from mta7.pltn13.pbi.net ([64.164.98.8]) by ietf-mx with esmtp (Exim 4.12) id 1AIFZh-0004Wt-00 for ips@ietf.org; Fri, 07 Nov 2003 17:59:29 -0500 Received: from DT-Server1.datatransit.com (adsl-67-127-61-146.dsl.pltn13.pacbell.net [67.127.61.146]) by mta7.pltn13.pbi.net (8.12.10/8.12.10) with SMTP id hA7MxSxu027998 for ; Fri, 7 Nov 2003 14:59:28 -0800 (PST) Received: (qmail 9518 invoked from network); 7 Nov 2003 22:59:27 -0000 Received: from unknown (HELO DelliciousGlow) (10.0.0.242) by dt-server1.datatransit.com with SMTP; 7 Nov 2003 22:59:27 -0000 From: "Randy Jennings" To: , "'Yao, Xuebin'" Cc: "'dan yo'" , Subject: RE: [Ips] Full Feature Phase and Digests Date: Fri, 7 Nov 2003 14:59:27 -0800 Message-ID: <000801c3a582$cbecef60$f200000a@DelliciousGlow> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > >The difference between the two views is a matter of how the receive > > logic > > >is built. If you're in FFP and doing header digests, you > evaluate the > > >digest before you look at the opcode. You have to do this > because until > > >you know the header digest is ok, you can't trust the opcode! > > > > Is that always the case? Think about the situation of iSCSI target > > receive logic for iSCSI requests with posssible AHS. > According to iSCSI > > I hadn't touched on AHS. Good to bring up. > I think it would never be correct to blindly digest-check the BHS w/o > considering TotalAHSLength, as you will never know where the digest is > supposed to be. :-) > > I also think your consideration of the opcode in the receive logic is > incorrect. The receive logic should only worry about the framing of > packets, and leave validation to the next software layer. > > Yes, a write PDU with an AHS is wrong, but it is not the same kind of > wrong as a PDU with a bad header digest. > I assume you mean right PDU :-). I agree that you should not check opcode to see if there _should_ be an AHS there. I think what Xuebin's point is that the AHS may be corrupted, and you would not find the correct spot for the Header Digest. I think we are safely assuming that a CRC check on random data would probably fail. The interesting part here is a AHS that indicates the digest is beyond the end of received data (sent TCP stream). Just something to keep in mind. Don't you love corner cases? Sincerely, Randy Jennings Data Transit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 19:49:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16777 for ; Fri, 7 Nov 2003 19:49:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIHHp-0005rX-0w for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 19:49:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA80n8Yu022529 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 19:49:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIHHo-0005rI-SV for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 19:49:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16765 for ; Fri, 7 Nov 2003 19:48:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIHHn-0005zR-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 19:49:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIHHm-0005zO-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 19:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIHHg-0005qF-Vt; Fri, 07 Nov 2003 19:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIHH7-0005oS-Cy for ips@optimus.ietf.org; Fri, 07 Nov 2003 19:48:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16757 for ; Fri, 7 Nov 2003 19:48:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIHH5-0005zD-00 for ips@ietf.org; Fri, 07 Nov 2003 19:48:23 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1AIHH4-0005zA-00 for ips@ietf.org; Fri, 07 Nov 2003 19:48:22 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel6.hp.com (Postfix) with ESMTP id 0D7541C012E1; Fri, 7 Nov 2003 19:48:23 -0500 (EST) Received: from swathi.rose.hp.com (dhcp-roseor-bdi217.rose.hp.com [15.23.138.217]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id QAA11065; Fri, 7 Nov 2003 16:48:21 -0800 (PST) Message-Id: <6.0.0.22.1.20031107162859.02b03248@rosemail.rose.hp.com> X-Sender: cbm@rosemail.rose.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 07 Nov 2003 16:39:17 -0800 To: pat_thaler@agilent.com, cbm@rose.hp.com, wrstuden@wasabisystems.com, ips@ietf.org From: "Mallikarjun C." Subject: RE: [Ips] Handling error during packet transmission In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0132E05D5@axcs04.cos.agilen t.com> References: <1BEBA5E8600DD4119A50009027AF54A0132E05D5@axcs04.cos.agilent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Pat, I understood the question to be only about a SCSI Read, but you're right, the other interesting case is of a non-recoverable error happening on the initiator while servicing an R2T. As you suggest, an initiator-initiated abort TMF should ensure the correctness and ordering expectations here. Initiator must not of course complete the Data-out sequence that took the hit (even if it did, not with the "Desired Data Transfer Length" # of bytes). Regards. Mallikarjun At 12:45 PM 11/7/2003, pat_thaler@agilent.com wrote: >Mallikarjun, > >Sending an unsucccessful status applies if it is a SCSI Read. What if it s >a SCSI Write - that is, the initiator is sending the data? Can it solve >the problem by aborting the task? > >Regards, >Pat > >-----Original Message----- >From: Mallikarjun C. [mailto:cbm@rose.hp.com] >Sent: Friday, November 07, 2003 10:47 AM >To: wrstuden@wasabisystems.com; ips@ietf.org >Subject: Re: [Ips] Handling error during packet transmission > > >Bill, > >I think you have all the different possible solutions identified. >My take is that the choice is one of implementation/solution >considerations - such as how fault-tolerant you want to be, >how many other I/Os are likely active on the connection at >any time, how expensive it is to recover the other I/Os if connection >is dropped, how flexible is your code, can the target fence >the malfunctioning physical memory and continue on or the >session has to be killed anyway...etc. > >Given that the SCSI initiator cannot make any assumptions >about the contents of a posted Data-in buffer unless it receives >a successful completion from the target, the only spec requirement >in the scenario you describe is that the target must not send >a successful SCSI status. > >Mallikarjun > >At 04:21 PM 11/6/2003, wrstuden@wasabisystems.com wrote: > >Ok, here's an error that I admit is a bit extreme. > > > >What do you (a target or initiator) do if you have sent the header for a > >PDU and then realize, say due to ECC memory error detection, that you > >can't send the rest of the PDU? > > > >Say the target is servicing a SCSI READ command. It sets up a PDU for > >transmission. Assume we're on a link where we aren't sending jumbo grams > >and the PDU will mean multiple ethernet frames. Now say that there is a > >(detected) data corruption event during the transmission of the PDU. Like > >a double bit error on ECC system memory for instance. The point is the PDU > >header has gone out but we don't have all the data. > > > >And assume that when we go to try and recover the data, we find out we > >can't easily get it (it wasn't say a PCI transfer error that re-running > >the transfer will recover). We decide we don't want to stall the TCP > >connection getting it. > > > >What do we do? > > > >If we had data digests, one option would be to fill the rest of the > >PDU with nonsense (zeros?), and deliberately send a bad digest. > > > >If we didn't have digests, would it be reasonable to send garbage (zeros?) > >to fill the PDU, then abort the command with a CHECK CONDITION and > >indicate an underrun that didn't include the unsent PDU data? > > > >As an example, we successfully send 8K of data, then we are sending a > >DATA-IN PDU with 8k, and run into the error after 4k. We abort the > >command, and indicate that only 12k of data were sent. ? > > > >Yes, this shouldn't happen, but what do you do if it does? > > > >Take care, > > > >Bill > > > >_______________________________________________ > >Ips mailing list > >Ips@ietf.org > >https://www1.ietf.org/mailman/listinfo/ips > > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 20:15:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17574 for ; Fri, 7 Nov 2003 20:15:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIHgv-00071A-Mn for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 20:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA81F5Xv026970 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 20:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIHgv-00070v-Ff for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 20:15:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17567 for ; Fri, 7 Nov 2003 20:14:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIHgt-0006FK-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 20:15:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIHgt-0006FH-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 20:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIHgt-0006zy-DO; Fri, 07 Nov 2003 20:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIHfx-0006z0-Ka for ips@optimus.ietf.org; Fri, 07 Nov 2003 20:14:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17542 for ; Fri, 7 Nov 2003 20:13:54 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIHfv-0006Ex-00 for ips@ietf.org; Fri, 07 Nov 2003 20:14:03 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AIHfv-0006Eu-00 for ips@ietf.org; Fri, 07 Nov 2003 20:14:03 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id D497F40140; Fri, 7 Nov 2003 20:14:03 -0500 (EST) Date: Fri, 7 Nov 2003 16:10:49 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Randy Jennings Cc: "'Yao, Xuebin'" , "'dan yo'" , ips@ietf.org Subject: RE: [Ips] Full Feature Phase and Digests In-Reply-To: <000801c3a582$cbecef60$f200000a@DelliciousGlow> Message-ID: References: <000801c3a582$cbecef60$f200000a@DelliciousGlow> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , On Fri, 7 Nov 2003, Randy Jennings wrote: > > I think it would never be correct to blindly digest-check the BHS w/o > > considering TotalAHSLength, as you will never know where the digest is > > supposed to be. :-) > > > > I also think your consideration of the opcode in the receive logic is > > incorrect. The receive logic should only worry about the framing of > > packets, and leave validation to the next software layer. > > > > Yes, a write PDU with an AHS is wrong, but it is not the same kind of > > wrong as a PDU with a bad header digest. > > > I assume you mean right PDU :-). > > I agree that you should not check opcode to see if there _should_ be an > AHS there. I think what Xuebin's point is that the AHS may be > corrupted, and you would not find the correct spot for the Header > Digest. I think we are safely assuming that a CRC check on random data > would probably fail. Yes, we are assuming that a CRC check on random data will fail. Assuming random data leads to a random CRC, then we have a one in 2^32 chance of getting a false positive. :-) > The interesting part here is a AHS that indicates the digest is beyond > the end of received data (sent TCP stream). Just something to keep in > mind. Don't you love corner cases? Doesn't matter. TCP is a stream protocol. The AHS and or the digest can come in subsequent frames. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 7 21:57:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19910 for ; Fri, 7 Nov 2003 21:57:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJHf-0002Pc-Ro for ips-archive@odin.ietf.org; Fri, 07 Nov 2003 21:57:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA82v7tb009266 for ips-archive@odin.ietf.org; Fri, 7 Nov 2003 21:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJHf-0002PN-DU for ips-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 21:57:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19905 for ; Fri, 7 Nov 2003 21:56:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJHc-0007Ja-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 21:57:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIJHc-0007JW-00 for ips-web-archive@ietf.org; Fri, 07 Nov 2003 21:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJHZ-0002ON-G1; Fri, 07 Nov 2003 21:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJ2e-00024B-D2 for ips@optimus.ietf.org; Fri, 07 Nov 2003 21:41:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19567 for ; Fri, 7 Nov 2003 21:41:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJ2b-00079t-00 for ips@ietf.org; Fri, 07 Nov 2003 21:41:33 -0500 Received: from mta4.rcsntx.swbell.net ([151.164.30.28]) by ietf-mx with esmtp (Exim 4.12) id 1AIJ2a-00079q-00 for ips@ietf.org; Fri, 07 Nov 2003 21:41:32 -0500 Received: from DT-Server1.datatransit.com (adsl-67-127-61-146.dsl.pltn13.pacbell.net [67.127.61.146]) by mta4.rcsntx.swbell.net (8.12.10/8.12.10) with SMTP id hA82fWoe027384 for ; Fri, 7 Nov 2003 20:41:32 -0600 (CST) Received: (qmail 12878 invoked from network); 8 Nov 2003 02:41:31 -0000 Received: from unknown (HELO DelliciousGlow) (10.0.0.242) by dt-server1.datatransit.com with SMTP; 8 Nov 2003 02:41:31 -0000 From: "Randy Jennings" To: Cc: "'Yao, Xuebin'" , "'dan yo'" , Subject: RE: [Ips] Full Feature Phase and Digests Date: Fri, 7 Nov 2003 18:41:31 -0800 Message-ID: <000e01c3a5a1$d1811040$f200000a@DelliciousGlow> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > The interesting part here is a AHS that indicates the > digest is beyond > > the end of received data (sent TCP stream). Just something > to keep in > > mind. Don't you love corner cases? > > Doesn't matter. TCP is a stream protocol. The AHS and or the > digest can > come in subsequent frames. :-) However, the data bytes perceived as AHS and digest may not ever, if the length is past what it should be! I suppose that would be either a timeout error or caught by a noop. Sincerely, Randy Jennings Data Transit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 10 13:02:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03409 for ; Mon, 10 Nov 2003 13:02:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGMa-0005kL-Do for ips-archive@odin.ietf.org; Mon, 10 Nov 2003 13:02:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAI28DH022088 for ips-archive@odin.ietf.org; Mon, 10 Nov 2003 13:02:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGMa-0005kB-8A for ips-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 13:02:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03403 for ; Mon, 10 Nov 2003 13:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGMY-0001PH-00 for ips-web-archive@ietf.org; Mon, 10 Nov 2003 13:02:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJGMY-0001PD-00 for ips-web-archive@ietf.org; Mon, 10 Nov 2003 13:02:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGMS-0005j1-Lz; Mon, 10 Nov 2003 13:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGMN-0005iX-IC for ips@optimus.ietf.org; Mon, 10 Nov 2003 13:01:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03393 for ; Mon, 10 Nov 2003 13:01:40 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGML-0001P0-00 for ips@ietf.org; Mon, 10 Nov 2003 13:01:53 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AJGML-0001Ou-00 for ips@ietf.org; Mon, 10 Nov 2003 13:01:53 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 9E23D40135; Mon, 10 Nov 2003 13:01:50 -0500 (EST) Date: Mon, 10 Nov 2003 08:58:33 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: pat_thaler@agilent.com Cc: cbm@rose.hp.com, ips@ietf.org Subject: RE: [Ips] Handling error during packet transmission In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0132E05D5@axcs04.cos.agilent.com> Message-ID: References: <1BEBA5E8600DD4119A50009027AF54A0132E05D5@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , On Fri, 7 Nov 2003 pat_thaler@agilent.com wrote: > Mallikarjun, > > Sending an unsucccessful status applies if it is a SCSI Read. What if it > s a SCSI Write - that is, the initiator is sending the data? Can it > solve the problem by aborting the task? I'd say that the right solution is, "The big hammer." Just as SCSI READ data can get copied into buffers, SCSI WRITE data can get copied into buffers and cause confusion. So I think the answer is that if you're using digests, pad the PDU and send a bad digest. If you aren't, RST the connection. And even if you are using digests, you can RST if you like. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Nov 11 09:45:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02624 for ; Tue, 11 Nov 2003 09:45:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZlZ-0004j4-91 for ips-archive@odin.ietf.org; Tue, 11 Nov 2003 09:45:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABEjDY1018162 for ips-archive@odin.ietf.org; Tue, 11 Nov 2003 09:45:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZlZ-0004ir-4B for ips-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 09:45:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02612 for ; Tue, 11 Nov 2003 09:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZlX-0003tF-00 for ips-web-archive@ietf.org; Tue, 11 Nov 2003 09:45:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJZlW-0003tC-00 for ips-web-archive@ietf.org; Tue, 11 Nov 2003 09:45:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZlO-0004hl-Nr; Tue, 11 Nov 2003 09:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJZlC-0004fj-6N for ips@optimus.ietf.org; Tue, 11 Nov 2003 09:44:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02609; Tue, 11 Nov 2003 09:44:36 -0500 (EST) From: AClarke@attotech.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZl8-0003t5-00; Tue, 11 Nov 2003 09:44:46 -0500 Received: from noteserv1.attotech.com ([12.32.232.51]) by ietf-mx with esmtp (Exim 4.12) id 1AJZl8-0003t1-00; Tue, 11 Nov 2003 09:44:46 -0500 Subject: RE: [Ips] Handling error during packet transmission To: wrstuden@wasabisystems.com Cc: cbm@rose.hp.com, ips@ietf.org, ips-admin@ietf.org, pat_thaler@agilent.com Message-ID: Date: Tue, 11 Nov 2003 09:44:24 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , I think that resetting the connection is the only solution that will always work and will not lead to interoperability problems. It is already specified in sections 3.2.5, and 6.12. Using the combination of bad data and a bad data digest is not equivalent to a reset. You must go through the options in section 6.7 in this case. The connection could still be reset depending on the error recovery level, number of connections, and the iSCSI implementation anyways. What would be the benefit of using the bad digest over reset? If an implementation is incorrect, for example it pads the data but data digest is off, it will be hard to debug or test the flaw and products might get out the door with data integrity problems. Also, digest errors should be rare, the overuse of this type of trick in TCP stacks diminished the usefulness of the TCP checksum. Which is why we have digests in the first place. Aaron wrstuden@wasabis ystems.com To: pat_thaler@agilent.com Sent by: cc: cbm@rose.hp.com, ips@ietf.org ips-admin@ietf.o Subject: RE: [Ips] Handling error during packet transmission rg 11/10/2003 11:58 AM On Fri, 7 Nov 2003 pat_thaler@agilent.com wrote: > Mallikarjun, > > Sending an unsucccessful status applies if it is a SCSI Read. What if it > s a SCSI Write - that is, the initiator is sending the data? Can it > solve the problem by aborting the task? I'd say that the right solution is, "The big hammer." Just as SCSI READ data can get copied into buffers, SCSI WRITE data can get copied into buffers and cause confusion. So I think the answer is that if you're using digests, pad the PDU and send a bad digest. If you aren't, RST the connection. And even if you are using digests, you can RST if you like. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Nov 11 16:08:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22160 for ; Tue, 11 Nov 2003 16:08:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfk7-0005Hi-5E for ips-archive@odin.ietf.org; Tue, 11 Nov 2003 16:08:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABL87nh020308 for ips-archive@odin.ietf.org; Tue, 11 Nov 2003 16:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfk6-0005HT-VF for ips-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 16:08:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22134 for ; Tue, 11 Nov 2003 16:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfk5-0002C8-00 for ips-web-archive@ietf.org; Tue, 11 Nov 2003 16:08:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJfk4-0002C4-00 for ips-web-archive@ietf.org; Tue, 11 Nov 2003 16:08:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfk1-0005Fn-D7; Tue, 11 Nov 2003 16:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfjQ-00055d-RN for ips@optimus.ietf.org; Tue, 11 Nov 2003 16:07:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22126 for ; Tue, 11 Nov 2003 16:07:12 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfjO-0002Br-00 for ips@ietf.org; Tue, 11 Nov 2003 16:07:22 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AJfjO-0002Bo-00 for ips@ietf.org; Tue, 11 Nov 2003 16:07:22 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 53C3540134; Tue, 11 Nov 2003 16:07:22 -0500 (EST) Date: Tue, 11 Nov 2003 12:04:05 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: AClarke@attotech.com Cc: cbm@rose.hp.com, ips@ietf.org, pat_thaler@agilent.com Subject: RE: [Ips] Handling error during packet transmission In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , On Tue, 11 Nov 2003 AClarke@attotech.com wrote: > I think that resetting the connection is the only solution that will always > work and will not lead to interoperability problems. It is already > specified in sections 3.2.5, and 6.12. 3.2.5 certainly leaves the big hammer as an option. However I'm not sure if 6.12 really applies here. The TCP connection is fine, it's the data that are in it that are the problem. > Using the combination of bad data and a bad data digest is not equivalent > to a reset. You must go through the options in section 6.7 in this case. > The connection could still be reset depending on the error recovery level, > number of connections, and the iSCSI implementation anyways. > > What would be the benefit of using the bad digest over reset? If an > implementation is incorrect, for example it pads the data but data digest > is off, it will be hard to debug or test the flaw and products might get > out the door with data integrity problems. As a result of this discussion, I think that sending pad data w/o digests is wrong. Why a bad digest? Because it's less intrusive in theory. Having to use the "big hammer" means that an error with one PDU (which really would mean killing one task) turns into an error on all tasks on that connection. Since you need multiple commands outstanding at once to get line rate (otherwise you see round-trip latency issues), you will most likely have other commands arround to feel the pain of the big hammer. I admit though that chances are initial products will just use the big hammer. > Also, digest errors should be rare, the overuse of this type of trick in > TCP stacks diminished the usefulness of the TCP checksum. Which is why we > have digests in the first place. Huh? The reason we have digests is that the TCP checksum is insensitive to too many multi-bit error patterns. Since it's a sum, if you have a set of bit errors that sum to zero (0->1 transition == + whatever, 1->0 transition == - whatever), you will get the same TCP checksum. Your data are wrong, but the checksum is fine. That's why we have digests. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Nov 11 16:30:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22747 for ; Tue, 11 Nov 2003 16:30:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJg5M-0006sd-UO for ips-archive@odin.ietf.org; Tue, 11 Nov 2003 16:30:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABLU4Ij026441 for ips-archive@odin.ietf.org; Tue, 11 Nov 2003 16:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJg5M-0006sO-Lx for ips-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 16:30:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22704 for ; Tue, 11 Nov 2003 16:29:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJg5K-0002Sn-00 for ips-web-archive@ietf.org; Tue, 11 Nov 2003 16:30:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJg5K-0002Sk-00 for ips-web-archive@ietf.org; Tue, 11 Nov 2003 16:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJg5K-0006rL-0M; Tue, 11 Nov 2003 16:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJg55-0006qu-TG for ips@optimus.ietf.org; Tue, 11 Nov 2003 16:29:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22696 for ; Tue, 11 Nov 2003 16:29:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJg53-0002SW-00 for ips@ietf.org; Tue, 11 Nov 2003 16:29:46 -0500 Received: from [66.155.203.134] (helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1AJg53-0002SD-00 for ips@ietf.org; Tue, 11 Nov 2003 16:29:45 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hABLTApY020536 for ; Tue, 11 Nov 2003 16:29:10 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hABLTAg6020531; Tue, 11 Nov 2003 16:29:10 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id hABLT9703111; Tue, 11 Nov 2003 16:29:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16305.21669.261718.607198@gargle.gargle.HOWL> Date: Tue, 11 Nov 2003 16:29:09 -0500 From: Paul Koning To: wrstuden@wasabisystems.com Cc: AClarke@attotech.com, cbm@rose.hp.com, ips@ietf.org, pat_thaler@agilent.com Subject: RE: [Ips] Handling error during packet transmission References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "wrstuden" == wrstuden writes: wrstuden> Why a bad digest? Because it's less intrusive in wrstuden> theory. Having to use the "big hammer" means that an error wrstuden> with one PDU (which really would mean killing one task) wrstuden> turns into an error on all tasks on that connection. ... Doesn't matter. Optimizing error handling is rarely useful -- only if you have a significant error rate. If the sort of problem we were talking about occurs multiple times per day, you should repair the broken hardware. The performance impact of the recovery for that case is quite uninteresting by comparison. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 13 13:18:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11337 for ; Thu, 13 Nov 2003 13:18:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKM2j-0001Q0-6z for ips-archive@odin.ietf.org; Thu, 13 Nov 2003 13:18:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADII99U005446 for ips-archive@odin.ietf.org; Thu, 13 Nov 2003 13:18:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKM2i-0001Pl-Vm for ips-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 13:18:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11313 for ; Thu, 13 Nov 2003 13:17:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKM2h-0002Cp-00 for ips-web-archive@ietf.org; Thu, 13 Nov 2003 13:18:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKM2g-0002Cl-00 for ips-web-archive@ietf.org; Thu, 13 Nov 2003 13:18:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKM2b-0001Nw-GB; Thu, 13 Nov 2003 13:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKM1g-0001NL-1S for ips@optimus.ietf.org; Thu, 13 Nov 2003 13:17:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11293; Thu, 13 Nov 2003 13:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKM1d-0002CE-00; Thu, 13 Nov 2003 13:17:01 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1AKM1d-0002CB-00; Thu, 13 Nov 2003 13:17:01 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel10.hp.com (Postfix) with ESMTP id 1286B1C02534; Thu, 13 Nov 2003 10:17:00 -0800 (PST) Received: from swathi.rose.hp.com (dhcp-roseor-bec059.rose.hp.com [15.23.142.59]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id KAA14734; Thu, 13 Nov 2003 10:16:59 -0800 (PST) Message-Id: <6.0.0.22.1.20031113101359.02a898a0@rosemail.rose.hp.com> X-Sender: cbm@rosemail.rose.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 13 Nov 2003 10:16:58 -0800 To: ips@ietf.org, rddp@ietf.org From: "Mallikarjun C." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ips] iSCSI/RDMA slides from IETF-58 Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , All: The iSCSI/RDMA (DA and iSER) slides I presented in the RDDP WG meeting at IETF-58 in Minneapolis are posted at: http://storage-arch.hp.com/iSCSI_over_RDMA_IETF_58.pdf -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard, Roseville cbm [at] rose.hp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 14 14:39:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25811 for ; Fri, 14 Nov 2003 14:39:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjmd-0002bp-EE for ips-archive@odin.ietf.org; Fri, 14 Nov 2003 14:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEJd7gf010023 for ips-archive@odin.ietf.org; Fri, 14 Nov 2003 14:39:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjmd-0002ba-9n for ips-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 14:39:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25796 for ; Fri, 14 Nov 2003 14:38:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjma-0003FY-00 for ips-web-archive@ietf.org; Fri, 14 Nov 2003 14:39:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKjma-0003FU-00 for ips-web-archive@ietf.org; Fri, 14 Nov 2003 14:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjmX-0002aX-P8; Fri, 14 Nov 2003 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjmS-0002aF-3i for ips@optimus.ietf.org; Fri, 14 Nov 2003 14:38:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25788 for ; Fri, 14 Nov 2003 14:38:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjmP-0003FL-00 for ips@ietf.org; Fri, 14 Nov 2003 14:38:53 -0500 Received: from web20712.mail.yahoo.com ([66.163.169.153]) by ietf-mx with smtp (Exim 4.12) id 1AKjmO-0003FI-00 for ips@ietf.org; Fri, 14 Nov 2003 14:38:52 -0500 Message-ID: <20031114193852.83806.qmail@web20712.mail.yahoo.com> Received: from [66.243.153.70] by web20712.mail.yahoo.com via HTTP; Fri, 14 Nov 2003 11:38:52 PST Date: Fri, 14 Nov 2003 11:38:52 -0800 (PST) From: dan yo To: ips@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-868416693-1068838732=:79930" Subject: [Ips] [Ips]target online notification Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , --0-868416693-1068838732=:79930 Content-Type: text/plain; charset=us-ascii Hi, Suppose a host is connected to a target (discovered earlier through SendTargets) and the target goes offline. When the target comes back online, is there a way in the iSCSI protocol to tell the host about it (other than using SCN in iSNS)? or does the host have to do busy retry? I am particularly interested in how the Microsoft iSCSI stack handles this situation. Thanks. --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-868416693-1068838732=:79930 Content-Type: text/html; charset=us-ascii
Hi,
Suppose a host is connected to a target (discovered earlier through SendTargets) and the target goes offline.  When the target comes back online, is there a way in the iSCSI protocol to tell the host about it (other than using SCN in iSNS)?  or does the host have to do busy retry?  I am particularly interested in how the Microsoft iSCSI stack handles this situation.
Thanks.

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-868416693-1068838732=:79930-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 14 14:51:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26147 for ; Fri, 14 Nov 2003 14:51:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjyB-0003L9-Ju for ips-archive@odin.ietf.org; Fri, 14 Nov 2003 14:51:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEJp3MK012833 for ips-archive@odin.ietf.org; Fri, 14 Nov 2003 14:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjyB-0003Ku-Fk for ips-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 14:51:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26139 for ; Fri, 14 Nov 2003 14:50:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjy8-0003P3-00 for ips-web-archive@ietf.org; Fri, 14 Nov 2003 14:51:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKjy8-0003P0-00 for ips-web-archive@ietf.org; Fri, 14 Nov 2003 14:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjy9-0003Iz-DG; Fri, 14 Nov 2003 14:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjxi-0003IL-H2 for ips@optimus.ietf.org; Fri, 14 Nov 2003 14:50:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26130 for ; Fri, 14 Nov 2003 14:50:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjxf-0003OZ-00 for ips@ietf.org; Fri, 14 Nov 2003 14:50:31 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AKjxe-0003OW-00 for ips@ietf.org; Fri, 14 Nov 2003 14:50:30 -0500 Received: from phys-giza-1 ([129.147.4.102]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAEJo0xA026609 for ; Fri, 14 Nov 2003 11:50:00 -0800 (PST) Received: from sun.com (dhcp-ubrm05-50-163.Central.Sun.COM [129.147.50.163]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HOC00JEZXRBO7@giza-mail1.Central.Sun.COM> for ips@ietf.org; Fri, 14 Nov 2003 12:49:59 -0700 (MST) Date: Fri, 14 Nov 2003 12:50:34 -0700 From: Paul von Behren Subject: Re: [Ips] [Ips]target online notification In-reply-to: <20031114193852.83806.qmail@web20712.mail.yahoo.com> To: dan yo Cc: ips@ietf.org Message-id: <3FB5320A.4070407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 References: <20031114193852.83806.qmail@web20712.mail.yahoo.com> Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There's a related question for LUN configuration changes - suppose the target is a RAID array and someone creates a LUN, or changes it's visibility with LUN masking. Is there some mechanism the array can use to tell the host drivers to look for changes in the LUN configuration. In FCP, this is often done with a LIP or RSCN. Does iSCSI allow a target to send an SCN to initiators? thanks, Paul dan yo wrote: > Hi, > Suppose a host is connected to a target (discovered earlier through > SendTargets) and the target goes offline. When the target comes back > online, is there a way in the iSCSI protocol to tell the host about it > (other than using SCN in iSNS)? or does the host have to do busy > retry? I am particularly interested in how the Microsoft iSCSI stack > handles this situation. > Thanks. > > ------------------------------------------------------------------------ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Nov 15 11:29:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12116 for ; Sat, 15 Nov 2003 11:29:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL3IR-0007aT-Nz for ips-archive@odin.ietf.org; Sat, 15 Nov 2003 11:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAFGTFA2029162 for ips-archive@odin.ietf.org; Sat, 15 Nov 2003 11:29:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL3IR-0007aH-H8 for ips-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 11:29:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12093 for ; Sat, 15 Nov 2003 11:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL3IO-0001ru-00 for ips-web-archive@ietf.org; Sat, 15 Nov 2003 11:29:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AL3IO-0001rr-00 for ips-web-archive@ietf.org; Sat, 15 Nov 2003 11:29:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL3ID-0007ZJ-OW; Sat, 15 Nov 2003 11:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL3Hp-0007Yj-Hw for ips@optimus.ietf.org; Sat, 15 Nov 2003 11:28:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12037 for ; Sat, 15 Nov 2003 11:28:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL3Hm-0001qY-00 for ips@ietf.org; Sat, 15 Nov 2003 11:28:34 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1AL3Hl-0001pw-00 for ips@ietf.org; Sat, 15 Nov 2003 11:28:33 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAFGRt5k066922 for ; Sat, 15 Nov 2003 16:27:55 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAFGRspw196174 for ; Sat, 15 Nov 2003 17:27:54 +0100 To: ips@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Julian Satran Message-ID: Date: Sat, 15 Nov 2003 10:27:48 -0600 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 15/11/2003 18:27:54, Serialize complete at 15/11/2003 18:27:54 Content-Type: multipart/alternative; boundary="=_alternative 005A6D6386256DDF_=" Subject: [Ips] (no subject) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 005A6D6386256DDF_= Content-Type: text/plain; charset="US-ASCII" There was a heated debate on the target. A discovery session is meant to make such support available. You may want to use out-of-band management mechanisms for this type of events. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 15/11/2003 10:26 ----- dan yo Sent by: ips-admin@ietf.org 14/11/2003 13:38 To ips@ietf.org cc Subject [Ips] [Ips]target online notification Hi, Suppose a host is connected to a target (discovered earlier through SendTargets) and the target goes offline. When the target comes back online, is there a way in the iSCSI protocol to tell the host about it (other than using SCN in iSNS)? or does the host have to do busy retry? I am particularly interested in how the Microsoft iSCSI stack handles this situation. Thanks. Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard ----- Forwarded by Julian Satran/Haifa/IBM on 15/11/2003 10:26 ----- Paul von Behren Sent by: ips-admin@ietf.org 14/11/2003 13:50 To dan yo cc ips@ietf.org Subject Re: [Ips] [Ips]target online notification There's a related question for LUN configuration changes - suppose the target is a RAID array and someone creates a LUN, or changes it's visibility with LUN masking. Is there some mechanism the array can use to tell the host drivers to look for changes in the LUN configuration. In FCP, this is often done with a LIP or RSCN. Does iSCSI allow a target to send an SCN to initiators? thanks, Paul dan yo wrote: > Hi, > Suppose a host is connected to a target (discovered earlier through > SendTargets) and the target goes offline. When the target comes back > online, is there a way in the iSCSI protocol to tell the host about it > (other than using SCN in iSNS)? or does the host have to do busy > retry? I am particularly interested in how the Microsoft iSCSI stack > handles this situation. > Thanks. > > ------------------------------------------------------------------------ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005A6D6386256DDF_= Content-Type: text/html; charset="US-ASCII"
There was a heated debate on the target. A discovery session is meant to make such support available. You may want to use out-of-band management mechanisms for this type of events.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 15/11/2003 10:26 -----
dan yo <ipsandude@yahoo.com>
Sent by: ips-admin@ietf.org

14/11/2003 13:38

To
ips@ietf.org
cc
Subject
[Ips] [Ips]target online notification





Hi,
Suppose a host is connected to a target (discovered earlier through SendTargets) and the target goes offline.  When the target comes back online, is there a way in the iSCSI protocol to tell the host about it (other than using SCN in iSNS)?  or does the host have to do busy retry?  I am particularly interested in how the Microsoft iSCSI stack handles this situation.
Thanks.

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
----- Forwarded by Julian Satran/Haifa/IBM on 15/11/2003 10:26 -----
Paul von Behren <Paul.Vonbehren@Sun.COM>
Sent by: ips-admin@ietf.org

14/11/2003 13:50

To
dan yo <ipsandude@yahoo.com>
cc
ips@ietf.org
Subject
Re: [Ips] [Ips]target online notification





There's a related question for LUN configuration changes - suppose
the target is a RAID array and someone creates a LUN, or changes
it's visibility with LUN masking.  Is there some mechanism the
array can use to tell the host drivers to look for changes
in the LUN configuration.  In FCP, this is often done with
a LIP or RSCN.  Does iSCSI allow a target to send an SCN to
initiators?

thanks,
Paul

dan yo wrote:

> Hi,
> Suppose a host is connected to a target (discovered earlier through
> SendTargets) and the target goes offline.  When the target comes back
> online, is there a way in the iSCSI protocol to tell the host about it
> (other than using SCN in iSNS)?  or does the host have to do busy
> retry?  I am particularly interested in how the Microsoft iSCSI stack
> handles this situation.
> Thanks.
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> <http://antispam.yahoo.com/whatsnewfree>


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 005A6D6386256DDF_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 13:31:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27197 for ; Mon, 17 Nov 2003 13:31:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALo9f-0005XK-4t for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 13:31:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHIVJgX021278 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 13:31:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALo9e-0005X7-Vx for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 13:31:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27189 for ; Mon, 17 Nov 2003 13:31:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALo9c-0003up-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 13:31:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALo9c-0003ul-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 13:31:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALo9N-0005W0-Kv; Mon, 17 Nov 2003 13:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALo8P-0005T6-KR for ips@optimus.ietf.org; Mon, 17 Nov 2003 13:30:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27153 for ; Mon, 17 Nov 2003 13:29:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALo8N-0003sF-00 for ips@ietf.org; Mon, 17 Nov 2003 13:29:59 -0500 Received: from adsl-63-206-199-11.dsl.snfc21.pacbell.net ([63.206.199.11] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1ALo8N-0003rX-00 for ips@ietf.org; Mon, 17 Nov 2003 13:29:59 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1ALnyP-0004St-00; Mon, 17 Nov 2003 10:19:41 -0800 From: "Nicholas A. Bellinger" To: ips@ietf.org, Julian_Satran@il.ibm.com Content-Type: text/plain Message-Id: <1069093178.16486.34.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 17 Nov 2003 10:19:38 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementations Draft Interest? Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greetings All, I am inquiring about interest in seeing a draft and possibly RFC regarding Considerations for Asymmetric iSCSI Implementations. I recall seeing some discussion on this topic back in 2000, and aside from a few other mentions of the model in various design documents I have not seen any followups. I am curious if the model had all but been abandoned for the symmetric model in traditional and iSER iSCSI, or if there is still room in the protocol for asymmetric operations? I have been thinking about this topic for a while and specifically its affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some feedback from list members if it would be worthwhile for someone (mabye even me!) to put the thoughts down for other interested parties to consider. Aside from the expected responses of complexity issues for simple implementations, I do not see a terrible amount of extra functionality required for ErrorRecoveryLevel=1 and above implementations to operate in an Asymmetric model, and literally no changes to RFC 3347. As to the benefits of running in a Asymmetric model I can only speculate, although I suppose most are related performance in multiple connection ErrorRecoveryLevel=1 and above software implementations. Any feedback is welcome! -- Nicholas A. Bellinger _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 14:18:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29003 for ; Mon, 17 Nov 2003 14:18:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALosv-00082B-P7 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 14:18:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHJI5X4030877 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 14:18:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALosv-00081w-J6 for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 14:18:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28970 for ; Mon, 17 Nov 2003 14:17:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALosr-0004Yl-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 14:18:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALosr-0004Yi-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 14:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALosr-00080U-JK; Mon, 17 Nov 2003 14:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALos0-0007zj-2q for ips@optimus.ietf.org; Mon, 17 Nov 2003 14:17:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28925 for ; Mon, 17 Nov 2003 14:16:55 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALorx-0004Y3-00 for ips@ietf.org; Mon, 17 Nov 2003 14:17:05 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1ALorx-0004Y0-00 for ips@ietf.org; Mon, 17 Nov 2003 14:17:05 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id E692E23DBB; Mon, 17 Nov 2003 12:17:04 -0700 (MST) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by relcos1.cos.agilent.com (Postfix) with SMTP id CC9D04C; Mon, 17 Nov 2003 12:17:04 -0700 (MST) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Nov 2003 12:17:04 -0700 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 12:17:04 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0132E05E4@axcs04.cos.agilent.com> To: nick@pyxtechnologies.com, ips@ietf.org, Julian_Satran@il.ibm.com Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? Date: Mon, 17 Nov 2003 12:17:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , I'm not clear on what you mean by "asymetric". -----Original Message----- From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] Sent: Monday, November 17, 2003 10:20 AM To: ips@ietf.org; Julian_Satran@il.ibm.com Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementations Draft Interest? Greetings All, I am inquiring about interest in seeing a draft and possibly RFC regarding Considerations for Asymmetric iSCSI Implementations. I recall seeing some discussion on this topic back in 2000, and aside from a few other mentions of the model in various design documents I have not seen any followups. I am curious if the model had all but been abandoned for the symmetric model in traditional and iSER iSCSI, or if there is still room in the protocol for asymmetric operations? I have been thinking about this topic for a while and specifically its affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some feedback from list members if it would be worthwhile for someone (mabye even me!) to put the thoughts down for other interested parties to consider. Aside from the expected responses of complexity issues for simple implementations, I do not see a terrible amount of extra functionality required for ErrorRecoveryLevel=1 and above implementations to operate in an Asymmetric model, and literally no changes to RFC 3347. As to the benefits of running in a Asymmetric model I can only speculate, although I suppose most are related performance in multiple connection ErrorRecoveryLevel=1 and above software implementations. Any feedback is welcome! -- Nicholas A. Bellinger _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 14:50:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00781 for ; Mon, 17 Nov 2003 14:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpO0-0001pc-0N for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 14:50:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHJoBdu007040 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 14:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpNz-0001o2-M7 for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 14:50:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00741 for ; Mon, 17 Nov 2003 14:49:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpNw-00056s-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 14:50:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALpNw-00056p-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 14:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpNq-0001md-WE; Mon, 17 Nov 2003 14:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpHi-00018C-NW for ips@optimus.ietf.org; Mon, 17 Nov 2003 14:43:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00083 for ; Mon, 17 Nov 2003 14:43:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpHf-0004vW-00 for ips@ietf.org; Mon, 17 Nov 2003 14:43:39 -0500 Received: from astound-64-85-224-253.ca.astound.net ([64.85.224.253] helo=master.linux-ide.org) by ietf-mx with esmtp (Exim 4.12) id 1ALpHf-0004vO-00 for ips@ietf.org; Mon, 17 Nov 2003 14:43:39 -0500 Received: from localhost (andre@localhost) by master.linux-ide.org (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id hAHJgMP29834; Mon, 17 Nov 2003 11:42:22 -0800 Date: Mon, 17 Nov 2003 11:42:22 -0800 (PST) From: Andre Hedrick X-Sender: andre@master.linux-ide.org To: pat_thaler@agilent.com cc: nick@pyxtechnologies.com, ips@ietf.org, Julian_Satran@il.ibm.com Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0132E05E4@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Pat: A simple method of spliting the command and data transports over their own respective connections. It is clear the command layer transactions will arrive before the following data transactions. There are obvious reason to split the layers, yet they generate a new level of error recovery. The principle reason to split the two is based on performance by allowing the target to prebuild buffers to optimize memory management and io scheduling events. PyX will present such a model for the next version of the iSCSI RFC. There are no patents involved, and this conforms to the goals of IETF. Regards, Andre On Mon, 17 Nov 2003 pat_thaler@agilent.com wrote: > I'm not clear on what you mean by "asymetric". > > -----Original Message----- > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > Sent: Monday, November 17, 2003 10:20 AM > To: ips@ietf.org; Julian_Satran@il.ibm.com > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > Implementations Draft Interest? > > > Greetings All, > > I am inquiring about interest in seeing a draft and possibly RFC > regarding Considerations for Asymmetric iSCSI Implementations. I recall > seeing some discussion on this topic back in 2000, and aside from a few > other mentions of the model in various design documents I have not seen > any followups. I am curious if the model had all but been abandoned for > the symmetric model in traditional and iSER iSCSI, or if there is still > room in the protocol for asymmetric operations? > > I have been thinking about this topic for a while and specifically its > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some > feedback from list members if it would be worthwhile for someone (mabye > even me!) to put the thoughts down for other interested parties to > consider. > > Aside from the expected responses of complexity issues for simple > implementations, I do not see a terrible amount of extra functionality > required for ErrorRecoveryLevel=1 and above implementations to operate > in an Asymmetric model, and literally no changes to RFC 3347. As to the > benefits of running in a Asymmetric model I can only speculate, > although I suppose most are related performance in multiple connection > ErrorRecoveryLevel=1 and above software implementations. > > Any feedback is welcome! > > -- > Nicholas A. Bellinger > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 15:13:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02709 for ; Mon, 17 Nov 2003 15:13:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpk5-0003OI-Up for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 15:13:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHKD1q9013028 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 15:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpk5-0003O3-Ok for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 15:13:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02639 for ; Mon, 17 Nov 2003 15:12:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpk4-0005UE-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 15:13:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALpk4-0005UB-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 15:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpk3-0003N3-Ql; Mon, 17 Nov 2003 15:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpjQ-0003L1-Kh for ips@optimus.ietf.org; Mon, 17 Nov 2003 15:12:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02553 for ; Mon, 17 Nov 2003 15:12:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpjP-0005Tp-00 for ips@ietf.org; Mon, 17 Nov 2003 15:12:19 -0500 Received: from adsl-63-206-199-11.dsl.snfc21.pacbell.net ([63.206.199.11] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1ALpjO-0005Sw-00 for ips@ietf.org; Mon, 17 Nov 2003 15:12:18 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1ALpZQ-0004Um-00; Mon, 17 Nov 2003 12:02:00 -0800 Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? From: "Nicholas A. Bellinger" To: pat_thaler@agilent.com Cc: ips@ietf.org, Julian Satran In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0132E05E4@axcs04.cos.agilent.com> References: <1BEBA5E8600DD4119A50009027AF54A0132E05E4@axcs04.cos.agilent.com> Content-Type: text/plain Message-Id: <1069099316.16485.66.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 17 Nov 2003 12:01:57 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat, http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf The following paper from Kalman Meth decribes them on page 12: Asymmetric: Single Control Channel / iSCSI Connection. Multiple Data Channels / iSCSI Connection. Control Channel used to transfer commands, status, and task management. Symmetric: All Channels / iSCSI Connections identical. Send Data and Status over same Channel / iSCSI Connection as corresponding command. I am not exactly sure why the single control channel restriction was imposed in the asymmetric case, but imagine its no longer an issue to have multiple control channels. Perhaps this was before the advent of session wide CmdSN ordering? Some of the more interesting questions: Connection recovery case, which connection an inflight command is alligent to when the control and/or data connection fails. Requirements for falling back when an session runs out of control and/or data channels. Or is it just easier to do session reinstatement into an symmetric session. How strict are the requirements for data on the control channel and control primatives in the data channel? Immediate DataOut comes to mind in the former case, and Phase Collapse for DataIn in the latter. Thanks! On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote: > I'm not clear on what you mean by "asymetric". > > -----Original Message----- > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > Sent: Monday, November 17, 2003 10:20 AM > To: ips@ietf.org; Julian_Satran@il.ibm.com > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > Implementations Draft Interest? > > > Greetings All, > > I am inquiring about interest in seeing a draft and possibly RFC > regarding Considerations for Asymmetric iSCSI Implementations. I recall > seeing some discussion on this topic back in 2000, and aside from a few > other mentions of the model in various design documents I have not seen > any followups. I am curious if the model had all but been abandoned for > the symmetric model in traditional and iSER iSCSI, or if there is still > room in the protocol for asymmetric operations? > > I have been thinking about this topic for a while and specifically its > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some > feedback from list members if it would be worthwhile for someone (mabye > even me!) to put the thoughts down for other interested parties to > consider. > > Aside from the expected responses of complexity issues for simple > implementations, I do not see a terrible amount of extra functionality > required for ErrorRecoveryLevel=1 and above implementations to operate > in an Asymmetric model, and literally no changes to RFC 3347. As to the > benefits of running in a Asymmetric model I can only speculate, > although I suppose most are related performance in multiple connection > ErrorRecoveryLevel=1 and above software implementations. > > Any feedback is welcome! > > -- > Nicholas A. Bellinger > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips -- Nicholas A. Bellinger _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 16:41:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07072 for ; Mon, 17 Nov 2003 16:41:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr7R-00086B-6M for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 16:41:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHLfDcs031127 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 16:41:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr7R-00085y-09 for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 16:41:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07048 for ; Mon, 17 Nov 2003 16:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALr7P-0006pk-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 16:41:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALr7O-0006ph-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 16:41:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr7F-00083S-Oq; Mon, 17 Nov 2003 16:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr6g-00080v-3S for ips@optimus.ietf.org; Mon, 17 Nov 2003 16:40:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07014 for ; Mon, 17 Nov 2003 16:40:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALr6e-0006pG-00 for ips@ietf.org; Mon, 17 Nov 2003 16:40:24 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1ALr6c-0006oa-00 for ips@ietf.org; Mon, 17 Nov 2003 16:40:22 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAHLdhkF218848; Mon, 17 Nov 2003 16:39:43 -0500 Received: from d03nm115.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAHLdfwR080570; Mon, 17 Nov 2003 14:39:42 -0700 To: "Nicholas A. Bellinger" Cc: ips@ietf.org, ips-admin@ietf.org, Julian Satran , pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: [Ips] : Considerations for Asymmetric iSCSI Implementati ons Draft Interest? X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: John Hufferd Message-ID: Date: Mon, 17 Nov 2003 13:26:10 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.2CF2HF92 | October 15, 2003) at 11/17/2003 14:39:42, Serialize complete at 11/17/2003 14:39:42 Content-Type: multipart/alternative; boundary="=_alternative 0075AB4488256DE1_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0075AB4488256DE1_= Content-Type: text/plain; charset="us-ascii" I am not sure why we would ever want to do this. How does this improve the performance over normal Multiple Connections per Session? And what is the projected improvement (%)? . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Nicholas A. Bellinger" Sent by: ips-admin@ietf.org 11/17/2003 12:01 PM To: pat_thaler@agilent.com cc: ips@ietf.org, Julian Satran Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? Pat, http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf The following paper from Kalman Meth decribes them on page 12: Asymmetric: Single Control Channel / iSCSI Connection. Multiple Data Channels / iSCSI Connection. Control Channel used to transfer commands, status, and task management. Symmetric: All Channels / iSCSI Connections identical. Send Data and Status over same Channel / iSCSI Connection as corresponding command. I am not exactly sure why the single control channel restriction was imposed in the asymmetric case, but imagine its no longer an issue to have multiple control channels. Perhaps this was before the advent of session wide CmdSN ordering? Some of the more interesting questions: Connection recovery case, which connection an inflight command is alligent to when the control and/or data connection fails. Requirements for falling back when an session runs out of control and/or data channels. Or is it just easier to do session reinstatement into an symmetric session. How strict are the requirements for data on the control channel and control primatives in the data channel? Immediate DataOut comes to mind in the former case, and Phase Collapse for DataIn in the latter. Thanks! On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote: > I'm not clear on what you mean by "asymetric". > > -----Original Message----- > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > Sent: Monday, November 17, 2003 10:20 AM > To: ips@ietf.org; Julian_Satran@il.ibm.com > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > Implementations Draft Interest? > > > Greetings All, > > I am inquiring about interest in seeing a draft and possibly RFC > regarding Considerations for Asymmetric iSCSI Implementations. I recall > seeing some discussion on this topic back in 2000, and aside from a few > other mentions of the model in various design documents I have not seen > any followups. I am curious if the model had all but been abandoned for > the symmetric model in traditional and iSER iSCSI, or if there is still > room in the protocol for asymmetric operations? > > I have been thinking about this topic for a while and specifically its > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some > feedback from list members if it would be worthwhile for someone (mabye > even me!) to put the thoughts down for other interested parties to > consider. > > Aside from the expected responses of complexity issues for simple > implementations, I do not see a terrible amount of extra functionality > required for ErrorRecoveryLevel=1 and above implementations to operate > in an Asymmetric model, and literally no changes to RFC 3347. As to the > benefits of running in a Asymmetric model I can only speculate, > although I suppose most are related performance in multiple connection > ErrorRecoveryLevel=1 and above software implementations. > > Any feedback is welcome! > > -- > Nicholas A. Bellinger > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips -- Nicholas A. Bellinger _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0075AB4488256DE1_= Content-Type: text/html; charset="us-ascii"
I am not sure why we would ever want to do this.  How does this improve the performance over normal Multiple Connections per Session?  And what is the projected improvement (%)?
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


"Nicholas A. Bellinger" <nick@pyxtechnologies.com>
Sent by: ips-admin@ietf.org

11/17/2003 12:01 PM

       
        To:        pat_thaler@agilent.com
        cc:        ips@ietf.org, Julian Satran <Julian_Satran@il.ibm.com>
        Subject:        RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati        ons Draft Interest?



Pat,

http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf

The following paper from Kalman Meth decribes them on page 12:

Asymmetric:
Single Control Channel / iSCSI Connection.

Multiple Data Channels / iSCSI Connection.

Control Channel used to transfer commands, status, and task management.

Symmetric:
All Channels / iSCSI Connections identical.

Send Data and Status over same Channel / iSCSI Connection as  
corresponding command.



I am not exactly sure why the single control channel restriction was
imposed in the asymmetric case, but imagine its no longer an issue to
have multiple control channels.  Perhaps this was before the advent of
session wide CmdSN ordering?

Some of the more interesting questions:

Connection recovery case, which connection an inflight command is
alligent to when the control and/or data connection fails.

Requirements for falling back when an session runs out of control and/or
data channels.  Or is it just easier to do session reinstatement into
an symmetric session.

How strict are the requirements for data on the control channel and
control primatives in the data channel?  Immediate DataOut comes to mind
in the former case, and Phase Collapse for DataIn in the latter.

Thanks!

On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote:
> I'm not clear on what you mean by "asymetric".
>
> -----Original Message-----
> From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com]
> Sent: Monday, November 17, 2003 10:20 AM
> To: ips@ietf.org; Julian_Satran@il.ibm.com
> Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI
> Implementations Draft Interest?
>
>
> Greetings All,
>                  
>                  I am inquiring about interest in seeing a draft and possibly RFC
> regarding Considerations for Asymmetric iSCSI Implementations.  I recall
> seeing some discussion on this topic back in 2000, and aside from a few
> other mentions of the model in various design documents I have not seen
> any followups.  I am curious if the model had all but been abandoned for
> the symmetric model in traditional and iSER iSCSI, or if there is still
> room in the protocol for asymmetric operations?
>
> I have been thinking about this topic for a while and specifically its
> affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some
> feedback from list members if it would be worthwhile for someone (mabye
> even me!) to put the thoughts down for other interested parties to
> consider.
>
> Aside from the expected responses of complexity issues for simple
> implementations,  I do not see a terrible amount of extra functionality
> required for ErrorRecoveryLevel=1 and above implementations to operate
> in an Asymmetric model, and literally no changes to RFC 3347.  As to the
> benefits of running in a Asymmetric model I can only speculate,
> although I suppose most are related performance in multiple connection
> ErrorRecoveryLevel=1 and above software implementations.
>
> Any feedback is welcome!                
>
> --
> Nicholas A. Bellinger <nick@pyxtechnologies.com>
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
--
Nicholas A. Bellinger <nick@pyxtechnologies.com>


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

--=_alternative 0075AB4488256DE1_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 16:43:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07196 for ; Mon, 17 Nov 2003 16:43:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr9G-0008Fx-At for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 16:43:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHLh6ic031731 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 16:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr9F-0008EZ-E7 for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 16:43:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07176 for ; Mon, 17 Nov 2003 16:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALr9D-0006rX-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 16:43:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALr9D-0006rS-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 16:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr9D-0008Cq-U0; Mon, 17 Nov 2003 16:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr8f-0008Bk-TA for ips@optimus.ietf.org; Mon, 17 Nov 2003 16:42:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07148 for ; Mon, 17 Nov 2003 16:42:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALr8d-0006r7-00 for ips@ietf.org; Mon, 17 Nov 2003 16:42:27 -0500 Received: from [66.155.203.134] (helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1ALr8d-0006qH-00 for ips@ietf.org; Mon, 17 Nov 2003 16:42:27 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hAHLfrpW008573 for ; Mon, 17 Nov 2003 16:41:53 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hAHLfqg6008568; Mon, 17 Nov 2003 16:41:52 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id hAHLfpV16917; Mon, 17 Nov 2003 16:41:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16313.16543.839025.41894@gargle.gargle.HOWL> Date: Mon, 17 Nov 2003 16:41:51 -0500 From: Paul Koning To: andre@pyxtechnologies.com Cc: pat_thaler@agilent.com, nick@pyxtechnologies.com, ips@ietf.org, Julian_Satran@il.ibm.com Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? References: <1BEBA5E8600DD4119A50009027AF54A0132E05E4@axcs04.cos.agilent.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Andre" == Andre Hedrick writes: Andre> Pat: Andre> A simple method of spliting the command and data transports Andre> over their own respective connections. It is clear the Andre> command layer transactions will arrive before the following Andre> data transactions. Is it? If immediate or unsolicited data flows over data connections, then this doesn't seem to be true. Andre> There are obvious reason to split the layers... Do you have examples of such reasons? paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 17:12:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09012 for ; Mon, 17 Nov 2003 17:12:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrbM-00027A-Af for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 17:12:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHMC8qx008122 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 17:12:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrbM-00026v-3t for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 17:12:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08975 for ; Mon, 17 Nov 2003 17:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrbJ-0007Z0-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 17:12:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALrbJ-0007Yx-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 17:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrbF-00025w-4a; Mon, 17 Nov 2003 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrTl-000191-Df for ips@optimus.ietf.org; Mon, 17 Nov 2003 17:04:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08469 for ; Mon, 17 Nov 2003 17:04:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrTi-0007NW-00 for ips@ietf.org; Mon, 17 Nov 2003 17:04:14 -0500 Received: from astound-64-85-224-253.ca.astound.net ([64.85.224.253] helo=master.linux-ide.org) by ietf-mx with esmtp (Exim 4.12) id 1ALrTT-0007MZ-00 for ips@ietf.org; Mon, 17 Nov 2003 17:03:59 -0500 Received: from localhost (andre@localhost) by master.linux-ide.org (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id hAHM2PE30463; Mon, 17 Nov 2003 14:02:26 -0800 Date: Mon, 17 Nov 2003 14:02:25 -0800 (PST) From: Andre Hedrick X-Sender: andre@master.linux-ide.org To: Paul Koning cc: andre@pyxtechnologies.com, pat_thaler@agilent.com, nick@pyxtechnologies.com, ips@ietf.org, Julian_Satran@il.ibm.com Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? In-Reply-To: <16313.16543.839025.41894@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , On Mon, 17 Nov 2003, Paul Koning wrote: > >>>>> "Andre" == Andre Hedrick writes: > > Andre> Pat: > > Andre> A simple method of spliting the command and data transports > Andre> over their own respective connections. It is clear the > Andre> command layer transactions will arrive before the following > Andre> data transactions. > > Is it? If immediate or unsolicited data flows over data connections, > then this doesn't seem to be true. You missed the point of a possible addition of error recovery and in a split path model, the immediate/unsolicited data are points which conflict. These may be excepts or a new behavior to be set into a new FSM. > Andre> There are obvious reason to split the layers... > > Do you have examples of such reasons? Simple rules of multi path or raid extentions requiring specific sizes/break points of memory buffers for host side operations There are many reasons on the storage side to have earily knowledge of the expected incoming command. Surely it is obvious the huge assist a target would gain in managing transactions and commits to real/virtual platters. Multi path operations gains are potentially huge. Well maybe it is not time until everyone has deployed ERL 2. Cheers, Andre _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 17:25:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09874 for ; Mon, 17 Nov 2003 17:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrny-0003Su-4F for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 17:25:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHMPAE3013316 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 17:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrny-0003Sh-0W for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 17:25:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09827 for ; Mon, 17 Nov 2003 17:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrnv-00001Y-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 17:25:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALrnv-00001V-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 17:25:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrns-0003OA-30; Mon, 17 Nov 2003 17:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrnd-0003Lx-Jv for ips@optimus.ietf.org; Mon, 17 Nov 2003 17:24:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09800 for ; Mon, 17 Nov 2003 17:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrnb-00000q-00 for ips@ietf.org; Mon, 17 Nov 2003 17:24:47 -0500 Received: from mta3.wss.scd.yahoo.com ([66.218.85.34]) by ietf-mx with esmtp (Exim 4.12) id 1ALrna-0007no-00 for ips@ietf.org; Mon, 17 Nov 2003 17:24:46 -0500 Received: from igor.muttsnuts.com (81.129.21.210) by mta3.wss.scd.yahoo.com (7.0.016) (authenticated as marke@muttsnuts.com) id 3F61636001C6E2F5 for ips@ietf.org; Mon, 17 Nov 2003 14:24:15 -0800 Message-Id: <6.0.0.22.2.20031117220640.040795e0@mail.muttsnuts.com> X-Sender: marke%muttsnuts.com@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 17 Nov 2003 22:24:11 +0000 To: ips@ietf.org From: "Mark S. Edwards" Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? In-Reply-To: <1069099316.16485.66.camel@subjekt.volcom.net> References: <1BEBA5E8600DD4119A50009027AF54A0132E05E4@axcs04.cos.agilent.com> <1069099316.16485.66.camel@subjekt.volcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="0"; format=flowed Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , I can't access the doc you reference, but I believe that it is very old and part of the idea bouncing during the early stages of iSCSI. I've been trying to remember the various discussions at the time as to the pro's and con's of the different models, but I do remember that I was quite opposed to this one largely due to the pain of what happens if one or other of the control or data plane fabrics breaks. Remember, any IETF based solution MUST be scalable to the Internet. Stuff that works when two hosts are side by side in a data centre has a habit of biting back when they are on opposite sides of the World. The earliest reference I have in my mail store goes back April 2001 and the Last Call discussions on the requirements document. There were a couple of emails asking Marjorie and team to remove the connection model discussions. This was particularly apt from Bob Snively and also tells you where to trawl for further enlightenment on the original discussions, presumably there may be some IPS meeting notes on this in there, too. >6) ALTERNATE CONNECTION BINDING > > The section in 2.4 discussing an alternate mechanism for > connection binding merely serves to weaken the stand > in favor of the selected binding relationship. The following > text should be deleted: > > "An alternate approach that was extensively discussed involved > sending all commands on a single connection and the associated data > and status on a different connection (asymetric approach). In this > scheme, the transport ensures the commands arrive in order. The > protocol on the data and status connections is simpler, perhaps > lending itself to a simpler realization in hardware. One > disadvantage of this approach is that the recovery procedure is > different if a command connection fails vs. a data connection. Some > argued that this approach would require greater inter-processor > communication when connections are spread across processors. > The reader may reference the mail archives of the IPS mailing list > between June and September of 2000 for extensive discussions on > symmetric vs asymmetric connection models." regards, Mark. At 08:01 PM 11/17/2003, Nicholas A. Bellinger wrote: >Pat, > >http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf > >The following paper from Kalman Meth decribes them on page 12: > >Asymmetric: >Single Control Channel / iSCSI Connection. > >Multiple Data Channels / iSCSI Connection. > >Control Channel used to transfer commands, status, and task management. > >Symmetric: >All Channels / iSCSI Connections identical. > >Send Data and Status over same Channel / iSCSI Connection as >corresponding command. > > > >I am not exactly sure why the single control channel restriction was >imposed in the asymmetric case, but imagine its no longer an issue to >have multiple control channels. Perhaps this was before the advent of >session wide CmdSN ordering? > >Some of the more interesting questions: > >Connection recovery case, which connection an inflight command is >alligent to when the control and/or data connection fails. > >Requirements for falling back when an session runs out of control and/or >data channels. Or is it just easier to do session reinstatement into >an symmetric session. > >How strict are the requirements for data on the control channel and >control primatives in the data channel? Immediate DataOut comes to mind >in the former case, and Phase Collapse for DataIn in the latter. > >Thanks! > >On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote: > > I'm not clear on what you mean by "asymetric". > > > > -----Original Message----- > > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > > Sent: Monday, November 17, 2003 10:20 AM > > To: ips@ietf.org; Julian_Satran@il.ibm.com > > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > > Implementations Draft Interest? > > > > > > Greetings All, > > > > I am inquiring about interest in seeing a draft and possibly RFC > > regarding Considerations for Asymmetric iSCSI Implementations. I recall > > seeing some discussion on this topic back in 2000, and aside from a few > > other mentions of the model in various design documents I have not seen > > any followups. I am curious if the model had all but been abandoned for > > the symmetric model in traditional and iSER iSCSI, or if there is still > > room in the protocol for asymmetric operations? > > > > I have been thinking about this topic for a while and specifically its > > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some > > feedback from list members if it would be worthwhile for someone (mabye > > even me!) to put the thoughts down for other interested parties to > > consider. > > > > Aside from the expected responses of complexity issues for simple > > implementations, I do not see a terrible amount of extra functionality > > required for ErrorRecoveryLevel=1 and above implementations to operate > > in an Asymmetric model, and literally no changes to RFC 3347. As to the > > benefits of running in a Asymmetric model I can only speculate, > > although I suppose most are related performance in multiple connection > > ErrorRecoveryLevel=1 and above software implementations. > > > > Any feedback is welcome! > > > > -- > > Nicholas A. Bellinger > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips >-- >Nicholas A. Bellinger > > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 17:55:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11252 for ; Mon, 17 Nov 2003 17:55:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsGx-0005Bf-LS for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 17:55:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHMt7Nf019933 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 17:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsGx-0005BQ-Eh for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 17:55:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11217 for ; Mon, 17 Nov 2003 17:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsGu-0000j9-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 17:55:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALsGu-0000j6-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 17:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsGs-00059j-R8; Mon, 17 Nov 2003 17:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsGP-00056l-69 for ips@optimus.ietf.org; Mon, 17 Nov 2003 17:54:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11174; Mon, 17 Nov 2003 17:54:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsGM-0000ik-00; Mon, 17 Nov 2003 17:54:30 -0500 Received: from adsl-63-206-199-11.dsl.snfc21.pacbell.net ([63.206.199.11] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1ALsGL-0000hx-00; Mon, 17 Nov 2003 17:54:29 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1ALs57-0004XA-00; Mon, 17 Nov 2003 14:42:53 -0800 Subject: RE: [Ips] : Considerations for Asymmetric iSCSI Implementations Draft Interest? From: "Nicholas A. Bellinger" To: John Hufferd Cc: ips@ietf.org, ips-admin@ietf.org, Julian Satran , pat_thaler@agilent.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1069108965.16485.124.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 17 Nov 2003 14:42:46 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, I can think of a few reasons while trying not to go too deep into implementation specific details. These have to do with my idea of achieving maximum parallelism, which probably is not the same as other peoples. Again these are purely speculation. (speculation == more threads doing simpler operations will be faster as connection count increases) Non Immedate Unsolicited DataOUT Case, assume FirstBurstLength >= SCSI Request size. Asymmetric: 2 Control Channels and 2 Data Channels: CID 0 and 1: Control Channels 0 and 1 CID 2 and 3: Data Channels 0 and 1 Only operation is checking CmdSN window to send commands: 0) TX threads for CID 0 and 1 checking CmdSN window to send non immediate commands. 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID 0. 2) iSCSI Scsi Cmnd Opcode is built on CID 0 and unsolicited DataOUT request gets added to CID 2 from CID 0. 3) A and B can happen in any order: 3A) iSCSI Scsi Cmnd Opcode gets sent on CID 0. 3B) iSCSI Unsolicited DataOUT request gets queued and Unsolicited DataOUT is built on CID 2. 4) iSCSI Unsolicited DataOUT is sent on CID 2 after iSCSI Scsi Cmnd Opcode is sent on CID 0. 5) TX thread for CID 1 detects open CmdSN window and the process starts over again with CID 1 and CID 3. Problem: Latency issue of iSCSI Unsolicited DataOUT arriving before iSCSI Scsi Cmnd Opcode. Symmetric: 2 iSCSI Connections: CID 0 and 1 0) TX threads for CID 0 and 1 checking CmdSN window to send non immediate commands. 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID 0. 2) iSCSI Scsi Cmnd Opcode is built on CID 0. 3) iSCSI Scsi Cmnd Opcode is sent on CID 0, and adds Unsolicited DataOUT request to CID 0 queue. 4) Either A or B may happen next (matter of implementation) 4A) CID 0 builds Unsolicited DataOUT. 4B) CID 0 detects CmdSN window is open and sends more non-immediate commands, only until after CmdSN window closes does it send Unsolicited DataOUT. 5) TX thread for CID 1 detects CmdSN window and the process starts over again with CID 1. Problem: CID 0 having to build and send DataOUT while it could be sending another iSCSI Scsi Cmnd Opcode while the CmdSN window is open. This is just one scenario off the top of my head and could be written off as a matter of implementation, but the asymmetric goal is to achieve maximum parallelism by A) threads doing smaller specialized jobs, and B) Control threads queuing up more iSCSI Scsi Cmnds faster to Data Threads checking a single queue. As far as performance percentage improvement I cannot begin to dream up numbers until an asymmetric prototype is complete, and very well could only show improvements in specific configurations, but it is anyones guess. Thanks! -- Nicholas A. Bellinger On Mon, 2003-11-17 at 13:26, John Hufferd wrote: > I am not sure why we would ever want to do this. How does this > improve the performance over normal Multiple Connections per Session? > And what is the projected improvement (%)? > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/System Group, San Jose CA > Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Alt Office: (408) 997-6136, Cell: (408) 499-9702 > Internet Address: hufferd@us.ibm.com > > > > "Nicholas A. Bellinger" > > Sent by: > ips-admin@ietf.org > > 11/17/2003 12:01 PM > > To: > pat_thaler@agilent.com > cc: > ips@ietf.org, Julian > Satran > > Subject: > RE: [Ips] [IPS]: > Considerations for > Asymmetric iSCSI > Implementati ons > Draft Interest? > > > Pat, > > http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf > > The following paper from Kalman Meth decribes them on page 12: > > Asymmetric: > Single Control Channel / iSCSI Connection. > > Multiple Data Channels / iSCSI Connection. > > Control Channel used to transfer commands, status, and task > management. > > Symmetric: > All Channels / iSCSI Connections identical. > > Send Data and Status over same Channel / iSCSI Connection as > corresponding command. > > > > I am not exactly sure why the single control channel restriction was > imposed in the asymmetric case, but imagine its no longer an issue to > have multiple control channels. Perhaps this was before the advent of > session wide CmdSN ordering? > > Some of the more interesting questions: > > Connection recovery case, which connection an inflight command is > alligent to when the control and/or data connection fails. > > Requirements for falling back when an session runs out of control > and/or > data channels. Or is it just easier to do session reinstatement into > an symmetric session. > > How strict are the requirements for data on the control channel and > control primatives in the data channel? Immediate DataOut comes to > mind > in the former case, and Phase Collapse for DataIn in the latter. > > Thanks! > > On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote: > > I'm not clear on what you mean by "asymetric". > > > > -----Original Message----- > > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > > Sent: Monday, November 17, 2003 10:20 AM > > To: ips@ietf.org; Julian_Satran@il.ibm.com > > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > > Implementations Draft Interest? > > > > > > Greetings All, > > > > I am inquiring about interest in seeing a draft and > possibly RFC > > regarding Considerations for Asymmetric iSCSI Implementations. I > recall > > seeing some discussion on this topic back in 2000, and aside from a > few > > other mentions of the model in various design documents I have not > seen > > any followups. I am curious if the model had all but been abandoned > for > > the symmetric model in traditional and iSER iSCSI, or if there is > still > > room in the protocol for asymmetric operations? > > > > I have been thinking about this topic for a while and specifically > its > > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get > some > > feedback from list members if it would be worthwhile for someone > (mabye > > even me!) to put the thoughts down for other interested parties to > > consider. > > > > Aside from the expected responses of complexity issues for simple > > implementations, I do not see a terrible amount of extra > functionality > > required for ErrorRecoveryLevel=1 and above implementations to > operate > > in an Asymmetric model, and literally no changes to RFC 3347. As to > the > > benefits of running in a Asymmetric model I can only speculate, > > although I suppose most are related performance in multiple > connection > > ErrorRecoveryLevel=1 and above software implementations. > > > > Any feedback is welcome! > > > > -- > > Nicholas A. Bellinger > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > -- > Nicholas A. Bellinger > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 18:00:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11496 for ; Mon, 17 Nov 2003 18:00:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsLr-0005bR-Fx for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 18:00:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHN0AGQ021402 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 18:00:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsLo-0005WW-MN for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 18:00:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11452 for ; Mon, 17 Nov 2003 17:59:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsLl-0000pT-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 18:00:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALsLl-0000pQ-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 18:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsLk-0005VJ-4W; Mon, 17 Nov 2003 18:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsLJ-0005TH-Bo for ips@optimus.ietf.org; Mon, 17 Nov 2003 17:59:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11438 for ; Mon, 17 Nov 2003 17:59:23 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsLG-0000ol-00 for ips@ietf.org; Mon, 17 Nov 2003 17:59:34 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1ALsLG-0000oh-00 for ips@ietf.org; Mon, 17 Nov 2003 17:59:34 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 850C4626B; Mon, 17 Nov 2003 15:59:34 -0700 (MST) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by relcos1.cos.agilent.com (Postfix) with SMTP id 6442F57; Mon, 17 Nov 2003 15:59:34 -0700 (MST) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Nov 2003 15:59:31 -0700 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 15:59:30 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0132E05E5@axcs04.cos.agilent.com> To: marke@muttsnuts.com, ips@ietf.org Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementat i ons Draft Interest? Date: Mon, 17 Nov 2003 15:59:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , The asymmetric model looks simple at first glance, but when one probes, it appears to require significant extra complexity compared to the current model where command, data and status for a command are carried on a single connection. For example, when unsolicited data is sent on a data connection, it may arrive before the command so it may have to be held until the command arrives. More importantly, the SCSI protocol assumes an underlying ordered delivery to the SCSI layer between data and status. If data and status travel in different channels, then there would need to be some interlock between the cards to ensure that the status was not delivered to SCSI before the associated data. I expect the need for the interlock and the need to coordinate between the ends of the link which link the data was to be sent on would require changes to the iSCSI headers. The communication required between adapters (or adapter to driver to adapter) is also a disadvantage. Pat -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of Mark S. Edwards Sent: Monday, November 17, 2003 2:24 PM To: ips@ietf.org Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? I can't access the doc you reference, but I believe that it is very old and part of the idea bouncing during the early stages of iSCSI. I've been trying to remember the various discussions at the time as to the pro's and con's of the different models, but I do remember that I was quite opposed to this one largely due to the pain of what happens if one or other of the control or data plane fabrics breaks. Remember, any IETF based solution MUST be scalable to the Internet. Stuff that works when two hosts are side by side in a data centre has a habit of biting back when they are on opposite sides of the World. The earliest reference I have in my mail store goes back April 2001 and the Last Call discussions on the requirements document. There were a couple of emails asking Marjorie and team to remove the connection model discussions. This was particularly apt from Bob Snively and also tells you where to trawl for further enlightenment on the original discussions, presumably there may be some IPS meeting notes on this in there, too. >6) ALTERNATE CONNECTION BINDING > > The section in 2.4 discussing an alternate mechanism for > connection binding merely serves to weaken the stand > in favor of the selected binding relationship. The following > text should be deleted: > > "An alternate approach that was extensively discussed involved > sending all commands on a single connection and the associated data > and status on a different connection (asymetric approach). In this > scheme, the transport ensures the commands arrive in order. The > protocol on the data and status connections is simpler, perhaps > lending itself to a simpler realization in hardware. One > disadvantage of this approach is that the recovery procedure is > different if a command connection fails vs. a data connection. Some > argued that this approach would require greater inter-processor > communication when connections are spread across processors. > The reader may reference the mail archives of the IPS mailing list > between June and September of 2000 for extensive discussions on > symmetric vs asymmetric connection models." regards, Mark. At 08:01 PM 11/17/2003, Nicholas A. Bellinger wrote: >Pat, > >http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf > >The following paper from Kalman Meth decribes them on page 12: > >Asymmetric: >Single Control Channel / iSCSI Connection. > >Multiple Data Channels / iSCSI Connection. > >Control Channel used to transfer commands, status, and task management. > >Symmetric: >All Channels / iSCSI Connections identical. > >Send Data and Status over same Channel / iSCSI Connection as >corresponding command. > > > >I am not exactly sure why the single control channel restriction was >imposed in the asymmetric case, but imagine its no longer an issue to >have multiple control channels. Perhaps this was before the advent of >session wide CmdSN ordering? > >Some of the more interesting questions: > >Connection recovery case, which connection an inflight command is >alligent to when the control and/or data connection fails. > >Requirements for falling back when an session runs out of control and/or >data channels. Or is it just easier to do session reinstatement into >an symmetric session. > >How strict are the requirements for data on the control channel and >control primatives in the data channel? Immediate DataOut comes to mind >in the former case, and Phase Collapse for DataIn in the latter. > >Thanks! > >On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote: > > I'm not clear on what you mean by "asymetric". > > > > -----Original Message----- > > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > > Sent: Monday, November 17, 2003 10:20 AM > > To: ips@ietf.org; Julian_Satran@il.ibm.com > > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > > Implementations Draft Interest? > > > > > > Greetings All, > > > > I am inquiring about interest in seeing a draft and possibly RFC > > regarding Considerations for Asymmetric iSCSI Implementations. I recall > > seeing some discussion on this topic back in 2000, and aside from a few > > other mentions of the model in various design documents I have not seen > > any followups. I am curious if the model had all but been abandoned for > > the symmetric model in traditional and iSER iSCSI, or if there is still > > room in the protocol for asymmetric operations? > > > > I have been thinking about this topic for a while and specifically its > > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some > > feedback from list members if it would be worthwhile for someone (mabye > > even me!) to put the thoughts down for other interested parties to > > consider. > > > > Aside from the expected responses of complexity issues for simple > > implementations, I do not see a terrible amount of extra functionality > > required for ErrorRecoveryLevel=1 and above implementations to operate > > in an Asymmetric model, and literally no changes to RFC 3347. As to the > > benefits of running in a Asymmetric model I can only speculate, > > although I suppose most are related performance in multiple connection > > ErrorRecoveryLevel=1 and above software implementations. > > > > Any feedback is welcome! > > > > -- > > Nicholas A. Bellinger > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips >-- >Nicholas A. Bellinger > > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 18:17:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13207 for ; Mon, 17 Nov 2003 18:17:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALscA-0006R2-Vf for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 18:17:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHNH2mG024724 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 18:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALscA-0006Qf-Q2 for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 18:17:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13148 for ; Mon, 17 Nov 2003 18:16:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsc7-00018m-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 18:16:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALsc7-00018h-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 18:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsc9-0006Ng-5N; Mon, 17 Nov 2003 18:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsbJ-0006LK-GS for ips@optimus.ietf.org; Mon, 17 Nov 2003 18:16:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13053 for ; Mon, 17 Nov 2003 18:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsbG-00016D-00 for ips@ietf.org; Mon, 17 Nov 2003 18:16:06 -0500 Received: from adsl-63-206-199-11.dsl.snfc21.pacbell.net ([63.206.199.11] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1ALsbF-00014J-00 for ips@ietf.org; Mon, 17 Nov 2003 18:16:05 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1ALsRL-0004Y4-00; Mon, 17 Nov 2003 15:05:51 -0800 Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? From: "Nicholas A. Bellinger" To: "Mark S. Edwards" Cc: ips@ietf.org In-Reply-To: <6.0.0.22.2.20031117220640.040795e0@mail.muttsnuts.com> References: <1BEBA5E8600DD4119A50009027AF54A0132E05E4@axcs04.cos.agilent.com> <1069099316.16485.66.camel@subjekt.volcom.net> <6.0.0.22.2.20031117220640.040795e0@mail.muttsnuts.com> Content-Type: text/plain Message-Id: <1069110350.16486.145.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 17 Nov 2003 15:05:50 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark, On Mon, 2003-11-17 at 14:24, Mark S. Edwards wrote: > I can't access the doc you reference, but I believe that it is very old and > part of the idea bouncing during the early stages of iSCSI. > > I've been trying to remember the various discussions at the time as to the > pro's and con's of the different models, but I do remember that I was quite > opposed to this one largely due to the pain of what happens if one or other > of the control or data plane fabrics breaks. Remember, any IETF based > solution MUST be scalable to the Internet. Stuff that works when two hosts > are side by side in a data centre has a habit of biting back when they are > on opposite sides of the World. > What I am proposing is not a requirement for iSCSI, but an optional extension for the high speed ErrorRecoveryLevel=1 and above software implementations which would most likely be used in enviroment you mention above. > The earliest reference I have in my mail store goes back April 2001 and the > Last Call discussions on the requirements document. There were a couple of > emails asking Marjorie and team to remove the connection model discussions. > > This was particularly apt from Bob Snively and also tells you where to > trawl for further enlightenment on the original discussions, presumably > there may be some IPS meeting notes on this in there, too. > > >6) ALTERNATE CONNECTION BINDING > > > > The section in 2.4 discussing an alternate mechanism for > > connection binding merely serves to weaken the stand > > in favor of the selected binding relationship. The following > > text should be deleted: > > > > "An alternate approach that was extensively discussed involved > > sending all commands on a single connection and the associated data > > and status on a different connection (asymetric approach). In this > > scheme, the transport ensures the commands arrive in order. The > > protocol on the data and status connections is simpler, perhaps > > lending itself to a simpler realization in hardware. One > > disadvantage of this approach is that the recovery procedure is > > different if a command connection fails vs. a data connection. Some > > argued that this approach would require greater inter-processor > > communication when connections are spread across processors. > > The reader may reference the mail archives of the IPS mailing list > > between June and September of 2000 for extensive discussions on > > symmetric vs asymmetric connection models." > Also, the single control channel approach was to ensure SCSI transport ordering before the advent of session wide CmdSN ordering for non immediate commands. What I am proposing is multiple control channels following Session wide CmdSN ordering rules to stay in line with T10. In the connection recovery case it is almost certain that a command is alligent to a control channel and not data channel. Granted there are a few issues to consider when one or the other fails for a inflight command, but nothing above and beyond what a ErrorRecoveryLevel=2 implementation has already had to consider in normal symmetric operation. Thanks! -- Nicholas A. Bellinger _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 18:34:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13696 for ; Mon, 17 Nov 2003 18:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALssg-0007Z3-Mt for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 18:34:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHNY67U029073 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 18:34:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALssg-0007Yq-G6 for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 18:34:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13679 for ; Mon, 17 Nov 2003 18:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALssd-0001LY-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 18:34:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALssd-0001LV-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 18:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALssa-0007Xs-OX; Mon, 17 Nov 2003 18:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALss3-0007XJ-Fq for ips@optimus.ietf.org; Mon, 17 Nov 2003 18:33:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13668 for ; Mon, 17 Nov 2003 18:33:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALss0-0001LA-00 for ips@ietf.org; Mon, 17 Nov 2003 18:33:24 -0500 Received: from adsl-63-206-199-11.dsl.snfc21.pacbell.net ([63.206.199.11] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1ALsrz-0001Ki-00 for ips@ietf.org; Mon, 17 Nov 2003 18:33:23 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1ALshy-0004YO-00; Mon, 17 Nov 2003 15:23:02 -0800 Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementations Draft Interest? From: "Nicholas A. Bellinger" To: pat_thaler@agilent.com Cc: marke@muttsnuts.com, ips@ietf.org In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0132E05E5@axcs04.cos.agilent.com> References: <1BEBA5E8600DD4119A50009027AF54A0132E05E5@axcs04.cos.agilent.com> Content-Type: text/plain Message-Id: <1069111380.16485.155.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 17 Nov 2003 15:23:01 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat, On Mon, 2003-11-17 at 14:59, pat_thaler@agilent.com wrote: > The asymmetric model looks simple at first glance, but when one probes, it appears to require significant extra complexity compared to the current model where command, data and status for a command are carried on a single connection. > > For example, when unsolicited data is sent on a data connection, it may arrive before the command so it may have to be held until the command arrives. More importantly, the SCSI protocol assumes an underlying ordered delivery to the SCSI layer between data and status. If data and status travel in different channels, then there would need to be some interlock between the cards to ensure that the status was not delivered to SCSI before the associated data. > > I expect the need for the interlock and the need to coordinate between the ends of the link which link the data was to be sent on would require changes to the iSCSI headers. > > The communication required between adapters (or adapter to driver to adapter) is also a disadvantage. > > Pat > I take the stance that handling and not discarding any Unsolicited DataOUT for an unknown Initiator Task Tag is a bad idea. In the Unsolicited DataOut case, when the DataOUT request is only sent (but can be built) on the data channel only after the control channel has successfuly sent the iSCSI Scsi Cmnd. Of course then the problem arises of handling out of order CmdSNs for multiple control channels, and Unsolicited DataOut still arriving before (although this time a Initiator Task Tag would be present) the CmdSN of the iSCSI SCSI Cmnd is executed by the Storage Transport Layer. Thanks for the observations! -- Nicholas A. Bellinger > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of Mark S. > Edwards > Sent: Monday, November 17, 2003 2:24 PM > To: ips@ietf.org > Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI > Implementati ons Draft Interest? > > > I can't access the doc you reference, but I believe that it is very old and > part of the idea bouncing during the early stages of iSCSI. > > I've been trying to remember the various discussions at the time as to the > pro's and con's of the different models, but I do remember that I was quite > opposed to this one largely due to the pain of what happens if one or other > of the control or data plane fabrics breaks. Remember, any IETF based > solution MUST be scalable to the Internet. Stuff that works when two hosts > are side by side in a data centre has a habit of biting back when they are > on opposite sides of the World. > > The earliest reference I have in my mail store goes back April 2001 and the > Last Call discussions on the requirements document. There were a couple of > emails asking Marjorie and team to remove the connection model discussions. > > This was particularly apt from Bob Snively and also tells you where to > trawl for further enlightenment on the original discussions, presumably > there may be some IPS meeting notes on this in there, too. > > >6) ALTERNATE CONNECTION BINDING > > > > The section in 2.4 discussing an alternate mechanism for > > connection binding merely serves to weaken the stand > > in favor of the selected binding relationship. The following > > text should be deleted: > > > > "An alternate approach that was extensively discussed involved > > sending all commands on a single connection and the associated data > > and status on a different connection (asymetric approach). In this > > scheme, the transport ensures the commands arrive in order. The > > protocol on the data and status connections is simpler, perhaps > > lending itself to a simpler realization in hardware. One > > disadvantage of this approach is that the recovery procedure is > > different if a command connection fails vs. a data connection. Some > > argued that this approach would require greater inter-processor > > communication when connections are spread across processors. > > The reader may reference the mail archives of the IPS mailing list > > between June and September of 2000 for extensive discussions on > > symmetric vs asymmetric connection models." > > regards, > > Mark. > > > > > > At 08:01 PM 11/17/2003, Nicholas A. Bellinger wrote: > >Pat, > > > >http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf > > > >The following paper from Kalman Meth decribes them on page 12: > > > >Asymmetric: > >Single Control Channel / iSCSI Connection. > > > >Multiple Data Channels / iSCSI Connection. > > > >Control Channel used to transfer commands, status, and task management. > > > >Symmetric: > >All Channels / iSCSI Connections identical. > > > >Send Data and Status over same Channel / iSCSI Connection as > >corresponding command. > > > > > > > >I am not exactly sure why the single control channel restriction was > >imposed in the asymmetric case, but imagine its no longer an issue to > >have multiple control channels. Perhaps this was before the advent of > >session wide CmdSN ordering? > > > >Some of the more interesting questions: > > > >Connection recovery case, which connection an inflight command is > >alligent to when the control and/or data connection fails. > > > >Requirements for falling back when an session runs out of control and/or > >data channels. Or is it just easier to do session reinstatement into > >an symmetric session. > > > >How strict are the requirements for data on the control channel and > >control primatives in the data channel? Immediate DataOut comes to mind > >in the former case, and Phase Collapse for DataIn in the latter. > > > >Thanks! > > > >On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote: > > > I'm not clear on what you mean by "asymetric". > > > > > > -----Original Message----- > > > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > > > Sent: Monday, November 17, 2003 10:20 AM > > > To: ips@ietf.org; Julian_Satran@il.ibm.com > > > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > > > Implementations Draft Interest? > > > > > > > > > Greetings All, > > > > > > I am inquiring about interest in seeing a draft and possibly RFC > > > regarding Considerations for Asymmetric iSCSI Implementations. I recall > > > seeing some discussion on this topic back in 2000, and aside from a few > > > other mentions of the model in various design documents I have not seen > > > any followups. I am curious if the model had all but been abandoned for > > > the symmetric model in traditional and iSER iSCSI, or if there is still > > > room in the protocol for asymmetric operations? > > > > > > I have been thinking about this topic for a while and specifically its > > > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some > > > feedback from list members if it would be worthwhile for someone (mabye > > > even me!) to put the thoughts down for other interested parties to > > > consider. > > > > > > Aside from the expected responses of complexity issues for simple > > > implementations, I do not see a terrible amount of extra functionality > > > required for ErrorRecoveryLevel=1 and above implementations to operate > > > in an Asymmetric model, and literally no changes to RFC 3347. As to the > > > benefits of running in a Asymmetric model I can only speculate, > > > although I suppose most are related performance in multiple connection > > > ErrorRecoveryLevel=1 and above software implementations. > > > > > > Any feedback is welcome! > > > > > > -- > > > Nicholas A. Bellinger > > > > > > > > > _______________________________________________ > > > Ips mailing list > > > Ips@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ips > >-- > >Nicholas A. Bellinger > > > > > >_______________________________________________ > >Ips mailing list > >Ips@ietf.org > >https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 17 20:08:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16680 for ; Mon, 17 Nov 2003 20:08:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuLi-0004OQ-UT for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 20:08:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI18AZd016880 for ips-archive@odin.ietf.org; Mon, 17 Nov 2003 20:08:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuLi-0004OB-Ow for ips-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 20:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16630 for ; Mon, 17 Nov 2003 20:07:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALuLg-0002ll-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 20:08:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALuLg-0002lh-00 for ips-web-archive@ietf.org; Mon, 17 Nov 2003 20:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuLZ-0004Le-Aw; Mon, 17 Nov 2003 20:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuKl-00047w-NK for ips@optimus.ietf.org; Mon, 17 Nov 2003 20:07:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16598 for ; Mon, 17 Nov 2003 20:06:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALuKj-0002kJ-00 for ips@ietf.org; Mon, 17 Nov 2003 20:07:09 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1ALuKi-0002jF-00 for ips@ietf.org; Mon, 17 Nov 2003 20:07:08 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAI16UIw361694; Mon, 17 Nov 2003 20:06:30 -0500 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAI16SiB138004; Mon, 17 Nov 2003 18:06:29 -0700 To: "Nicholas A. Bellinger" Cc: ips@ietf.org, ips-admin@ietf.org, Julian Satran , pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: [Ips] : Considerations for Asymmetric iSCSI Implementations Draft Interest? X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: John Hufferd Message-ID: Date: Mon, 17 Nov 2003 17:06:24 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.2CF2HF92 | October 15, 2003) at 11/17/2003 18:06:29, Serialize complete at 11/17/2003 18:06:29 Content-Type: multipart/alternative; boundary="=_alternative 0006008688256DE2_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0006008688256DE2_= Content-Type: text/plain; charset="us-ascii" Yes, it is anyone's guess what the performance improvement (if any) there would be. But you are saying that with specialty engines, you could go faster. On the other hand many of the implementations I have seen have speciality engines and speciality paths. In your example, if I understood it correctly, you have 4 connections for the Asymmetric case. But you don't seem to talk about that with your Symmetric case. Also, you talk about the CmdSN window, but it seemed that you specified it as a connection based item. However, since it is a Session Wide value, any of the example's four connections would be able to start transferring the very next command. So there would be NO hold up waiting to send the command on another connection, as long as a connection was freed. And since that is basically the same limitation for the Asymmetric case (a connection must be free to send data, or anything), I do not see the problem, let alone the fix. Remember you can have Multiple Connections per Session (MC/S), between physically different Portals, or you can have MC/S within a single Physical Portal via multiple logical connections. So everything you want to do is doable, and without a clear reason why an Asymmetric case is better, I can not see us dealing with it. (Some deep math is probably needed here.) . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Nicholas A. Bellinger" 11/17/2003 02:42 PM To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ietf.org, ips-admin@ietf.org, Julian Satran , pat_thaler@agilent.com Subject: RE: [Ips] : Considerations for Asymmetric iSCSI Implementations Draft Interest? John, I can think of a few reasons while trying not to go too deep into implementation specific details. These have to do with my idea of achieving maximum parallelism, which probably is not the same as other peoples. Again these are purely speculation. (speculation == more threads doing simpler operations will be faster as connection count increases) Non Immedate Unsolicited DataOUT Case, assume FirstBurstLength >= SCSI Request size. Asymmetric: 2 Control Channels and 2 Data Channels: CID 0 and 1: Control Channels 0 and 1 CID 2 and 3: Data Channels 0 and 1 Only operation is checking CmdSN window to send commands: 0) TX threads for CID 0 and 1 checking CmdSN window to send non immediate commands. 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID 0. 2) iSCSI Scsi Cmnd Opcode is built on CID 0 and unsolicited DataOUT request gets added to CID 2 from CID 0. 3) A and B can happen in any order: 3A) iSCSI Scsi Cmnd Opcode gets sent on CID 0. 3B) iSCSI Unsolicited DataOUT request gets queued and Unsolicited DataOUT is built on CID 2. 4) iSCSI Unsolicited DataOUT is sent on CID 2 after iSCSI Scsi Cmnd Opcode is sent on CID 0. 5) TX thread for CID 1 detects open CmdSN window and the process starts over again with CID 1 and CID 3. Problem: Latency issue of iSCSI Unsolicited DataOUT arriving before iSCSI Scsi Cmnd Opcode. Symmetric: 2 iSCSI Connections: CID 0 and 1 0) TX threads for CID 0 and 1 checking CmdSN window to send non immediate commands. 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID 0. 2) iSCSI Scsi Cmnd Opcode is built on CID 0. 3) iSCSI Scsi Cmnd Opcode is sent on CID 0, and adds Unsolicited DataOUT request to CID 0 queue. 4) Either A or B may happen next (matter of implementation) 4A) CID 0 builds Unsolicited DataOUT. 4B) CID 0 detects CmdSN window is open and sends more non-immediate commands, only until after CmdSN window closes does it send Unsolicited DataOUT. 5) TX thread for CID 1 detects CmdSN window and the process starts over again with CID 1. Problem: CID 0 having to build and send DataOUT while it could be sending another iSCSI Scsi Cmnd Opcode while the CmdSN window is open. This is just one scenario off the top of my head and could be written off as a matter of implementation, but the asymmetric goal is to achieve maximum parallelism by A) threads doing smaller specialized jobs, and B) Control threads queuing up more iSCSI Scsi Cmnds faster to Data Threads checking a single queue. As far as performance percentage improvement I cannot begin to dream up numbers until an asymmetric prototype is complete, and very well could only show improvements in specific configurations, but it is anyones guess. Thanks! -- Nicholas A. Bellinger On Mon, 2003-11-17 at 13:26, John Hufferd wrote: > I am not sure why we would ever want to do this. How does this > improve the performance over normal Multiple Connections per Session? > And what is the projected improvement (%)? > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/System Group, San Jose CA > Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Alt Office: (408) 997-6136, Cell: (408) 499-9702 > Internet Address: hufferd@us.ibm.com > > > > "Nicholas A. Bellinger" > > Sent by: > ips-admin@ietf.org > > 11/17/2003 12:01 PM > > To: > pat_thaler@agilent.com > cc: > ips@ietf.org, Julian > Satran > > Subject: > RE: [Ips] [IPS]: > Considerations for > Asymmetric iSCSI > Implementati ons > Draft Interest? > > > Pat, > > http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf > > The following paper from Kalman Meth decribes them on page 12: > > Asymmetric: > Single Control Channel / iSCSI Connection. > > Multiple Data Channels / iSCSI Connection. > > Control Channel used to transfer commands, status, and task > management. > > Symmetric: > All Channels / iSCSI Connections identical. > > Send Data and Status over same Channel / iSCSI Connection as > corresponding command. > > > > I am not exactly sure why the single control channel restriction was > imposed in the asymmetric case, but imagine its no longer an issue to > have multiple control channels. Perhaps this was before the advent of > session wide CmdSN ordering? > > Some of the more interesting questions: > > Connection recovery case, which connection an inflight command is > alligent to when the control and/or data connection fails. > > Requirements for falling back when an session runs out of control > and/or > data channels. Or is it just easier to do session reinstatement into > an symmetric session. > > How strict are the requirements for data on the control channel and > control primatives in the data channel? Immediate DataOut comes to > mind > in the former case, and Phase Collapse for DataIn in the latter. > > Thanks! > > On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote: > > I'm not clear on what you mean by "asymetric". > > > > -----Original Message----- > > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > > Sent: Monday, November 17, 2003 10:20 AM > > To: ips@ietf.org; Julian_Satran@il.ibm.com > > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > > Implementations Draft Interest? > > > > > > Greetings All, > > > > I am inquiring about interest in seeing a draft and > possibly RFC > > regarding Considerations for Asymmetric iSCSI Implementations. I > recall > > seeing some discussion on this topic back in 2000, and aside from a > few > > other mentions of the model in various design documents I have not > seen > > any followups. I am curious if the model had all but been abandoned > for > > the symmetric model in traditional and iSER iSCSI, or if there is > still > > room in the protocol for asymmetric operations? > > > > I have been thinking about this topic for a while and specifically > its > > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get > some > > feedback from list members if it would be worthwhile for someone > (mabye > > even me!) to put the thoughts down for other interested parties to > > consider. > > > > Aside from the expected responses of complexity issues for simple > > implementations, I do not see a terrible amount of extra > functionality > > required for ErrorRecoveryLevel=1 and above implementations to > operate > > in an Asymmetric model, and literally no changes to RFC 3347. As to > the > > benefits of running in a Asymmetric model I can only speculate, > > although I suppose most are related performance in multiple > connection > > ErrorRecoveryLevel=1 and above software implementations. > > > > Any feedback is welcome! > > > > -- > > Nicholas A. Bellinger > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > -- > Nicholas A. Bellinger > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0006008688256DE2_= Content-Type: text/html; charset="us-ascii"
Yes, it is anyone's guess what the performance improvement (if any) there would be. But you are saying that with specialty engines, you could go faster.  On the other hand many of the implementations I have seen have speciality engines and speciality paths.  In your example, if I understood it correctly, you have 4 connections for the Asymmetric case.  But you don't seem to talk about that with your Symmetric case.

Also, you talk about the CmdSN window, but it seemed that you specified it as a connection based item.  However, since it is a Session Wide value, any of the example's four connections would be able to start transferring the very next command.  So there would be NO hold up waiting to send the command on another connection, as long as a connection was freed.  And since that is basically the same limitation for the Asymmetric case (a connection must be free to send data, or anything), I do not see the problem, let alone the fix.

Remember you can have Multiple Connections per Session (MC/S), between physically different Portals, or you can have MC/S within a single Physical Portal via multiple logical connections.  So everything you want to do is doable, and without a clear reason why an Asymmetric case is better, I can not see us dealing with it.  (Some deep math is probably needed here.)
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


"Nicholas A. Bellinger" <nick@pyxtechnologies.com>

11/17/2003 02:42 PM

       
        To:        John Hufferd/San Jose/IBM@IBMUS
        cc:        ips@ietf.org, ips-admin@ietf.org, Julian Satran <Julian_Satran@il.ibm.com>, pat_thaler@agilent.com
        Subject:        RE: [Ips] : Considerations for Asymmetric iSCSI Implementations        Draft Interest?



John,

I can think of a few reasons while trying not to go too deep into
implementation specific details.  These have to do with my idea of
achieving maximum parallelism,  which probably is not the same as other
peoples. Again these are purely speculation. (speculation == more
threads doing simpler operations will be faster as connection count
increases)

Non Immedate Unsolicited DataOUT Case, assume FirstBurstLength >= SCSI
Request size.


Asymmetric:

2 Control Channels and 2 Data Channels:
CID 0 and 1: Control Channels 0 and 1
CID 2 and 3: Data Channels 0 and 1

Only operation is checking CmdSN window to send commands:

0) TX threads for CID 0 and 1 checking CmdSN window to send non
immediate commands.
1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID
0.
2) iSCSI Scsi Cmnd Opcode is built on CID 0 and unsolicited DataOUT
request gets added to CID 2 from CID 0.
3) A and B can happen in any order:
3A) iSCSI Scsi Cmnd Opcode gets sent on CID 0.
3B) iSCSI Unsolicited DataOUT request gets queued and Unsolicited
DataOUT is built on CID 2.
4) iSCSI Unsolicited DataOUT is sent on CID 2 after iSCSI Scsi Cmnd
Opcode is sent on CID 0.
5) TX thread for CID 1 detects open CmdSN window and the process starts
  over again with CID 1 and CID 3.

Problem:
Latency issue of iSCSI Unsolicited DataOUT arriving before iSCSI Scsi
Cmnd Opcode.


Symmetric:  

2 iSCSI Connections:
CID 0 and 1

0) TX threads for CID 0 and 1 checking CmdSN window to send non
immediate commands.
1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID
0.
2) iSCSI Scsi Cmnd Opcode is built on CID 0.
3) iSCSI Scsi Cmnd Opcode is sent on CID 0, and adds Unsolicited DataOUT
request to CID 0 queue.
4) Either A or B may happen next (matter of implementation)
4A) CID 0 builds Unsolicited DataOUT.
4B) CID 0 detects CmdSN window is open and sends more non-immediate
commands, only until after CmdSN window closes does it send Unsolicited
DataOUT.
5) TX thread for CID 1 detects CmdSN window and the process starts over
again with CID 1.

Problem:
CID 0 having to build and send DataOUT while it could be sending another
iSCSI Scsi Cmnd Opcode while the CmdSN window is open.


This is just one scenario off the top of my head and could be written
off as a matter of implementation,  but the asymmetric goal is to
achieve maximum parallelism by A) threads doing smaller specialized
jobs, and B) Control threads queuing up more iSCSI Scsi Cmnds faster to
Data Threads checking a single queue.  As far as performance percentage
improvement I cannot begin to dream up numbers until an asymmetric
prototype is complete, and very well could only show improvements in
specific configurations,  but it is anyones guess.

Thanks!

--
Nicholas A. Bellinger <nick@pyxtechnologies.com>


On Mon, 2003-11-17 at 13:26, John Hufferd wrote:
> I am not sure why we would ever want to do this.  How does this
> improve the performance over normal Multiple Connections per Session?
> And what is the projected improvement (%)?
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/System Group, San Jose CA
> Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
> Alt Office: (408) 997-6136, Cell: (408) 499-9702
> Internet Address: hufferd@us.ibm.com
>
>
>
> "Nicholas A. Bellinger"
> <nick@pyxtechnologies.com>
> Sent by:
> ips-admin@ietf.org
>
> 11/17/2003 12:01 PM
>        
>         To:      
> pat_thaler@agilent.com
>         cc:      
> ips@ietf.org, Julian
> Satran
> <Julian_Satran@il.ibm.com>
>         Subject:      
> RE: [Ips] [IPS]:
> Considerations for
> Asymmetric iSCSI
> Implementati        ons
> Draft Interest?
>
>
> Pat,
>
> http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf
>
> The following paper from Kalman Meth decribes them on page 12:
>
> Asymmetric:
> Single Control Channel / iSCSI Connection.
>
> Multiple Data Channels / iSCSI Connection.
>
> Control Channel used to transfer commands, status, and task
> management.
>
> Symmetric:
> All Channels / iSCSI Connections identical.
>
> Send Data and Status over same Channel / iSCSI Connection as  
> corresponding command.
>
>
>
> I am not exactly sure why the single control channel restriction was
> imposed in the asymmetric case, but imagine its no longer an issue to
> have multiple control channels.  Perhaps this was before the advent of
> session wide CmdSN ordering?
>
> Some of the more interesting questions:
>
> Connection recovery case, which connection an inflight command is
> alligent to when the control and/or data connection fails.
>
> Requirements for falling back when an session runs out of control
> and/or
> data channels.  Or is it just easier to do session reinstatement into
> an symmetric session.
>
> How strict are the requirements for data on the control channel and
> control primatives in the data channel?  Immediate DataOut comes to
> mind
> in the former case, and Phase Collapse for DataIn in the latter.
>
> Thanks!
>
> On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote:
> > I'm not clear on what you mean by "asymetric".
> >
> > -----Original Message-----
> > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com]
> > Sent: Monday, November 17, 2003 10:20 AM
> > To: ips@ietf.org; Julian_Satran@il.ibm.com
> > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI
> > Implementations Draft Interest?
> >
> >
> > Greetings All,
> >                  
> >                  I am inquiring about interest in seeing a draft and
> possibly RFC
> > regarding Considerations for Asymmetric iSCSI Implementations.  I
> recall
> > seeing some discussion on this topic back in 2000, and aside from a
> few
> > other mentions of the model in various design documents I have not
> seen
> > any followups.  I am curious if the model had all but been abandoned
> for
> > the symmetric model in traditional and iSER iSCSI, or if there is
> still
> > room in the protocol for asymmetric operations?
> >
> > I have been thinking about this topic for a while and specifically
> its
> > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get
> some
> > feedback from list members if it would be worthwhile for someone
> (mabye
> > even me!) to put the thoughts down for other interested parties to
> > consider.
> >
> > Aside from the expected responses of complexity issues for simple
> > implementations,  I do not see a terrible amount of extra
> functionality
> > required for ErrorRecoveryLevel=1 and above implementations to
> operate
> > in an Asymmetric model, and literally no changes to RFC 3347.  As to
> the
> > benefits of running in a Asymmetric model I can only speculate,
> > although I suppose most are related performance in multiple
> connection
> > ErrorRecoveryLevel=1 and above software implementations.
> >
> > Any feedback is welcome!                
> >
> > --
> > Nicholas A. Bellinger <nick@pyxtechnologies.com>
> >
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> --
> Nicholas A. Bellinger <nick@pyxtechnologies.com>
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 0006008688256DE2_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Nov 18 01:28:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24573 for ; Tue, 18 Nov 2003 01:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALzLO-0001cH-G4 for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 01:28:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI6SAZM006212 for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 01:28:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALzLO-0001c7-8Q for ips-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 01:28:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24559 for ; Tue, 18 Nov 2003 01:27:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALzLL-0006e0-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 01:28:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALzLK-0006dx-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 01:28:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALzLF-0001aB-AN; Tue, 18 Nov 2003 01:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALzKn-0001YQ-6r for ips@optimus.ietf.org; Tue, 18 Nov 2003 01:27:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24550; Tue, 18 Nov 2003 01:27:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALzKh-0006dl-00; Tue, 18 Nov 2003 01:27:27 -0500 Received: from adsl-63-206-199-11.dsl.snfc21.pacbell.net ([63.206.199.11] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1ALzKg-0006d3-00; Tue, 18 Nov 2003 01:27:26 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1ALzAe-0004bP-00; Mon, 17 Nov 2003 22:17:04 -0800 Subject: RE: [Ips] : Considerations for Asymmetric iSCSI Implementations Draft Interest? From: "Nicholas A. Bellinger" To: John Hufferd Cc: ips@ietf.org, ips-admin@ietf.org, Julian Satran , pat_thaler@agilent.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1069136221.16485.196.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 17 Nov 2003 22:17:01 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, On Mon, 2003-11-17 at 17:06, John Hufferd wrote: > Yes, it is anyone's guess what the performance improvement (if any) > there would be. But you are saying that with specialty engines, you > could go faster. On the other hand many of the implementations I have > seen have speciality engines and speciality paths. In your example, > if I understood it correctly, you have 4 connections for the > Asymmetric case. But you don't seem to talk about that with your > Symmetric case. > Point taken in the symmetric case. The goal was to show operations based with multiple connections. The same basic operation would occur in the symmetric example with four connections. > Also, you talk about the CmdSN window, but it seemed that you > specified it as a connection based item. However, since it is a > Session Wide value, any of the example's four connections would be > able to start transferring the very next command. So there would be > NO hold up waiting to send the command on another connection, as long > as a connection was freed. And since that is basically the same > limitation for the Asymmetric case (a connection must be free to send > data, or anything), I do not see the problem, let alone the fix. > The CmdSN was used in context of each control connection or normal connection TX thread checking the session wide CmdSN window for an opening to send non immediate commands, sorry for the confusion. The delay I was trying to convey in the symmetric example is not a session wide delay of other connections unable to send non immediate commands when the CmdSN window opens, but other connections being busy fullfilling interconnection requests such as Unsolicited DataOut. > Remember you can have Multiple Connections per Session (MC/S), between > physically different Portals, or you can have MC/S within a single > Physical Portal via multiple logical connections. So everything you > want to do is doable, and without a clear reason why an Asymmetric > case is better, I can not see us dealing with it. (Some deep math is > probably needed here.) > . > . I am not questioning any of these points, the main concept being addressed here with control and data connections is keeping each of them as busy as possible doing their specifics jobs: Control Connection: Checking CmdSN window openings for sending non immediate commands. ie: a single session wide request queue. Data Connection: Checking for pending Unsolicited or Solicited DataOUT. ie: a single connection wide request queue. Compared to: Normal Connection: At absolute least two queues. One checking for pending Unsolicited or Solicited DataOUT requests (connection wide), and one for checking openings in the CmdSN window for sending non immediate commands (session wide). (I believe the IBM iSCSI Initiator for Linux based on draft v8 had three queues. Immediate (connection wide), R2T (connection wide), and session wide queue checked when the CmdSN window opened). Back to the performance question, I completely agree. It is anyones guess and will remain that until someone comes up with numbers for various cases. (It could very well be difficult to beat symmetric ImmediateData performance when the entire request size fits in FirstBurstLength, as good implementations do today). In any event I still firmly believe that an asymmetric model will scale futher and have a better cache hit ratio than its symmetric couterpart in the pure software case. Thanks! -- Nicholas A. Bellinger > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/System Group, San Jose CA > Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Alt Office: (408) 997-6136, Cell: (408) 499-9702 > Internet Address: hufferd@us.ibm.com > > > > "Nicholas A. Bellinger" > > > 11/17/2003 02:42 PM > > To: John > Hufferd/San > Jose/IBM@IBMUS > cc: > ips@ietf.org, > ips-admin@ietf.org, > Julian Satran > , pat_thaler@agilent.com > Subject: > RE: [Ips] : > Considerations for > Asymmetric iSCSI > Implementations > Draft Interest? > > > John, > > I can think of a few reasons while trying not to go too deep into > implementation specific details. These have to do with my idea of > achieving maximum parallelism, which probably is not the same as > other > peoples. Again these are purely speculation. (speculation == more > threads doing simpler operations will be faster as connection count > increases) > > Non Immedate Unsolicited DataOUT Case, assume FirstBurstLength >= SCSI > Request size. > > > Asymmetric: > > 2 Control Channels and 2 Data Channels: > CID 0 and 1: Control Channels 0 and 1 > CID 2 and 3: Data Channels 0 and 1 > > Only operation is checking CmdSN window to send commands: > > 0) TX threads for CID 0 and 1 checking CmdSN window to send non > immediate commands. > 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID > 0. > 2) iSCSI Scsi Cmnd Opcode is built on CID 0 and unsolicited DataOUT > request gets added to CID 2 from CID 0. > 3) A and B can happen in any order: > 3A) iSCSI Scsi Cmnd Opcode gets sent on CID 0. > 3B) iSCSI Unsolicited DataOUT request gets queued and Unsolicited > DataOUT is built on CID 2. > 4) iSCSI Unsolicited DataOUT is sent on CID 2 after iSCSI Scsi Cmnd > Opcode is sent on CID 0. > 5) TX thread for CID 1 detects open CmdSN window and the process > starts > over again with CID 1 and CID 3. > > Problem: > Latency issue of iSCSI Unsolicited DataOUT arriving before iSCSI Scsi > Cmnd Opcode. > > > Symmetric: > > 2 iSCSI Connections: > CID 0 and 1 > > 0) TX threads for CID 0 and 1 checking CmdSN window to send non > immediate commands. > 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID > 0. > 2) iSCSI Scsi Cmnd Opcode is built on CID 0. > 3) iSCSI Scsi Cmnd Opcode is sent on CID 0, and adds Unsolicited > DataOUT > request to CID 0 queue. > 4) Either A or B may happen next (matter of implementation) > 4A) CID 0 builds Unsolicited DataOUT. > 4B) CID 0 detects CmdSN window is open and sends more non-immediate > commands, only until after CmdSN window closes does it send > Unsolicited > DataOUT. > 5) TX thread for CID 1 detects CmdSN window and the process starts > over > again with CID 1. > > Problem: > CID 0 having to build and send DataOUT while it could be sending > another > iSCSI Scsi Cmnd Opcode while the CmdSN window is open. > > > This is just one scenario off the top of my head and could be written > off as a matter of implementation, but the asymmetric goal is to > achieve maximum parallelism by A) threads doing smaller specialized > jobs, and B) Control threads queuing up more iSCSI Scsi Cmnds faster > to > Data Threads checking a single queue. As far as performance > percentage > improvement I cannot begin to dream up numbers until an asymmetric > prototype is complete, and very well could only show improvements in > specific configurations, but it is anyones guess. > > Thanks! > > -- > Nicholas A. Bellinger > > > On Mon, 2003-11-17 at 13:26, John Hufferd wrote: > > I am not sure why we would ever want to do this. How does this > > improve the performance over normal Multiple Connections per > Session? > > And what is the projected improvement (%)? > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/System Group, San Jose CA > > Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Alt Office: (408) 997-6136, Cell: (408) 499-9702 > > Internet Address: hufferd@us.ibm.com > > > > > > > > "Nicholas A. Bellinger" > > > > Sent by: > > ips-admin@ietf.org > > > > 11/17/2003 12:01 PM > > > > To: > > pat_thaler@agilent.com > > cc: > > ips@ietf.org, Julian > > Satran > > > > Subject: > > RE: [Ips] [IPS]: > > Considerations for > > Asymmetric iSCSI > > Implementati ons > > Draft Interest? > > > > > > Pat, > > > > > http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf > > > > The following paper from Kalman Meth decribes them on page 12: > > > > Asymmetric: > > Single Control Channel / iSCSI Connection. > > > > Multiple Data Channels / iSCSI Connection. > > > > Control Channel used to transfer commands, status, and task > > management. > > > > Symmetric: > > All Channels / iSCSI Connections identical. > > > > Send Data and Status over same Channel / iSCSI Connection as > > corresponding command. > > > > > > > > I am not exactly sure why the single control channel restriction was > > imposed in the asymmetric case, but imagine its no longer an issue > to > > have multiple control channels. Perhaps this was before the advent > of > > session wide CmdSN ordering? > > > > Some of the more interesting questions: > > > > Connection recovery case, which connection an inflight command is > > alligent to when the control and/or data connection fails. > > > > Requirements for falling back when an session runs out of control > > and/or > > data channels. Or is it just easier to do session reinstatement > into > > an symmetric session. > > > > How strict are the requirements for data on the control channel and > > control primatives in the data channel? Immediate DataOut comes to > > mind > > in the former case, and Phase Collapse for DataIn in the latter. > > > > Thanks! > > > > On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote: > > > I'm not clear on what you mean by "asymetric". > > > > > > -----Original Message----- > > > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > > > Sent: Monday, November 17, 2003 10:20 AM > > > To: ips@ietf.org; Julian_Satran@il.ibm.com > > > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > > > Implementations Draft Interest? > > > > > > > > > Greetings All, > > > > > > I am inquiring about interest in seeing a draft > and > > possibly RFC > > > regarding Considerations for Asymmetric iSCSI Implementations. I > > recall > > > seeing some discussion on this topic back in 2000, and aside from > a > > few > > > other mentions of the model in various design documents I have not > > seen > > > any followups. I am curious if the model had all but been > abandoned > > for > > > the symmetric model in traditional and iSER iSCSI, or if there is > > still > > > room in the protocol for asymmetric operations? > > > > > > I have been thinking about this topic for a while and specifically > > its > > > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get > > some > > > feedback from list members if it would be worthwhile for someone > > (mabye > > > even me!) to put the thoughts down for other interested parties to > > > consider. > > > > > > Aside from the expected responses of complexity issues for simple > > > implementations, I do not see a terrible amount of extra > > functionality > > > required for ErrorRecoveryLevel=1 and above implementations to > > operate > > > in an Asymmetric model, and literally no changes to RFC 3347. As > to > > the > > > benefits of running in a Asymmetric model I can only speculate, > > > although I suppose most are related performance in multiple > > connection > > > ErrorRecoveryLevel=1 and above software implementations. > > > > > > Any feedback is welcome! > > > > > > -- > > > Nicholas A. Bellinger > > > > > > > > > _______________________________________________ > > > Ips mailing list > > > Ips@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ips > > -- > > Nicholas A. Bellinger > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Nov 18 03:31:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10111 for ; Tue, 18 Nov 2003 03:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1GU-00011F-9H for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 03:31:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI8VElm003917 for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 03:31:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1GR-000115-9s for ips-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 03:31:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10099 for ; Tue, 18 Nov 2003 03:31:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM1GO-0000TF-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 03:31:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM1GO-0000TC-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 03:31:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1GH-000104-Jt; Tue, 18 Nov 2003 03:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1GD-0000zT-LD for ips@optimus.ietf.org; Tue, 18 Nov 2003 03:30:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10087 for ; Tue, 18 Nov 2003 03:30:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM1GB-0000QQ-00 for ips@ietf.org; Tue, 18 Nov 2003 03:30:55 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AM1G9-0000Q3-00 for ips@ietf.org; Tue, 18 Nov 2003 03:30:53 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAI8U7cF416148; Tue, 18 Nov 2003 03:30:07 -0500 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAI8U6mA273224; Tue, 18 Nov 2003 01:30:07 -0700 To: "Nicholas A. Bellinger" Cc: ips@ietf.org, ips-admin@ietf.org, Julian Satran , pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: [Ips] : Considerations for Asymmetric iSCSI Implementations Draft Interest? X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: John Hufferd Message-ID: Date: Tue, 18 Nov 2003 00:30:00 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.2CF2HF92 | October 15, 2003) at 11/18/2003 01:30:06, Serialize complete at 11/18/2003 01:30:06 Content-Type: multipart/alternative; boundary="=_alternative 002E9D3D88256DE2_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 002E9D3D88256DE2_= Content-Type: text/plain; charset="us-ascii" Well until I see some compelling numbers, we will probably just continue to disagree. But I think compelling numbers is what is needed before we would think about opening this up. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Nicholas A. Bellinger" Sent by: ips-admin@ietf.org 11/17/2003 10:17 PM To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ietf.org, ips-admin@ietf.org, Julian Satran , pat_thaler@agilent.com Subject: RE: [Ips] : Considerations for Asymmetric iSCSI Implementations Draft Interest? John, On Mon, 2003-11-17 at 17:06, John Hufferd wrote: > Yes, it is anyone's guess what the performance improvement (if any) > there would be. But you are saying that with specialty engines, you > could go faster. On the other hand many of the implementations I have > seen have speciality engines and speciality paths. In your example, > if I understood it correctly, you have 4 connections for the > Asymmetric case. But you don't seem to talk about that with your > Symmetric case. > Point taken in the symmetric case. The goal was to show operations based with multiple connections. The same basic operation would occur in the symmetric example with four connections. > Also, you talk about the CmdSN window, but it seemed that you > specified it as a connection based item. However, since it is a > Session Wide value, any of the example's four connections would be > able to start transferring the very next command. So there would be > NO hold up waiting to send the command on another connection, as long > as a connection was freed. And since that is basically the same > limitation for the Asymmetric case (a connection must be free to send > data, or anything), I do not see the problem, let alone the fix. > The CmdSN was used in context of each control connection or normal connection TX thread checking the session wide CmdSN window for an opening to send non immediate commands, sorry for the confusion. The delay I was trying to convey in the symmetric example is not a session wide delay of other connections unable to send non immediate commands when the CmdSN window opens, but other connections being busy fullfilling interconnection requests such as Unsolicited DataOut. > Remember you can have Multiple Connections per Session (MC/S), between > physically different Portals, or you can have MC/S within a single > Physical Portal via multiple logical connections. So everything you > want to do is doable, and without a clear reason why an Asymmetric > case is better, I can not see us dealing with it. (Some deep math is > probably needed here.) > . > . I am not questioning any of these points, the main concept being addressed here with control and data connections is keeping each of them as busy as possible doing their specifics jobs: Control Connection: Checking CmdSN window openings for sending non immediate commands. ie: a single session wide request queue. Data Connection: Checking for pending Unsolicited or Solicited DataOUT. ie: a single connection wide request queue. Compared to: Normal Connection: At absolute least two queues. One checking for pending Unsolicited or Solicited DataOUT requests (connection wide), and one for checking openings in the CmdSN window for sending non immediate commands (session wide). (I believe the IBM iSCSI Initiator for Linux based on draft v8 had three queues. Immediate (connection wide), R2T (connection wide), and session wide queue checked when the CmdSN window opened). Back to the performance question, I completely agree. It is anyones guess and will remain that until someone comes up with numbers for various cases. (It could very well be difficult to beat symmetric ImmediateData performance when the entire request size fits in FirstBurstLength, as good implementations do today). In any event I still firmly believe that an asymmetric model will scale futher and have a better cache hit ratio than its symmetric couterpart in the pure software case. Thanks! -- Nicholas A. Bellinger > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/System Group, San Jose CA > Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Alt Office: (408) 997-6136, Cell: (408) 499-9702 > Internet Address: hufferd@us.ibm.com > > > > "Nicholas A. Bellinger" > > > 11/17/2003 02:42 PM > > To: John > Hufferd/San > Jose/IBM@IBMUS > cc: > ips@ietf.org, > ips-admin@ietf.org, > Julian Satran > , pat_thaler@agilent.com > Subject: > RE: [Ips] : > Considerations for > Asymmetric iSCSI > Implementations > Draft Interest? > > > John, > > I can think of a few reasons while trying not to go too deep into > implementation specific details. These have to do with my idea of > achieving maximum parallelism, which probably is not the same as > other > peoples. Again these are purely speculation. (speculation == more > threads doing simpler operations will be faster as connection count > increases) > > Non Immedate Unsolicited DataOUT Case, assume FirstBurstLength >= SCSI > Request size. > > > Asymmetric: > > 2 Control Channels and 2 Data Channels: > CID 0 and 1: Control Channels 0 and 1 > CID 2 and 3: Data Channels 0 and 1 > > Only operation is checking CmdSN window to send commands: > > 0) TX threads for CID 0 and 1 checking CmdSN window to send non > immediate commands. > 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID > 0. > 2) iSCSI Scsi Cmnd Opcode is built on CID 0 and unsolicited DataOUT > request gets added to CID 2 from CID 0. > 3) A and B can happen in any order: > 3A) iSCSI Scsi Cmnd Opcode gets sent on CID 0. > 3B) iSCSI Unsolicited DataOUT request gets queued and Unsolicited > DataOUT is built on CID 2. > 4) iSCSI Unsolicited DataOUT is sent on CID 2 after iSCSI Scsi Cmnd > Opcode is sent on CID 0. > 5) TX thread for CID 1 detects open CmdSN window and the process > starts > over again with CID 1 and CID 3. > > Problem: > Latency issue of iSCSI Unsolicited DataOUT arriving before iSCSI Scsi > Cmnd Opcode. > > > Symmetric: > > 2 iSCSI Connections: > CID 0 and 1 > > 0) TX threads for CID 0 and 1 checking CmdSN window to send non > immediate commands. > 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID > 0. > 2) iSCSI Scsi Cmnd Opcode is built on CID 0. > 3) iSCSI Scsi Cmnd Opcode is sent on CID 0, and adds Unsolicited > DataOUT > request to CID 0 queue. > 4) Either A or B may happen next (matter of implementation) > 4A) CID 0 builds Unsolicited DataOUT. > 4B) CID 0 detects CmdSN window is open and sends more non-immediate > commands, only until after CmdSN window closes does it send > Unsolicited > DataOUT. > 5) TX thread for CID 1 detects CmdSN window and the process starts > over > again with CID 1. > > Problem: > CID 0 having to build and send DataOUT while it could be sending > another > iSCSI Scsi Cmnd Opcode while the CmdSN window is open. > > > This is just one scenario off the top of my head and could be written > off as a matter of implementation, but the asymmetric goal is to > achieve maximum parallelism by A) threads doing smaller specialized > jobs, and B) Control threads queuing up more iSCSI Scsi Cmnds faster > to > Data Threads checking a single queue. As far as performance > percentage > improvement I cannot begin to dream up numbers until an asymmetric > prototype is complete, and very well could only show improvements in > specific configurations, but it is anyones guess. > > Thanks! > > -- > Nicholas A. Bellinger > > > On Mon, 2003-11-17 at 13:26, John Hufferd wrote: > > I am not sure why we would ever want to do this. How does this > > improve the performance over normal Multiple Connections per > Session? > > And what is the projected improvement (%)? > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/System Group, San Jose CA > > Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Alt Office: (408) 997-6136, Cell: (408) 499-9702 > > Internet Address: hufferd@us.ibm.com > > > > > > > > "Nicholas A. Bellinger" > > > > Sent by: > > ips-admin@ietf.org > > > > 11/17/2003 12:01 PM > > > > To: > > pat_thaler@agilent.com > > cc: > > ips@ietf.org, Julian > > Satran > > > > Subject: > > RE: [Ips] [IPS]: > > Considerations for > > Asymmetric iSCSI > > Implementati ons > > Draft Interest? > > > > > > Pat, > > > > > http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf > > > > The following paper from Kalman Meth decribes them on page 12: > > > > Asymmetric: > > Single Control Channel / iSCSI Connection. > > > > Multiple Data Channels / iSCSI Connection. > > > > Control Channel used to transfer commands, status, and task > > management. > > > > Symmetric: > > All Channels / iSCSI Connections identical. > > > > Send Data and Status over same Channel / iSCSI Connection as > > corresponding command. > > > > > > > > I am not exactly sure why the single control channel restriction was > > imposed in the asymmetric case, but imagine its no longer an issue > to > > have multiple control channels. Perhaps this was before the advent > of > > session wide CmdSN ordering? > > > > Some of the more interesting questions: > > > > Connection recovery case, which connection an inflight command is > > alligent to when the control and/or data connection fails. > > > > Requirements for falling back when an session runs out of control > > and/or > > data channels. Or is it just easier to do session reinstatement > into > > an symmetric session. > > > > How strict are the requirements for data on the control channel and > > control primatives in the data channel? Immediate DataOut comes to > > mind > > in the former case, and Phase Collapse for DataIn in the latter. > > > > Thanks! > > > > On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote: > > > I'm not clear on what you mean by "asymetric". > > > > > > -----Original Message----- > > > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > > > Sent: Monday, November 17, 2003 10:20 AM > > > To: ips@ietf.org; Julian_Satran@il.ibm.com > > > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > > > Implementations Draft Interest? > > > > > > > > > Greetings All, > > > > > > I am inquiring about interest in seeing a draft > and > > possibly RFC > > > regarding Considerations for Asymmetric iSCSI Implementations. I > > recall > > > seeing some discussion on this topic back in 2000, and aside from > a > > few > > > other mentions of the model in various design documents I have not > > seen > > > any followups. I am curious if the model had all but been > abandoned > > for > > > the symmetric model in traditional and iSER iSCSI, or if there is > > still > > > room in the protocol for asymmetric operations? > > > > > > I have been thinking about this topic for a while and specifically > > its > > > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get > > some > > > feedback from list members if it would be worthwhile for someone > > (mabye > > > even me!) to put the thoughts down for other interested parties to > > > consider. > > > > > > Aside from the expected responses of complexity issues for simple > > > implementations, I do not see a terrible amount of extra > > functionality > > > required for ErrorRecoveryLevel=1 and above implementations to > > operate > > > in an Asymmetric model, and literally no changes to RFC 3347. As > to > > the > > > benefits of running in a Asymmetric model I can only speculate, > > > although I suppose most are related performance in multiple > > connection > > > ErrorRecoveryLevel=1 and above software implementations. > > > > > > Any feedback is welcome! > > > > > > -- > > > Nicholas A. Bellinger > > > > > > > > > _______________________________________________ > > > Ips mailing list > > > Ips@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ips > > -- > > Nicholas A. Bellinger > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 002E9D3D88256DE2_= Content-Type: text/html; charset="us-ascii"
Well until I see some compelling numbers, we will probably just continue to disagree.  But I think compelling numbers is what is needed before we would think about opening this up.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


"Nicholas A. Bellinger" <nick@pyxtechnologies.com>
Sent by: ips-admin@ietf.org

11/17/2003 10:17 PM

       
        To:        John Hufferd/San Jose/IBM@IBMUS
        cc:        ips@ietf.org, ips-admin@ietf.org, Julian Satran <Julian_Satran@il.ibm.com>, pat_thaler@agilent.com
        Subject:        RE: [Ips] : Considerations for Asymmetric iSCSI Implementations        Draft Interest?



John,

On Mon, 2003-11-17 at 17:06, John Hufferd wrote:
> Yes, it is anyone's guess what the performance improvement (if any)
> there would be. But you are saying that with specialty engines, you
> could go faster.  On the other hand many of the implementations I have
> seen have speciality engines and speciality paths.  In your example,
> if I understood it correctly, you have 4 connections for the
> Asymmetric case.  But you don't seem to talk about that with your
> Symmetric case.
>

Point taken in the symmetric case.  The goal was to show operations
based with multiple connections.   The same basic operation would occur
in the symmetric example with four connections.


> Also, you talk about the CmdSN window, but it seemed that you
> specified it as a connection based item.  However, since it is a
> Session Wide value, any of the example's four connections would be
> able to start transferring the very next command.  So there would be
> NO hold up waiting to send the command on another connection, as long
> as a connection was freed.  And since that is basically the same
> limitation for the Asymmetric case (a connection must be free to send
> data, or anything), I do not see the problem, let alone the fix.
>

The CmdSN was used in context of each control connection or normal
connection TX thread checking the session wide CmdSN window for an
opening to send non immediate commands, sorry for the confusion.  The
delay I was trying to convey in the symmetric example is not a session
wide delay of other connections unable to send non immediate commands
when the CmdSN window opens, but other connections being busy
fullfilling interconnection requests such as Unsolicited DataOut.


> Remember you can have Multiple Connections per Session (MC/S), between
> physically different Portals, or you can have MC/S within a single
> Physical Portal via multiple logical connections.  So everything you
> want to do is doable, and without a clear reason why an Asymmetric
> case is better, I can not see us dealing with it.  (Some deep math is
> probably needed here.)
> .
> .

I am not questioning any of these points,  the main concept being
addressed here with control and data connections is keeping each of them
as busy as possible doing their specifics jobs:

Control Connection: Checking CmdSN window openings for sending non
immediate commands. ie: a single session wide request queue.

Data Connection: Checking for pending Unsolicited or Solicited DataOUT.
ie: a single connection wide request queue.

Compared to:

Normal Connection: At absolute least two queues.  One checking for
pending Unsolicited or Solicited DataOUT requests (connection wide), and
one for checking openings in the CmdSN window for sending non immediate
commands (session wide).
(I believe the IBM iSCSI Initiator for Linux based on draft v8 had three
queues.  Immediate (connection wide), R2T (connection wide), and session
wide queue checked when the CmdSN window opened).


Back to the performance question,  I completely agree.  It is anyones
guess and will remain that until someone comes up with numbers for
various cases. (It could very well be difficult to beat symmetric
ImmediateData performance when the entire request size fits in
FirstBurstLength, as good implementations do today).  In any event I
still firmly believe that an asymmetric model will scale futher and have
a better cache hit ratio than its symmetric couterpart in the pure
software case.


Thanks!

--
Nicholas A. Bellinger <nick@pyxtechnologies.com>


> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/System Group, San Jose CA
> Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
> Alt Office: (408) 997-6136, Cell: (408) 499-9702
> Internet Address: hufferd@us.ibm.com
>
>
>
> "Nicholas A. Bellinger"
> <nick@pyxtechnologies.com>
>
> 11/17/2003 02:42 PM
>        
>         To:        John
> Hufferd/San
> Jose/IBM@IBMUS
>         cc:      
> ips@ietf.org,
> ips-admin@ietf.org,
> Julian Satran
> <Julian_Satran@il.ibm.com>, pat_thaler@agilent.com
>         Subject:      
> RE: [Ips] :
> Considerations for
> Asymmetric iSCSI
> Implementations      
> Draft Interest?
>
>
> John,
>
> I can think of a few reasons while trying not to go too deep into
> implementation specific details.  These have to do with my idea of
> achieving maximum parallelism,  which probably is not the same as
> other
> peoples. Again these are purely speculation. (speculation == more
> threads doing simpler operations will be faster as connection count
> increases)
>
> Non Immedate Unsolicited DataOUT Case, assume FirstBurstLength >= SCSI
> Request size.
>
>
> Asymmetric:
>
> 2 Control Channels and 2 Data Channels:
> CID 0 and 1: Control Channels 0 and 1
> CID 2 and 3: Data Channels 0 and 1
>
> Only operation is checking CmdSN window to send commands:
>
> 0) TX threads for CID 0 and 1 checking CmdSN window to send non
> immediate commands.
> 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID
> 0.
> 2) iSCSI Scsi Cmnd Opcode is built on CID 0 and unsolicited DataOUT
> request gets added to CID 2 from CID 0.
> 3) A and B can happen in any order:
> 3A) iSCSI Scsi Cmnd Opcode gets sent on CID 0.
> 3B) iSCSI Unsolicited DataOUT request gets queued and Unsolicited
> DataOUT is built on CID 2.
> 4) iSCSI Unsolicited DataOUT is sent on CID 2 after iSCSI Scsi Cmnd
> Opcode is sent on CID 0.
> 5) TX thread for CID 1 detects open CmdSN window and the process
> starts
>   over again with CID 1 and CID 3.
>
> Problem:
> Latency issue of iSCSI Unsolicited DataOUT arriving before iSCSI Scsi
> Cmnd Opcode.
>
>
> Symmetric:  
>
> 2 iSCSI Connections:
> CID 0 and 1
>
> 0) TX threads for CID 0 and 1 checking CmdSN window to send non
> immediate commands.
> 1) CmdSN window opens for CID 0, iSCSI command becomes alligent to CID
> 0.
> 2) iSCSI Scsi Cmnd Opcode is built on CID 0.
> 3) iSCSI Scsi Cmnd Opcode is sent on CID 0, and adds Unsolicited
> DataOUT
> request to CID 0 queue.
> 4) Either A or B may happen next (matter of implementation)
> 4A) CID 0 builds Unsolicited DataOUT.
> 4B) CID 0 detects CmdSN window is open and sends more non-immediate
> commands, only until after CmdSN window closes does it send
> Unsolicited
> DataOUT.
> 5) TX thread for CID 1 detects CmdSN window and the process starts
> over
> again with CID 1.
>
> Problem:
> CID 0 having to build and send DataOUT while it could be sending
> another
> iSCSI Scsi Cmnd Opcode while the CmdSN window is open.
>
>
> This is just one scenario off the top of my head and could be written
> off as a matter of implementation,  but the asymmetric goal is to
> achieve maximum parallelism by A) threads doing smaller specialized
> jobs, and B) Control threads queuing up more iSCSI Scsi Cmnds faster
> to
> Data Threads checking a single queue.  As far as performance
> percentage
> improvement I cannot begin to dream up numbers until an asymmetric
> prototype is complete, and very well could only show improvements in
> specific configurations,  but it is anyones guess.
>
> Thanks!
>
> --
> Nicholas A. Bellinger <nick@pyxtechnologies.com>
>
>
> On Mon, 2003-11-17 at 13:26, John Hufferd wrote:
> > I am not sure why we would ever want to do this.  How does this
> > improve the performance over normal Multiple Connections per
> Session?
> > And what is the projected improvement (%)?
> > .
> > .
> > John L. Hufferd
> > Senior Technical Staff Member (STSM)
> > IBM/System Group, San Jose CA
> > Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
> > Alt Office: (408) 997-6136, Cell: (408) 499-9702
> > Internet Address: hufferd@us.ibm.com
> >
> >
> >
> > "Nicholas A. Bellinger"
> > <nick@pyxtechnologies.com>
> > Sent by:
> > ips-admin@ietf.org
> >
> > 11/17/2003 12:01 PM
> >        
> >         To:      
> > pat_thaler@agilent.com
> >         cc:      
> > ips@ietf.org, Julian
> > Satran
> > <Julian_Satran@il.ibm.com>
> >         Subject:      
> > RE: [Ips] [IPS]:
> > Considerations for
> > Asymmetric iSCSI
> > Implementati        ons
> > Draft Interest?
> >
> >
> > Pat,
> >
> >
> http://www.haifa.il.ibm.com/Workshops/Storage2002/papers/iscsiDesign.pdf
> >
> > The following paper from Kalman Meth decribes them on page 12:
> >
> > Asymmetric:
> > Single Control Channel / iSCSI Connection.
> >
> > Multiple Data Channels / iSCSI Connection.
> >
> > Control Channel used to transfer commands, status, and task
> > management.
> >
> > Symmetric:
> > All Channels / iSCSI Connections identical.
> >
> > Send Data and Status over same Channel / iSCSI Connection as  
> > corresponding command.
> >
> >
> >
> > I am not exactly sure why the single control channel restriction was
> > imposed in the asymmetric case, but imagine its no longer an issue
> to
> > have multiple control channels.  Perhaps this was before the advent
> of
> > session wide CmdSN ordering?
> >
> > Some of the more interesting questions:
> >
> > Connection recovery case, which connection an inflight command is
> > alligent to when the control and/or data connection fails.
> >
> > Requirements for falling back when an session runs out of control
> > and/or
> > data channels.  Or is it just easier to do session reinstatement
> into
> > an symmetric session.
> >
> > How strict are the requirements for data on the control channel and
> > control primatives in the data channel?  Immediate DataOut comes to
> > mind
> > in the former case, and Phase Collapse for DataIn in the latter.
> >
> > Thanks!
> >
> > On Mon, 2003-11-17 at 11:17, pat_thaler@agilent.com wrote:
> > > I'm not clear on what you mean by "asymetric".
> > >
> > > -----Original Message-----
> > > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com]
> > > Sent: Monday, November 17, 2003 10:20 AM
> > > To: ips@ietf.org; Julian_Satran@il.ibm.com
> > > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI
> > > Implementations Draft Interest?
> > >
> > >
> > > Greetings All,
> > >                  
> > >                  I am inquiring about interest in seeing a draft
> and
> > possibly RFC
> > > regarding Considerations for Asymmetric iSCSI Implementations.  I
> > recall
> > > seeing some discussion on this topic back in 2000, and aside from
> a
> > few
> > > other mentions of the model in various design documents I have not
> > seen
> > > any followups.  I am curious if the model had all but been
> abandoned
> > for
> > > the symmetric model in traditional and iSER iSCSI, or if there is
> > still
> > > room in the protocol for asymmetric operations?
> > >
> > > I have been thinking about this topic for a while and specifically
> > its
> > > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get
> > some
> > > feedback from list members if it would be worthwhile for someone
> > (mabye
> > > even me!) to put the thoughts down for other interested parties to
> > > consider.
> > >
> > > Aside from the expected responses of complexity issues for simple
> > > implementations,  I do not see a terrible amount of extra
> > functionality
> > > required for ErrorRecoveryLevel=1 and above implementations to
> > operate
> > > in an Asymmetric model, and literally no changes to RFC 3347.  As
> to
> > the
> > > benefits of running in a Asymmetric model I can only speculate,
> > > although I suppose most are related performance in multiple
> > connection
> > > ErrorRecoveryLevel=1 and above software implementations.
> > >
> > > Any feedback is welcome!                
> > >
> > > --
> > > Nicholas A. Bellinger <nick@pyxtechnologies.com>
> > >
> > >
> > > _______________________________________________
> > > Ips mailing list
> > > Ips@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ips
> > --
> > Nicholas A. Bellinger <nick@pyxtechnologies.com>
> >
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
>
>



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

--=_alternative 002E9D3D88256DE2_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Nov 18 03:55:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10517 for ; Tue, 18 Nov 2003 03:55:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1dc-00024O-AU for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 03:55:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI8t7J7007956 for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 03:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1da-00024F-Vr for ips-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 03:55:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10506 for ; Tue, 18 Nov 2003 03:54:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM1dY-0000f7-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 03:55:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM1dY-0000f3-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 03:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1dX-00022W-BC; Tue, 18 Nov 2003 03:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1dU-00021Z-7c for ips@optimus.ietf.org; Tue, 18 Nov 2003 03:55:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10503 for ; Tue, 18 Nov 2003 03:54:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM1dR-0000f0-00 for ips@ietf.org; Tue, 18 Nov 2003 03:54:57 -0500 Received: from web42001.mail.yahoo.com ([66.218.93.169]) by ietf-mx with smtp (Exim 4.12) id 1AM1dQ-0000et-00 for ips@ietf.org; Tue, 18 Nov 2003 03:54:57 -0500 Message-ID: <20031118085427.97112.qmail@web42001.mail.yahoo.com> Received: from [64.163.148.74] by web42001.mail.yahoo.com via HTTP; Tue, 18 Nov 2003 00:54:27 PST Date: Tue, 18 Nov 2003 00:54:27 -0800 (PST) From: Alberto Alesina To: ips@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-827380614-1069145667=:90544" Subject: [Ips] target device Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , --0-827380614-1069145667=:90544 Content-Type: text/plain; charset=us-ascii hello, i am new to iSCSI and have a basic question about iSCSI - how would the initiator know about the disk capacity of the target devices (to calculate the maximum logical block address) ? is this part of the iSCSI protocol? thanks a lot.... alberto alesina --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-827380614-1069145667=:90544 Content-Type: text/html; charset=us-ascii
hello,
i am new to iSCSI and have a basic question about iSCSI - how would the initiator know about the disk capacity of the target devices (to calculate the maximum logical block address) ?  is this part of the iSCSI protocol?
 
thanks a lot....
alberto alesina

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-827380614-1069145667=:90544-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Nov 18 03:59:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10697 for ; Tue, 18 Nov 2003 03:59:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1hS-0002Rn-5M for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 03:59:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI8x5xw009200 for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 03:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1hQ-0002Nh-3z for ips-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 03:59:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10675 for ; Tue, 18 Nov 2003 03:58:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM1hN-0000is-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 03:59:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM1hN-0000ip-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 03:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1hN-0002Lq-2B; Tue, 18 Nov 2003 03:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM1h7-0002LF-3J for ips@optimus.ietf.org; Tue, 18 Nov 2003 03:58:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10650 for ; Tue, 18 Nov 2003 03:58:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM1h4-0000iG-00 for ips@ietf.org; Tue, 18 Nov 2003 03:58:42 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1AM1h2-0000ht-00 for ips@ietf.org; Tue, 18 Nov 2003 03:58:41 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAI8vbwj063804; Tue, 18 Nov 2003 08:57:39 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAI8vXN9278648; Tue, 18 Nov 2003 09:57:33 +0100 In-Reply-To: To: Andre Hedrick Cc: ips@ietf.org, nick@pyxtechnologies.com, pat_thaler@agilent.com Subject: RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Julian Satran Message-ID: Date: Tue, 18 Nov 2003 10:57:31 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 18/11/2003 10:57:34, Serialize complete at 18/11/2003 10:57:34 Content-Type: multipart/alternative; boundary="=_alternative 00311B55C2256DE2_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00311B55C2256DE2_= Content-Type: text/plain; charset="US-ASCII" I doubt that you will find enough interest in the (IETF) community to pursue this seriously. We did try this path (not very long nor very deep) because it felt promising and with a single active control channel we could ahve avoided command numbering and eliminate the usual head-of-queue blocking by large data transfers usually associated with symmetric solutions. There where a number of reasons why the "community" felt at the time that this is not worth pursuing - complexity, ability to operate (in case of hardware adapters) across card/chip boundaries, lack of compelling advantages (although many of us did not feel that way). We did even discuss the very attractive fact the control and data paths could be targeted to different units. After a while we felt that it is more important to make progress that to pursue both the asymmetric and the symmetric solutions - and the rest is history. Julo Andre Hedrick 17/11/2003 21:42 To pat_thaler@agilent.com cc nick@pyxtechnologies.com, ips@ietf.org, Julian Satran/Haifa/IBM@IBMIL Subject RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? Pat: A simple method of spliting the command and data transports over their own respective connections. It is clear the command layer transactions will arrive before the following data transactions. There are obvious reason to split the layers, yet they generate a new level of error recovery. The principle reason to split the two is based on performance by allowing the target to prebuild buffers to optimize memory management and io scheduling events. PyX will present such a model for the next version of the iSCSI RFC. There are no patents involved, and this conforms to the goals of IETF. Regards, Andre On Mon, 17 Nov 2003 pat_thaler@agilent.com wrote: > I'm not clear on what you mean by "asymetric". > > -----Original Message----- > From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com] > Sent: Monday, November 17, 2003 10:20 AM > To: ips@ietf.org; Julian_Satran@il.ibm.com > Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI > Implementations Draft Interest? > > > Greetings All, > > I am inquiring about interest in seeing a draft and possibly RFC > regarding Considerations for Asymmetric iSCSI Implementations. I recall > seeing some discussion on this topic back in 2000, and aside from a few > other mentions of the model in various design documents I have not seen > any followups. I am curious if the model had all but been abandoned for > the symmetric model in traditional and iSER iSCSI, or if there is still > room in the protocol for asymmetric operations? > > I have been thinking about this topic for a while and specifically its > affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some > feedback from list members if it would be worthwhile for someone (mabye > even me!) to put the thoughts down for other interested parties to > consider. > > Aside from the expected responses of complexity issues for simple > implementations, I do not see a terrible amount of extra functionality > required for ErrorRecoveryLevel=1 and above implementations to operate > in an Asymmetric model, and literally no changes to RFC 3347. As to the > benefits of running in a Asymmetric model I can only speculate, > although I suppose most are related performance in multiple connection > ErrorRecoveryLevel=1 and above software implementations. > > Any feedback is welcome! > > -- > Nicholas A. Bellinger > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > --=_alternative 00311B55C2256DE2_= Content-Type: text/html; charset="US-ASCII"
I doubt that you will find enough interest in the (IETF) community to pursue this seriously.
We did try this path (not very long nor very deep) because it felt promising and with a single active control channel we could ahve avoided command numbering and eliminate the usual head-of-queue blocking by large data transfers usually associated with symmetric solutions.

There where a number of reasons why the "community" felt at the time that this is not worth pursuing - complexity, ability to operate (in case of hardware adapters) across card/chip boundaries, lack of compelling advantages (although many of us did not feel that way). We did even discuss the very attractive fact the control and data paths could be targeted to different units. After a while we felt that it is more important to make progress that to pursue both the asymmetric and the symmetric solutions - and the rest is history.

Julo


Andre Hedrick <andre@pyxtechnologies.com>

17/11/2003 21:42

To
pat_thaler@agilent.com
cc
nick@pyxtechnologies.com, ips@ietf.org, Julian Satran/Haifa/IBM@IBMIL
Subject
RE: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest?






Pat:

A simple method of spliting the command and data transports over their own
respective connections.  It is clear the command layer transactions will
arrive before the following data transactions.

There are obvious reason to split the layers, yet they generate a new
level of error recovery.

The principle reason to split the two is based on performance by allowing
the target to prebuild buffers to optimize memory management and io
scheduling events.

PyX will present such a model for the next version of the iSCSI RFC.
There are no patents involved, and this conforms to the goals of IETF.

Regards,

Andre

On Mon, 17 Nov 2003 pat_thaler@agilent.com wrote:

> I'm not clear on what you mean by "asymetric".
>
> -----Original Message-----
> From: Nicholas A. Bellinger [mailto:nick@pyxtechnologies.com]
> Sent: Monday, November 17, 2003 10:20 AM
> To: ips@ietf.org; Julian_Satran@il.ibm.com
> Subject: [Ips] [IPS]: Considerations for Asymmetric iSCSI
> Implementations Draft Interest?
>
>
> Greetings All,
>                  
>                  I am inquiring about interest in seeing a draft and possibly RFC
> regarding Considerations for Asymmetric iSCSI Implementations.  I recall
> seeing some discussion on this topic back in 2000, and aside from a few
> other mentions of the model in various design documents I have not seen
> any followups.  I am curious if the model had all but been abandoned for
> the symmetric model in traditional and iSER iSCSI, or if there is still
> room in the protocol for asymmetric operations?
>
> I have been thinking about this topic for a while and specifically its
> affects on ErrorRecoveryLevel=2 implemenatations and wanted to get some
> feedback from list members if it would be worthwhile for someone (mabye
> even me!) to put the thoughts down for other interested parties to
> consider.
>
> Aside from the expected responses of complexity issues for simple
> implementations,  I do not see a terrible amount of extra functionality
> required for ErrorRecoveryLevel=1 and above implementations to operate
> in an Asymmetric model, and literally no changes to RFC 3347.  As to the
> benefits of running in a Asymmetric model I can only speculate,
> although I suppose most are related performance in multiple connection
> ErrorRecoveryLevel=1 and above software implementations.
>
> Any feedback is welcome!                
>
> --
> Nicholas A. Bellinger <nick@pyxtechnologies.com>
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>


--=_alternative 00311B55C2256DE2_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Nov 18 12:46:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03451 for ; Tue, 18 Nov 2003 12:46:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9vW-0003vW-NK for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 12:46:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIHkAOX015090 for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 12:46:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9vV-0003vJ-Pd for ips-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 12:46:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03437 for ; Tue, 18 Nov 2003 12:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9vU-0001tZ-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 12:46:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM9vT-0001tW-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 12:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9vN-0003u9-3e; Tue, 18 Nov 2003 12:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9uz-0003tB-6x for ips@optimus.ietf.org; Tue, 18 Nov 2003 12:45:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03419 for ; Tue, 18 Nov 2003 12:45:23 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9ux-0001sz-00 for ips@ietf.org; Tue, 18 Nov 2003 12:45:35 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1AM9uw-0001sw-00 for ips@ietf.org; Tue, 18 Nov 2003 12:45:34 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 2FDE32198B; Tue, 18 Nov 2003 10:45:33 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 1605910B; Tue, 18 Nov 2003 10:45:33 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3ADFB.C28839D0" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Ips] target device Date: Tue, 18 Nov 2003 10:45:30 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0132E05E9@axcs04.cos.agilent.com> Thread-Topic: [Ips] target device Thread-Index: AcOtsbYORw6KNTmXSHSaAf/ZPbZKAQAScufQ To: , Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADFB.C28839D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Things such as this are all in the SCSI protocol rather than the iSCSI = protocol. That way they are common to all SCSI and not dependant on the = underlying transport (transport in SCSI terms rather than IETF usage of = the word, e.g. iSCSI, Fibre Channel, SAS). -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of Alberto = Alesina Sent: Tuesday, November 18, 2003 12:54 AM To: ips@ietf.org Subject: [Ips] target device hello, i am new to iSCSI and have a basic question about iSCSI - how would the = initiator know about the disk capacity of the target devices (to = calculate the maximum logical block address) ? is this part of the = iSCSI protocol? =20 thanks a lot.... alberto alesina _____ =20 Do you Yahoo!? Protect your identity with = Yahoo! Mail AddressGuard ------_=_NextPart_001_01C3ADFB.C28839D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Things = such as this=20 are all in the SCSI protocol rather than the iSCSI protocol. That way = they are=20 common to all SCSI and not dependant on the underlying transport = (transport in=20 SCSI terms rather than IETF usage of the word, e.g. iSCSI, Fibre = Channel,=20 SAS).
-----Original Message-----
From: ips-admin@ietf.org = [mailto:ips-admin@ietf.org]On Behalf Of Alberto = Alesina
Sent:=20 Tuesday, November 18, 2003 12:54 AM
To:=20 ips@ietf.org
Subject: [Ips] target = device

hello,
i am new to iSCSI and have a basic question about iSCSI -=20 how would the initiator know about the disk = capacity of=20 the target devices (to calculate the maximum logical block = address)=20 ?  is this part of the iSCSI protocol?
 
thanks a lot....
alberto alesina

Do you Yahoo!?
Protect=20 your identity with Yahoo! Mail = AddressGuard
------_=_NextPart_001_01C3ADFB.C28839D0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Nov 19 00:04:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06569 for ; Wed, 19 Nov 2003 00:04:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMKVb-0007vh-BG for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 00:04:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ547Xm030477 for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 00:04:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMKVb-0007vU-7D for ips-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 00:04:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06555 for ; Wed, 19 Nov 2003 00:03:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMKVY-00009r-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 00:04:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMKVY-00009n-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 00:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMKVV-0007uU-45; Wed, 19 Nov 2003 00:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMKVK-0007uG-FF for ips@optimus.ietf.org; Wed, 19 Nov 2003 00:03:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06549 for ; Wed, 19 Nov 2003 00:03:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMKVI-00009j-00 for ips@ietf.org; Wed, 19 Nov 2003 00:03:48 -0500 Received: from web20702.mail.yahoo.com ([216.136.226.175]) by ietf-mx with smtp (Exim 4.12) id 1AMKVH-00009g-00 for ips@ietf.org; Wed, 19 Nov 2003 00:03:47 -0500 Message-ID: <20031119050347.54958.qmail@web20702.mail.yahoo.com> Received: from [66.243.153.70] by web20702.mail.yahoo.com via HTTP; Tue, 18 Nov 2003 21:03:47 PST Date: Tue, 18 Nov 2003 21:03:47 -0800 (PST) From: dan yo To: ips@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-584693056-1069218227=:54062" Subject: [Ips] iSCSI cmd ordering and tagged task Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , --0-584693056-1069218227=:54062 Content-Type: text/plain; charset=us-ascii It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI. For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access. However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target. This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not. Is my concern valid? Thanks, Dan --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-584693056-1069218227=:54062 Content-Type: text/html; charset=us-ascii
It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI.  For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access.  However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target.  This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid?
Thanks,
Dan

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-584693056-1069218227=:54062-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Nov 19 02:22:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28713 for ; Wed, 19 Nov 2003 02:22:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMfL-0007O6-QX for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 02:22:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ7MJP1028397 for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 02:22:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMfK-0007Nw-TQ for ips-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 02:22:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28136 for ; Wed, 19 Nov 2003 02:22:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMMfG-0001rK-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 02:22:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMMfG-0001rH-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 02:22:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMf5-0007Mb-Sx; Wed, 19 Nov 2003 02:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMeN-0007JC-ES for ips@optimus.ietf.org; Wed, 19 Nov 2003 02:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27054; Wed, 19 Nov 2003 02:21:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMMeJ-0001qn-00; Wed, 19 Nov 2003 02:21:15 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1AMMeI-0001pz-00; Wed, 19 Nov 2003 02:21:14 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAJ7KhHf079416; Wed, 19 Nov 2003 07:20:43 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAJ7KggU265210; Wed, 19 Nov 2003 08:20:42 +0100 In-Reply-To: <20031119050347.54958.qmail@web20702.mail.yahoo.com> To: dan yo Cc: ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] iSCSI cmd ordering and tagged task MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Julian Satran Message-ID: Date: Wed, 19 Nov 2003 09:20:40 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 19/11/2003 09:20:42, Serialize complete at 19/11/2003 09:20:42 Content-Type: multipart/alternative; boundary="=_alternative 00285883C2256DE3_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00285883C2256DE3_= Content-Type: text/plain; charset="US-ASCII" I do not think your concern is valid. The skew introduced by multiple connections - when those operate correctly - is minimal. The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering. It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock. Julo dan yo Sent by: ips-admin@ietf.org 19/11/2003 07:03 To ips@ietf.org cc Subject [Ips] iSCSI cmd ordering and tagged task It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI. For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access. However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target. This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid? Thanks, Dan Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --=_alternative 00285883C2256DE3_= Content-Type: text/html; charset="US-ASCII"
I do not think your concern is valid.  The skew introduced by multiple connections - when those operate correctly - is minimal.
The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering.
It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock.

Julo



dan yo <ipsandude@yahoo.com>
Sent by: ips-admin@ietf.org

19/11/2003 07:03

To
ips@ietf.org
cc
Subject
[Ips] iSCSI cmd ordering and tagged task





It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI.  For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access.  However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target.  This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid?
Thanks,
Dan

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

--=_alternative 00285883C2256DE3_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Nov 19 09:51:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18727 for ; Wed, 19 Nov 2003 09:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTfj-0006g6-87 for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 09:51:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJEpBqt025670 for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 09:51:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTfj-0006fx-3V for ips-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 09:51:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18722 for ; Wed, 19 Nov 2003 09:50:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTfh-0000OM-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 09:51:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMTfg-0000OJ-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 09:51:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTfZ-0006eh-KT; Wed, 19 Nov 2003 09:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTfK-0006dq-Jk for ips@optimus.ietf.org; Wed, 19 Nov 2003 09:50:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18710 for ; Wed, 19 Nov 2003 09:50:32 -0500 (EST) From: dcuddihy@attotech.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTfI-0000Ny-00 for ips@ietf.org; Wed, 19 Nov 2003 09:50:44 -0500 Received: from [12.32.232.56] (helo=noteserv1.attotech.com) by ietf-mx with esmtp (Exim 4.12) id 1AMTfI-0000Nu-00 for ips@ietf.org; Wed, 19 Nov 2003 09:50:44 -0500 Subject: Re: [Ips] iSCSI cmd ordering and tagged task To: dan yo Cc: ips@ietf.org Message-ID: Date: Wed, 19 Nov 2003 09:50:28 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Dan, This is not really a limitation since iSCSI allows commands to be processed, and status returned, in a different order than they were received. Multiple outstanding commands to the same lun are accepted as long as they are within the command window (Max Command Sn - Expected Command SN. ) iSCSI allows tagged commands to be reordered by the target for efficiency's sake. One could assume that the initiator is sending them in order, so, again, any reordering that happens at the target device side is legal. I think that your confusion may arise from the idea that the initiator is somehow reordering the commands at its iSCSI layer, which would require some knowledge of the target state prior to sending the commands. This knowledge would create a challenging coupling between initiator and target, but if implemented, would be legal as long as the initiator reordered SCSI CDB's prior to creating the iSCSI PDU, keeping its Command SN's in incrementing order. If one likens this to parallel SCSI, the SCSI commands are sent to the target as the initiator receives them. The target may disconnect if it chooses, and process the remainder of the command in an order decided by the target. iSCSI allows the same; its disconnect is implicit; and target reordering is allowed at the SCSI processing layer. By the Way, TCP ensures ordering on a single connection. In practice, command ordering doesn't really come into play unless one is in a multi-connection scenario. regards, david David J Cuddihy, Principal Engineer ATTO Technology, Inc. http://www.attotech.com/bridge.html dan yo cc: Sent by: Subject: [Ips] iSCSI cmd ordering and tagged ips-admin@ietf task .org 11/19/2003 12:03 AM It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI. For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access. However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target. This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid? Thanks, Dan Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Nov 19 10:00:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19055 for ; Wed, 19 Nov 2003 10:00:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMToT-000787-SL for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 10:00:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJF0DAe027401 for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 10:00:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMToT-00077s-63 for ips-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:00:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18997 for ; Wed, 19 Nov 2003 09:59:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMToR-0000Te-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 10:00:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMToQ-0000Tb-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 10:00:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMToI-00075m-V6; Wed, 19 Nov 2003 10:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTnI-00073S-Se for ips@optimus.ietf.org; Wed, 19 Nov 2003 09:59:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18975 for ; Wed, 19 Nov 2003 09:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTnG-0000T6-00 for ips@ietf.org; Wed, 19 Nov 2003 09:58:58 -0500 Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx with esmtp (Exim 4.12) id 1AMTnF-0000T3-00 for ips@ietf.org; Wed, 19 Nov 2003 09:58:58 -0500 Received: from localhost (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id hAJEwoQu006036; Wed, 19 Nov 2003 09:58:50 -0500 (EST) Subject: Re: [Ips] iSCSI cmd ordering and tagged task From: Ming Zhang Reply-To: mingz@ele.uri.edu To: dcuddihy@attotech.com Cc: dan yo , ips@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: HPCL Message-Id: <1069253929.2605.6.camel@dyn251.ele.uri.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 19 Nov 2003 09:58:49 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-11-19 at 09:50, dcuddihy@attotech.com wrote: > Dan, > > This is not really a limitation since iSCSI allows commands to be > processed, and status returned, in a different order than they were > received. Multiple outstanding commands to the same lun are accepted as > long as they are within the command window (Max Command Sn - Expected > Command SN. ) iSCSI allows tagged commands to be reordered by the target > for efficiency's sake. One could assume that the initiator is sending > them in order, so, again, any reordering that happens at the target device > side is legal. > but it is possible that even the initiator can send multiple outstanding commands via multiple connections on one LUN, the cmd with larger CmdSN has to wait the the cmd with smaller CmdSn to come in queue before it can be processed by target. ming > I think that your confusion may arise from the idea that the initiator is > somehow reordering the commands at its iSCSI layer, which would require > some knowledge of the target state prior to sending the commands. This > knowledge would create a challenging coupling between initiator and target, > but if implemented, would be legal as long as the initiator reordered SCSI > CDB's prior to creating the iSCSI PDU, keeping its Command SN's in > incrementing order. > > If one likens this to parallel SCSI, the SCSI commands are sent to the > target as the initiator receives them. The target may disconnect if it > chooses, and process the remainder of the command in an order decided by > the target. > > iSCSI allows the same; its disconnect is implicit; and target reordering is > allowed at the SCSI processing layer. > > By the Way, TCP ensures ordering on a single connection. In practice, > command ordering doesn't really come into play unless one is in a > multi-connection scenario. > > regards, > > david > > David J Cuddihy, Principal Engineer > ATTO Technology, Inc. > http://www.attotech.com/bridge.html > > > > > dan yo > oo.com> cc: > Sent by: Subject: [Ips] iSCSI cmd ordering and tagged > ips-admin@ietf task > .org > > > 11/19/2003 > 12:03 AM > > > > > > > It seems that the iSCSI requirement of preserving command ordering would > reduce the benefit of the "tagged" tasks feature in SCSI. For instance, if > a host has several I/O tasks to send to the target and that the ordering is > not important, it may want to tag them as "Simple" and let the target > rearrange them in a way that is optimal to disk access. However, when > these tasks arrive out of sequence at the iSCSI target side (different from > the order in which they enter the iSCSI layer at the initiator side), they > will be held up to wait for their predecessor to arrive before they can be > delivered to the SCSI target. This will a bigger issue with the multiple > connections per session scenario in iSCSI where commands from different > connections will get out of order more often than not.&n! bsp; Is my > concern valid? > Thanks, > Dan > > > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > > > > > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips -- --------------------------------------------------- | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ --------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Nov 19 12:10:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27253 for ; Wed, 19 Nov 2003 12:10:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVqG-0008V3-48 for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 12:10:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHABbC032667 for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 12:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVqF-0008Un-AJ for ips-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27234 for ; Wed, 19 Nov 2003 12:09:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVqC-0003Yc-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 12:10:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVqC-0003YZ-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 12:10:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVq7-0008Sz-Nj; Wed, 19 Nov 2003 12:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVpx-0008Ri-Tj for ips@optimus.ietf.org; Wed, 19 Nov 2003 12:09:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27211 for ; Wed, 19 Nov 2003 12:09:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVpw-0003Xc-00 for ips@ietf.org; Wed, 19 Nov 2003 12:09:52 -0500 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1AMVpw-0003Wx-00 for ips@ietf.org; Wed, 19 Nov 2003 12:09:52 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 7E025245EC8; Wed, 19 Nov 2003 12:10:01 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21F3A4C6-1AB3-11D8-A616-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit Cc: nick@pyxtechnologies.com, Andre Hedrick From: Caitlin Bestler Subject: Re: [Ips] [IPS]: Considerations for Asymmetric iSCSI Implementati ons Draft Interest? Date: Wed, 19 Nov 2003 11:09:27 -0600 To: ips@ietf.org X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Nov 17, 2003, at 1:42 PM, Andre Hedrick wrote: > > Pat: > > A simple method of spliting the command and data transports over their > own > respective connections. It is clear the command layer transactions > will > arrive before the following data transactions. > > There are obvious reason to split the layers, yet they generate a new > level of error recovery. > > The principle reason to split the two is based on performance by > allowing > the target to prebuild buffers to optimize memory management and io > scheduling events. > > PyX will present such a model for the next version of the iSCSI RFC. > There are no patents involved, and this conforms to the goals of IETF. > > Regards, > > Andre > > On Mon, 17 Nov 2003 pat_thaler@agilent.com wrote: > Wouldn't either iSER (iSCSI over iWarp) or iSCSI over SCTP provide the same benefits of splitting control and data traffic without the complexities of dealing with failures on a subset of the connections? -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Nov 19 16:14:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12090 for ; Wed, 19 Nov 2003 16:14:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZeL-0000Bf-SC for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 16:14:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJLE9cR000715 for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 16:14:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZeL-0000BS-Ng for ips-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 16:14:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11999 for ; Wed, 19 Nov 2003 16:13:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZeK-0002Gu-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 16:14:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMZeJ-0002Gr-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 16:14:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZeD-00008b-Rc; Wed, 19 Nov 2003 16:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZdb-00007H-9P for ips@optimus.ietf.org; Wed, 19 Nov 2003 16:13:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11907 for ; Wed, 19 Nov 2003 16:13:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZdY-0002Ek-00 for ips@ietf.org; Wed, 19 Nov 2003 16:13:20 -0500 Received: from [66.155.203.134] (helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1AMZdX-0002Dr-00 for ips@ietf.org; Wed, 19 Nov 2003 16:13:19 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hAJLCnpW012310 for ; Wed, 19 Nov 2003 16:12:49 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hAJLCmg6012305; Wed, 19 Nov 2003 16:12:49 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id hAJLCmt22375; Wed, 19 Nov 2003 16:12:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16315.56527.991527.399624@gargle.gargle.HOWL> Date: Wed, 19 Nov 2003 16:12:47 -0500 From: Paul Koning To: dcuddihy@attotech.com Cc: ipsandude@yahoo.com, ips@ietf.org Subject: Re: [Ips] iSCSI cmd ordering and tagged task References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "dcuddihy" == dcuddihy writes: dcuddihy> Dan, dcuddihy> This is not really a limitation since iSCSI allows commands dcuddihy> to be processed, and status returned, in a different order dcuddihy> than they were received. Multiple outstanding commands to dcuddihy> the same lun are accepted as long as they are within the dcuddihy> command window (Max Command Sn - Expected Command SN. ) dcuddihy> iSCSI allows tagged commands to be reordered by the target dcuddihy> for efficiency's sake. One could assume that the initiator dcuddihy> is sending them in order, so, again, any reordering that dcuddihy> happens at the target device side is legal. That's not quite right. SCSI (not iSCSI) can process and complete commands in any order, subject to restrictions imposed by tagging. But the transport (iSCSI) is required to deliver the (non-immediate) commands to SCSI in CmdSn order (see section 3.2.2.1). So if you have multiple connections per session, with different latency on the connections, then the target has to shuffle the commands back into CmdSn order. As soon as it has a complete sequence of commands, it can hand them all to SCSI for action. Given that typical storage latency is substantially larger than LAN latency skew, the delay cost of this enforced order is not all that large. But it is real (and it also shows up in implementation complexity in the iSCSI target layer). paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Nov 19 19:33:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25467 for ; Wed, 19 Nov 2003 19:33:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcl3-0008Lu-RT for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 19:33:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK0XH4c032103 for ips-archive@odin.ietf.org; Wed, 19 Nov 2003 19:33:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcl3-0008Lh-M1 for ips-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 19:33:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25431 for ; Wed, 19 Nov 2003 19:33:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcl1-0007Rz-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 19:33:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMcku-0007Rt-00 for ips-web-archive@ietf.org; Wed, 19 Nov 2003 19:33:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMckn-0008Jt-UI; Wed, 19 Nov 2003 19:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMckV-0008Iw-SX for ips@optimus.ietf.org; Wed, 19 Nov 2003 19:32:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25300 for ; Wed, 19 Nov 2003 19:32:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMckT-0007J1-01 for ips@ietf.org; Wed, 19 Nov 2003 19:32:41 -0500 Received: from web20703.mail.yahoo.com ([216.136.226.176]) by ietf-mx with smtp (Exim 4.12) id 1AMcgF-00076S-00 for ips@ietf.org; Wed, 19 Nov 2003 19:28:19 -0500 Message-ID: <20031120002819.19530.qmail@web20703.mail.yahoo.com> Received: from [66.243.153.70] by web20703.mail.yahoo.com via HTTP; Wed, 19 Nov 2003 16:28:19 PST Date: Wed, 19 Nov 2003 16:28:19 -0800 (PST) From: dan yo Subject: Re: [Ips] iSCSI cmd ordering and tagged task To: Julian_Satran@il.ibm.com, ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-905078847-1069288099=:17892" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , --0-905078847-1069288099=:17892 Content-Type: text/plain; charset=us-ascii I agree, network latency is insignificant in comparision to disk latency. My real concern is the complexity in dealing with session wide variables (cmdSN is one) in a device that supports multiple connections per session. An example is the case where each connection (of a multi-connections session) terminates on different ingress (host facing) port of a gateway (iSCSI to FC, or iSCSI to SATA). As much as possible, I want to route the I/O from each ingress port directly to the egress port (target facing) without any inter-ingress port synchronization or lookup. The SCSI 'Simple' task seem to be an ideal candidate for that, but the cmdSN ordering gets in the way. Thanks, -Dan Julian Satran wrote: I do not think your concern is valid. The skew introduced by multiple connections - when those operate correctly - is minimal. The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering. It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock. Julo dan yo Sent by: ips-admin@ietf.org 19/11/2003 07:03 To ips@ietf.org cc Subject [Ips] iSCSI cmd ordering and tagged task It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI. For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access. However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target. This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid? Thanks, Dan --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-905078847-1069288099=:17892 Content-Type: text/html; charset=us-ascii

I agree, network latency is insignificant in comparision to disk latency.  My real concern is the complexity in dealing with session wide variables (cmdSN is one) in a device that supports multiple connections per session.  An example is the case where each connection (of a multi-connections session) terminates on different ingress (host facing) port of a gateway (iSCSI to FC, or iSCSI to SATA).  As much as possible, I want to route the I/O from each ingress port directly to the egress port (target facing) without any inter-ingress port synchronization or lookup.   The SCSI 'Simple' task seem to be an ideal candidate for that, but the cmdSN ordering gets in the way. 
Thanks,
-Dan  

Julian Satran <Julian_Satran@il.ibm.com> wrote:

I do not think your concern is valid.  The skew introduced by multiple connections - when those operate correctly - is minimal.
The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering.
It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock.

Julo



dan yo <ipsandude@yahoo.com>
Sent by: ips-admin@ietf.org

19/11/2003 07:03

To
ips@ietf.org
cc
Subject
[Ips] iSCSI cmd ordering and tagged task





It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI.  For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access.  However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target.  This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid?
Thanks,
Dan

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-905078847-1069288099=:17892-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 01:12:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05829 for ; Thu, 20 Nov 2003 01:12:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMi2g-0007eW-Eb for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 01:11:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK6BooJ029412 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 01:11:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMi2g-0007eJ-8B for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 01:11:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05826 for ; Thu, 20 Nov 2003 01:11:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMi2e-0004Gw-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 01:11:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMi2e-0004Gs-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 01:11:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMi1u-0007aO-Dm; Thu, 20 Nov 2003 01:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMi1W-0007a0-PU for ips@optimus.ietf.org; Thu, 20 Nov 2003 01:10:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05809 for ; Thu, 20 Nov 2003 01:10:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMi1U-0004Gg-00 for ips@ietf.org; Thu, 20 Nov 2003 01:10:36 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1AMi1T-0004GO-00 for ips@ietf.org; Thu, 20 Nov 2003 01:10:35 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAK6A0Hf095624; Thu, 20 Nov 2003 06:10:00 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAK69xLE180744; Thu, 20 Nov 2003 07:09:59 +0100 In-Reply-To: <20031120002819.19530.qmail@web20703.mail.yahoo.com> To: dan yo Cc: ips@ietf.org Subject: Re: [Ips] iSCSI cmd ordering and tagged task MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Thu, 20 Nov 2003 08:09:57 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 20/11/2003 08:09:59, Serialize complete at 20/11/2003 08:09:59 Content-Type: multipart/alternative; boundary="=_alternative 0021DB66C2256DE4_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0021DB66C2256DE4_= Content-Type: text/plain; charset="US-ASCII" Our assumption was that the SCSI layer will reside outside the port and it can hand-over the CmdSN to the port with the command (and perhaps the SCSI-Tag if that is to be different than the iSCSI tag). I am aware that many hardware adapters for reasons of they own have chose to generate their own CmdSN and break this assumption. Julo dan yo 20/11/2003 02:28 To Julian Satran/Haifa/IBM@IBMIL, ips@ietf.org cc Subject Re: [Ips] iSCSI cmd ordering and tagged task I agree, network latency is insignificant in comparision to disk latency. My real concern is the complexity in dealing with session wide variables (cmdSN is one) in a device that supports multiple connections per session. An example is the case where each connection (of a multi-connections session) terminates on different ingress (host facing) port of a gateway (iSCSI to FC, or iSCSI to SATA). As much as possible, I want to route the I/O from each ingress port directly to the egress port (target facing) without any inter-ingress port synchronization or lookup. The SCSI 'Simple' task seem to be an ideal candidate for that, but the cmdSN ordering gets in the way. Thanks, -Dan Julian Satran wrote: I do not think your concern is valid. The skew introduced by multiple connections - when those operate correctly - is minimal. The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering. It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock. Julo dan yo Sent by: ips-admin@ietf.org 19/11/2003 07:03 To ips@ietf.org cc Subject [Ips] iSCSI cmd ordering and tagged task It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI. For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access. However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target. This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid? Thanks, Dan Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --=_alternative 0021DB66C2256DE4_= Content-Type: text/html; charset="US-ASCII"
Our assumption was that the SCSI layer will reside outside the port and it can hand-over the CmdSN to the port with the command (and perhaps the SCSI-Tag if that is to be different than the iSCSI tag).  I am aware that many hardware adapters for reasons of they own have chose to generate their own CmdSN and break this assumption.

Julo


dan yo <ipsandude@yahoo.com>

20/11/2003 02:28

To
Julian Satran/Haifa/IBM@IBMIL, ips@ietf.org
cc
Subject
Re: [Ips] iSCSI cmd ordering and tagged task





I agree, network latency is insignificant in comparision to disk latency.  My real concern is the complexity in dealing with session wide variables (cmdSN is one) in a device that supports multiple connections per session.  An example is the case where each connection (of a multi-connections session) terminates on different ingress (host facing) port of a gateway (iSCSI to FC, or iSCSI to SATA).  As much as possible, I want to route the I/O from each ingress port directly to the egress port (target facing) without any inter-ingress port synchronization or lookup.   The SCSI 'Simple' task seem to be an ideal candidate for that, but the cmdSN ordering gets in the way.
Thanks,
-Dan  

Julian Satran <Julian_Satran@il.ibm.com> wrote:

I do not think your concern is valid.  The skew introduced by multiple connections - when those operate correctly - is minimal.
The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering.
It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock.

Julo


dan yo <ipsandude@yahoo.com>
Sent by: ips-admin@ietf.org

19/11/2003 07:03


To
ips@ietf.org
cc
Subject
[Ips] iSCSI cmd ordering and tagged task







It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI.  For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access.  However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target.  This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid?
Thanks,
Dan

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

--=_alternative 0021DB66C2256DE4_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 10:06:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07708 for ; Thu, 20 Nov 2003 10:06:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqNq-0000eb-CY for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 10:06:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKF6EbI002507 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 10:06:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqNq-0000eM-8S for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 10:06:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07649 for ; Thu, 20 Nov 2003 10:06:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqNo-0004ND-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 10:06:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMqNn-0004NA-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 10:06:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqNe-0000dA-Dc; Thu, 20 Nov 2003 10:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqN9-0000cO-8D for ips@optimus.ietf.org; Thu, 20 Nov 2003 10:05:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07567 for ; Thu, 20 Nov 2003 10:05:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqN6-0004Mk-00 for ips@ietf.org; Thu, 20 Nov 2003 10:05:28 -0500 Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx with esmtp (Exim 4.12) id 1AMqN5-0004M5-00 for ips@ietf.org; Thu, 20 Nov 2003 10:05:27 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 5BC8AED5C for ; Thu, 20 Nov 2003 09:04:55 -0600 (CST) Received: from cceexc17.americas.cpqcorp.net ([16.81.1.15]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Nov 2003 09:04:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AF77.A3DECAA2" Subject: RE: [Ips] iSCSI cmd ordering and tagged task Date: Thu, 20 Nov 2003 09:04:48 -0600 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6042050FD@cceexc17.americas.cpqcorp.net> Thread-Topic: [Ips] iSCSI cmd ordering and tagged task Thread-Index: AcOu/iIjlv1Dqap+TSi82qX0D3bB6AAeNeWQ From: "Elliott, Robert (Server Storage)" To: X-OriginalArrivalTime: 20 Nov 2003 15:04:48.0775 (UTC) FILETIME=[A43A2970:01C3AF77] Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AF77.A3DECAA2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Although you can view iSCSI's sequence numbers as interfering with an unordered use of SIMPLE task attribute, it has the benefit of making the ORDERED and HEAD OF QUEUE task attributes usable. Although SCSI architecture does not strictly require ordering, all SCSI transport protocols but one (Fibre Channel FCP, class 3, without command reference numbers) do ensure ordered delivery. Although it's not so important for disks, it is very helpful for tapes. =20 --=20 Rob Elliott, elliott@hp.com=20 Hewlett-Packard Industry Standard Server Storage Advanced Technology=20 https://ecardfile.com/id/RobElliott=20 -----Original Message----- From: dan yo [mailto:ipsandude@yahoo.com]=20 Sent: Wednesday, November 19, 2003 6:28 PM To: Julian_Satran@il.ibm.com; ips@ietf.org Subject: Re: [Ips] iSCSI cmd ordering and tagged task =09 =09 I agree, network latency is insignificant in comparision to disk latency. My real concern is the complexity in dealing with session wide variables (cmdSN is one) in a device that supports multiple connections per session. An example is the case where each connection (of a multi-connections session) terminates on different ingress (host facing) port of a gateway (iSCSI to FC, or iSCSI to SATA). As much as possible, I want to route the I/O from each ingress port directly to the egress port (target facing) without any inter-ingress port synchronization or lookup. The SCSI 'Simple' task seem to be an ideal candidate for that, but the cmdSN ordering gets in the way.=20 Thanks, -Dan =20 =09 Julian Satran wrote: I do not think your concern is valid. The skew introduced by multiple connections - when those operate correctly - is minimal.=20 The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering.=20 It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock.=20 =09 Julo=20 =09 =09 =09 =09 dan yo =20 Sent by: ips-admin@ietf.org=20 19/11/2003 07:03=20 To ips@ietf.org=20 cc Subject [Ips] iSCSI cmd ordering and tagged task=09 =09 It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI. For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access. However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target. This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid?=20 Thanks,=20 Dan=20 =09 _____ =20 Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard =20 =09 =09 _____ =20 Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard =20 ------_=_NextPart_001_01C3AF77.A3DECAA2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Although you can view iSCSI's sequence numbers as interfering = with an=20 unordered use of SIMPLE task attribute, it has the benefit of making the = ORDERED=20 and HEAD OF QUEUE task attributes usable.  Although SCSI = architecture does=20 not strictly require ordering, all SCSI transport protocols but one = (Fibre=20 Channel FCP, class 3, without command reference numbers) do ensure = ordered=20 delivery.  Although it's not so important for disks, it is very = helpful for=20 tapes.
 
-- =
Rob Elliott, = elliott@hp.com=20
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20

-----Original Message-----
From: dan = yo=20 [mailto:ipsandude@yahoo.com]
Sent: Wednesday, November 19, = 2003=20 6:28 PM
To: Julian_Satran@il.ibm.com;=20 ips@ietf.org
Subject: Re: [Ips] iSCSI cmd ordering and = tagged=20 task

I agree, network latency is insignificant in = comparision to=20 disk latency.  My real concern is the complexity in = dealing=20 with session wide variables (cmdSN is one) in a device=20 that supports multiple connections per session.  An example=20 is the case where each connection (of a multi-connections=20 session) terminates on different ingress (host facing) = port of a=20 gateway (iSCSI to FC, or iSCSI to SATA).  As much as = possible, I=20 want to route the I/O from each ingress port = directly to=20 the egress port (target facing) without any = inter-ingress port=20 synchronization or lookup.   The = SCSI 'Simple' task=20 seem to be an ideal candidate for that, but the cmdSN=20 ordering gets in the way. 
Thanks,
-Dan  

Julian Satran=20 <Julian_Satran@il.ibm.com> wrote:

I do not think your concern is valid. =  The skew=20 introduced by multiple connections - when those operate correctly - = is=20 minimal.
The iSCSI = ordering=20 requirement serves mainly to detect missing commands due to digest = errors=20 (not caught by TCP) and not to impose a SCSI ordering. =
It helps also avoiding having the = initiator overrun=20 the target beyond with more than the later can digest without using = slow=20 interlock.

Julo=20



dan yo=20 <ipsandude@yahoo.com>
Sent by: ips-admin@ietf.org=20

19/11/2003 07:03 =

To
ips@ietf.org=20
cc
Subject
[Ips] = iSCSI cmd=20 ordering and tagged = task

=




<= FONT=20 size=3D3>It seems that the iSCSI requirement of preserving command = ordering=20 would reduce the benefit of the "tagged" tasks feature in SCSI. =  For=20 instance, if a host has several I/O tasks to send to the target and = that the=20 ordering is not important, it may want to tag them as "Simple" and = let the=20 target rearrange them in a way that is optimal to disk access.=20  However, when these tasks arrive out of sequence at the iSCSI = target=20 side (different from the order in which they enter the iSCSI layer = at the=20 initiator side), they will be held up to wait for their predecessor = to=20 arrive before they can be delivered to the SCSI target.  This = will a=20 bigger issue with the multiple connections per session scenario in = iSCSI=20 where commands from different connections will get out of order more = often=20 than not.&n! bsp; Is my concern valid?
Thanks,
Dan=20

Do you Yahoo!?
Protect your identity with Yahoo! Mail = AddressGuard=20

Do you Yahoo!?
Protect=20 your identity with Yahoo! Mail=20 AddressGuard =00 ------_=_NextPart_001_01C3AF77.A3DECAA2-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 12:21:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14152 for ; Thu, 20 Nov 2003 12:21:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsUb-0001l8-32 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 12:21:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHLLLO006758 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 12:21:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsUa-0001kv-UN for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 12:21:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14114 for ; Thu, 20 Nov 2003 12:21:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsUZ-0006Wn-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 12:21:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMsUZ-0006Wk-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 12:21:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsUI-0001gv-M2; Thu, 20 Nov 2003 12:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsU3-0001gM-0s for ips@optimus.ietf.org; Thu, 20 Nov 2003 12:20:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14093 for ; Thu, 20 Nov 2003 12:20:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsU1-0006WI-00 for ips@ietf.org; Thu, 20 Nov 2003 12:20:45 -0500 Received: from web20713.mail.yahoo.com ([66.163.169.154]) by ietf-mx with smtp (Exim 4.12) id 1AMsTz-0006Vx-00 for ips@ietf.org; Thu, 20 Nov 2003 12:20:44 -0500 Message-ID: <20031120172026.99685.qmail@web20713.mail.yahoo.com> Received: from [66.243.153.70] by web20713.mail.yahoo.com via HTTP; Thu, 20 Nov 2003 09:20:26 PST Date: Thu, 20 Nov 2003 09:20:26 -0800 (PST) From: dan yo Subject: RE: [Ips] iSCSI cmd ordering and tagged task To: ips@ietf.org In-Reply-To: <78AF3C342AEAEF4BA33B35A8A15668C6042050FD@cceexc17.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1746599045-1069348826=:97970" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , --0-1746599045-1069348826=:97970 Content-Type: text/plain; charset=us-ascii Pardon me for thinking out loud. Then does it make sense for the iSCSI initiator to turn on the "Immediate bit" for SIMPLE tasks? I haven't thought through the side effect, but this seems to accomplish what I want, i.e. to allow each connection of a multiple connection session operate independently (no need to do cmdSN synchronization with other connections) and therefore easier to implement cut through switching in an iSCSI to FC gateway. Thanks, -Dan "Elliott, Robert (Server Storage)" wrote: Although you can view iSCSI's sequence numbers as interfering with an unordered use of SIMPLE task attribute, it has the benefit of making the ORDERED and HEAD OF QUEUE task attributes usable. Although SCSI architecture does not strictly require ordering, all SCSI transport protocols but one (Fibre Channel FCP, class 3, without command reference numbers) do ensure ordered delivery. Although it's not so important for disks, it is very helpful for tapes. -- Rob Elliott, elliott@hp.com Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott -----Original Message----- From: dan yo [mailto:ipsandude@yahoo.com] Sent: Wednesday, November 19, 2003 6:28 PM To: Julian_Satran@il.ibm.com; ips@ietf.org Subject: Re: [Ips] iSCSI cmd ordering and tagged task I agree, network latency is insignificant in comparision to disk latency. My real concern is the complexity in dealing with session wide variables (cmdSN is one) in a device that supports multiple connections per session. An example is the case where each connection (of a multi-connections session) terminates on different ingress (host facing) port of a gateway (iSCSI to FC, or iSCSI to SATA). As much as possible, I want to route the I/O from each ingress port directly to the egress port (target facing) without any inter-ingress port synchronization or lookup. The SCSI 'Simple' task seem to be an ideal candidate for that, but the cmdSN ordering gets in the way. Thanks, -Dan Julian Satran wrote: I do not think your concern is valid. The skew introduced by multiple connections - when those operate correctly - is minimal. The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering. It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock. Julo dan yo Sent by: ips-admin@ietf.org 19/11/2003 07:03 To ips@ietf.org cc Subject [Ips] iSCSI cmd ordering and tagged task It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI. For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access. However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target. This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid? Thanks, Dan --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now --0-1746599045-1069348826=:97970 Content-Type: text/html; charset=us-ascii
Pardon me for thinking out loud.  Then does it make sense for the iSCSI initiator to turn on the "Immediate bit" for SIMPLE tasks?  I haven't thought through the side effect, but this seems to accomplish what I want, i.e. to allow each connection of a multiple connection session operate independently (no need to do cmdSN synchronization with other connections) and therefore easier to implement cut through switching in an iSCSI to FC gateway.
Thanks,
-Dan  

"Elliott, Robert (Server Storage)" <elliott@hp.com> wrote:
Although you can view iSCSI's sequence numbers as interfering with an unordered use of SIMPLE task attribute, it has the benefit of making the ORDERED and HEAD OF QUEUE task attributes usable.  Although SCSI architecture does not strictly require ordering, all SCSI transport protocols but one (Fibre Channel FCP, class 3, without command reference numbers) do ensure ordered delivery.  Although it's not so important for disks, it is very helpful for tapes.
 
--
Rob Elliott, elliott@hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott

-----Original Message-----
From: dan yo [mailto:ipsandude@yahoo.com]
Sent: Wednesday, November 19, 2003 6:28 PM
To: Julian_Satran@il.ibm.com; ips@ietf.org
Subject: Re: [Ips] iSCSI cmd ordering and tagged task

I agree, network latency is insignificant in comparision to disk latency.  My real concern is the complexity in dealing with session wide variables (cmdSN is one) in a device that supports multiple connections per session.  An example is the case where each connection (of a multi-connections session) terminates on different ingress (host facing) port of a gateway (iSCSI to FC, or iSCSI to SATA).  As much as possible, I want to route the I/O from each ingress port directly to the egress port (target facing) without any inter-ingress port synchronization or lookup.   The SCSI 'Simple' task seem to be an ideal candidate for that, but the cmdSN ordering gets in the way. 
Thanks,
-Dan  

Julian Satran <Julian_Satran@il.ibm.com> wrote:

I do not think your concern is valid.  The skew introduced by multiple connections - when those operate correctly - is minimal.
The iSCSI ordering requirement serves mainly to detect missing commands due to digest errors (not caught by TCP) and not to impose a SCSI ordering.
It helps also avoiding having the initiator overrun the target beyond with more than the later can digest without using slow interlock.

Julo



dan yo <ipsandude@yahoo.com>
Sent by: ips-admin@ietf.org

19/11/2003 07:03

To
ips@ietf.org
cc
Subject
[Ips] iSCSI cmd ordering and tagged task





It seems that the iSCSI requirement of preserving command ordering would reduce the benefit of the "tagged" tasks feature in SCSI.  For instance, if a host has several I/O tasks to send to the target and that the ordering is not important, it may want to tag them as "Simple" and let the target rearrange them in a way that is optimal to disk access.  However, when these tasks arrive out of sequence at the iSCSI target side (different from the order in which they enter the iSCSI layer at the initiator side), they will be held up to wait for their predecessor to arrive before they can be delivered to the SCSI target.  This will a bigger issue with the multiple connections per session scenario in iSCSI where commands from different connections will get out of order more often than not.&n! bsp; Is my concern valid?
Thanks,
Dan

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Free Pop-Up Blocker - Get it now --0-1746599045-1069348826=:97970-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 14:08:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19045 for ; Thu, 20 Nov 2003 14:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu9z-00020Y-Pd for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 14:08:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJ8BOo007711 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 14:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu9z-00020I-Di for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:08:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18999 for ; Thu, 20 Nov 2003 14:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMu9x-0000Xa-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 14:08:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMu9w-0000XX-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 14:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu9r-0001wM-0G; Thu, 20 Nov 2003 14:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu9V-0001q5-UF for ips@optimus.ietf.org; Thu, 20 Nov 2003 14:07:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18976 for ; Thu, 20 Nov 2003 14:07:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMu9T-0000Wm-00 for ips@ietf.org; Thu, 20 Nov 2003 14:07:39 -0500 Received: from adsl-63-206-196-185.dsl.snfc21.pacbell.net ([63.206.196.185] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1AMu9S-0000WG-00 for ips@ietf.org; Thu, 20 Nov 2003 14:07:38 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1AMtzM-0007If-00; Thu, 20 Nov 2003 10:57:12 -0800 Subject: RE: [Ips] iSCSI cmd ordering and tagged task From: "Nicholas A. Bellinger" To: dan yo Cc: ips@ietf.org In-Reply-To: <20031120172026.99685.qmail@web20713.mail.yahoo.com> References: <20031120172026.99685.qmail@web20713.mail.yahoo.com> Content-Type: text/plain Message-Id: <1069354631.25197.33.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 20 Nov 2003 10:57:11 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan, Session wide ordering is a requirement for even single connection ErrorRecoveryLevel=0 implementations. Please see section 3.2.2.1 for the MUST requirement. Not supporting CmdSN/ExpCmdSN/MaxCmdSN ordering requirements is a definate violation of the iSCSI specification in a simple ErrorRecoveryLevel=0 implementation, let alone a multiple connection ErrorRecoveryLevel=1 and above implementation. One of the key goals of RFC 3347 and the iSCSI draft is to allow iSCSI vendors to create interoptable high speed implemenations. Leaving out basic parts of the specification to avoid doing the necessary work to make the implementation is question interoptable with industry standard implemenations is a bad position to put ones self into. Frankly, I will continue to advicate the point that only ErrorRecoveryLevel=1 and above implementations will be allowed use multiple connection sessions. Any iSCSI target supporting multiple connection sessions in a ErrorRecoveryLevel=0 implemenation is broken IMHO and does so to support broken iSCSI ErrorRecoveryLevel=0 initiator implemenations and vendors who believe they can get away with only doing parts of ErrorRecoveryLevel=1 without doing a complete ErrorRecoveryLevel=1 implementation. Negoitating the ErrorRecoveryLevel=1 key during the leading connection of a full feature phase iSCSI login means the supporting the nine (9) requirements of within-command and within-connection recovery from sections 6.1.4.1 and 6.1.4.2, negoitating the ErrorRecoveryLevel=1 key without implementing these features is a clear violation of the specification. In order to support the nine (9) requirements of ErrorRecoveryLevel=1 means supporting Fixed Interval Markers or some other framing mechnisim to recover from header digest failures where the offset to the next iSCSI Opcode cannot be reliably determined. (See section 6.1.4.1, Initiator and Target case C, and section 3.2.8) Also in the within-command recovery cases from section 6.1.4.1, DataPDUInOrder=No and DataSequenceInOrder=No cases must also be considered. Thanks! -- Nicholas A. Bellinger On Thu, 2003-11-20 at 09:20, dan yo wrote: > Pardon me for thinking out loud. Then does it make sense for the > iSCSI initiator to turn on the "Immediate bit" for SIMPLE tasks? I > haven't thought through the side effect, but this seems to accomplish > what I want, i.e. to allow each connection of a multiple connection > session operate independently (no need to do cmdSN synchronization > with other connections) and therefore easier to implement cut > through switching in an iSCSI to FC gateway. > Thanks, > -Dan > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 15:09:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22259 for ; Thu, 20 Nov 2003 15:09:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMv70-0006RZ-2B for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 15:09:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKK9Ava024763 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 15:09:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMv6z-0006RK-UT for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 15:09:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22201 for ; Thu, 20 Nov 2003 15:08:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMv6w-0001Wp-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 15:09:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMv6w-0001Wm-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 15:09:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMv6r-0006QC-TN; Thu, 20 Nov 2003 15:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMv6Y-0006PM-Kl for ips@optimus.ietf.org; Thu, 20 Nov 2003 15:08:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22136 for ; Thu, 20 Nov 2003 15:08:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMv6V-0001Vz-00 for ips@ietf.org; Thu, 20 Nov 2003 15:08:39 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1AMv6V-0001Vw-00 for ips@ietf.org; Thu, 20 Nov 2003 15:08:39 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel9.hp.com (Postfix) with ESMTP id 04D1A1C02BF0 for ; Thu, 20 Nov 2003 15:08:39 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bec059.rose.hp.com [15.23.142.59]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id MAA04796 for ; Thu, 20 Nov 2003 12:08:38 -0800 (PST) Message-ID: <3FBD1F41.1080309@rose.hp.com> Date: Thu, 20 Nov 2003 12:08:33 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] iSCSI cmd ordering and tagged task References: <78AF3C342AEAEF4BA33B35A8A15668C6042050FD@cceexc17.americas.cpqcorp.net> In-Reply-To: <78AF3C342AEAEF4BA33B35A8A15668C6042050FD@cceexc17.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In addition to Julian's and Rob's responses, which are right on, let me add one other note. This is a concern periodically expressed - that a multi-connection sesion has this serious problem of the network skew across multiple connections that slows down command reordering at the target. The response to that is - one does not have to use a multi-connection session unless one wanted *one* I_T nexus across all of them with all the implicit/expclicit expectations that go with it (that Rob refers to below), including ordered delivery. A perfectly reasonable alternative for some configurations may be to use multiple I_T nexuses between the two network entities - each on a different TCP connection. One could then argue that command ordering is a problem, period - even for single connection sessions. I think Julian already answered that - CmdSN is is also an error detection mechanism that ensures that all iSCSI sessions meet another expectation of an I_T nexus - that of reliable delivery. Finally, CmdSN is also a flow control mechanism that is required for the benefit of targets regardless of the number of connections. You can attempt to bypass the CmdSN "constraints" by immediate commands, but then you also bypass all these benefits for which it was designed. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Elliott, Robert (Server Storage) wrote: > Although you can view iSCSI's sequence numbers as interfering with an > unordered use of SIMPLE task attribute, it has the benefit of making the > ORDERED and HEAD OF QUEUE task attributes usable. Although SCSI > architecture does not strictly require ordering, all SCSI transport > protocols but one (Fibre Channel FCP, class 3, without command reference > numbers) do ensure ordered delivery. Although it's not so important for > disks, it is very helpful for tapes. > > -- > Rob Elliott, elliott@hp.com > Hewlett-Packard Industry Standard Server Storage Advanced Technology > https://ecardfile.com/id/RobElliott > > -----Original Message----- > From: dan yo [mailto:ipsandude@yahoo.com] > Sent: Wednesday, November 19, 2003 6:28 PM > To: Julian_Satran@il.ibm.com; ips@ietf.org > Subject: Re: [Ips] iSCSI cmd ordering and tagged task > > I agree, network latency is insignificant in comparision to disk > latency. My real concern is the complexity in dealing with session > wide variables (cmdSN is one) in a device that supports multiple > connections per session. An example is the case where each > connection (of a multi-connections session) terminates on different > ingress (host facing) port of a gateway (iSCSI to FC, or iSCSI to > SATA). As much as possible, I want to route > the I/O from each ingress port directly to the egress port (target > facing) without any inter-ingress port synchronization or > lookup. The SCSI 'Simple' task seem to be an ideal candidate for > that, but the cmdSN ordering gets in the way. > Thanks, > -Dan > > Julian Satran wrote: > > > I do not think your concern is valid. The skew introduced by > multiple connections - when those operate correctly - is minimal. > The iSCSI ordering requirement serves mainly to detect missing > commands due to digest errors (not caught by TCP) and not to > impose a SCSI ordering. > It helps also avoiding having the initiator overrun the target > beyond with more than the later can digest without using slow > interlock. > > Julo > > > > dan yo > Sent by: ips-admin@ietf.org > > 19/11/2003 07:03 > > > To > ips@ietf.org > cc > > Subject > [Ips] iSCSI cmd ordering and tagged task > > > > > > > > > It seems that the iSCSI requirement of preserving command > ordering would reduce the benefit of the "tagged" tasks feature > in SCSI. For instance, if a host has several I/O tasks to send > to the target and that the ordering is not important, it may > want to tag them as "Simple" and let the target rearrange them > in a way that is optimal to disk access. However, when these > tasks arrive out of sequence at the iSCSI target side (different > from the order in which they enter the iSCSI layer at the > initiator side), they will be held up to wait for their > predecessor to arrive before they can be delivered to the SCSI > target. This will a bigger issue with the multiple connections > per session scenario in iSCSI where commands from different > connections will get out of order more often than not.&n! bsp; > Is my concern valid? > Thanks, > Dan > > ------------------------------------------------------------------------ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 16:31:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29124 for ; Thu, 20 Nov 2003 16:31:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwNs-0005Ud-VG for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 16:30:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLUelp021114 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 16:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwNs-0005UT-Oo for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29079 for ; Thu, 20 Nov 2003 16:30:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwNq-0003kT-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 16:30:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMwNq-0003kQ-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 16:30:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwNG-0005PE-L6; Thu, 20 Nov 2003 16:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwML-0005NJ-BY for ips@optimus.ietf.org; Thu, 20 Nov 2003 16:29:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28796 for ; Thu, 20 Nov 2003 16:28:51 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwMJ-0003ej-00 for ips@ietf.org; Thu, 20 Nov 2003 16:29:03 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AMwMI-0003eU-00 for ips@ietf.org; Thu, 20 Nov 2003 16:29:02 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 2EF3340139; Thu, 20 Nov 2003 16:28:59 -0500 (EST) Date: Thu, 20 Nov 2003 13:25:32 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Paul von Behren Cc: dan yo , ips@ietf.org Subject: Re: [Ips] [Ips]target online notification In-Reply-To: <3FB5320A.4070407@sun.com> Message-ID: References: <20031114193852.83806.qmail@web20712.mail.yahoo.com> <3FB5320A.4070407@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , On Fri, 14 Nov 2003, Paul von Behren wrote: > There's a related question for LUN configuration changes - suppose > the target is a RAID array and someone creates a LUN, or changes > it's visibility with LUN masking. Is there some mechanism the > array can use to tell the host drivers to look for changes > in the LUN configuration. In FCP, this is often done with > a LIP or RSCN. Does iSCSI allow a target to send an SCN to > initiators? I'm not that familiar with FCP, but isn't there a SCSI way to notice this? iSCSI can transmit asynchronous UAs back to the initiator, so any initiator logged into the target can (if there's an appropriate UA) find out about the LUN change. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 16:45:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00260 for ; Thu, 20 Nov 2003 16:45:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwbq-0006ql-8L for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 16:45:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLj6AC026322 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 16:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwbp-0006qP-M6 for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:45:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00203 for ; Thu, 20 Nov 2003 16:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwbn-00049c-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 16:45:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMwbn-00049Z-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 16:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwbm-0006oN-RA; Thu, 20 Nov 2003 16:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwau-0006n4-Mi for ips@optimus.ietf.org; Thu, 20 Nov 2003 16:44:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00171 for ; Thu, 20 Nov 2003 16:43:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwas-00048X-00 for ips@ietf.org; Thu, 20 Nov 2003 16:44:06 -0500 Received: from adsl-63-206-196-185.dsl.snfc21.pacbell.net ([63.206.196.185] helo=subjekt.volcom.net) by ietf-mx with esmtp (Exim 4.12) id 1AMwar-00047N-00 for ips@ietf.org; Thu, 20 Nov 2003 16:44:05 -0500 Received: from localhost ([127.0.0.1]) by subjekt.volcom.net with esmtp (Exim 3.36 #1 (Debian)) id 1AMwKg-0007Ke-00; Thu, 20 Nov 2003 13:27:22 -0800 Subject: Re: [Ips] iSCSI cmd ordering and tagged task From: "Nicholas A. Bellinger" To: "Mallikarjun C." Cc: ips@ietf.org In-Reply-To: <3FBD24A5.5080204@rose.hp.com> References: <20031120172026.99685.qmail@web20713.mail.yahoo.com> <1069354631.25197.33.camel@subjekt.volcom.net> <3FBD24A5.5080204@rose.hp.com> Content-Type: text/plain Message-Id: <1069363640.25196.94.camel@subjekt.volcom.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 20 Nov 2003 13:27:20 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mallikarjun, I have come to the conclusion based upon the following examples: 0) The handling of out of order StatSNs and their eventual delayed execution on the Initiator are strictly a within-connection recovery feature. Why is one out of order execution mechinism defined as ErrorRecoveryLevel=1 while another is allowed for ErrorRecoveryLevel=0? It could be argued that since CmdSNs are expected to reguarly be out of order as they arrive, as compared to an out of order StatSN is usually attributed to a header or data digest failure in with a response pdu or datain pdu carrying a status bit. Nevertheless it is an asymmetry. :-) 1) The CmdSN timer on the Initiator that checks what CmdSNs have been acknowledged and possibly issue retries of non-immediate commands is listed as a within-connection recovery feature in section 6.1.4.2. Granted it could be argued that this is a implementation issue, but really any implemenation will have something along these lines (a CmdSN timer to either retry the CmdSN in ERL>=1 or fail the session in ERL=0) to determine when a non-immediate CmdSN has been lost for various reasons. Aside from pointing what I see as minor inconsistencies, I fear that it becomes very easy for vendors to choose what multiple connection funtionality not to implement at ErrorRecoveryLevel=0 and leave a window open for serious interoptabilty issues. From the point of view of someone who as brought Initiator, Target and Repeater stacks to ErrorRecoveryLevel=2 in parallel, it became very obvious that ErrorRecoveryLevel=1 was designed to make implementations as through as possible and force vendors to seriously take into consideration all the needed extra funtionality that comes with multiple connection sessions. One issue that immediatly comes to mind is the logging out of additional connections on the fly with a logout request with either the same or differing CID than the connection it arrived on. It is pure speculation as to if vendors who ultimately decide to take the multiple connection per session at ErrorRecoveryLevel=0 route will implement any of this functionality. IMHO, from the various inquries on the reflector regarding multiple connections per session and ErrorRecoveryLevel=0, I seriously doubt to see any of this additional required functionality being implemented. Thanks! -- Nicholas A. Bellinger On Thu, 2003-11-20 at 12:31, Mallikarjun C. wrote: > Nick, > > > Frankly, I will continue to advicate the point that only > > ErrorRecoveryLevel=1 and above implementations will be allowed use > > multiple connection sessions. Any iSCSI target supporting multiple > > connection sessions in a ErrorRecoveryLevel=0 implemenation is broken > > Why? > > The iSCSI semantics wrt multi-connection sessions are > always true (really relevant based on the operational value > of the MaxConnections key), not tied to the operational > ErrorRecoveryLevel key. > > M > > > Nicholas A. Bellinger wrote: > > > Dan, > > > > Session wide ordering is a requirement for even single connection > > ErrorRecoveryLevel=0 implementations. Please see section 3.2.2.1 for > > the MUST requirement. Not supporting CmdSN/ExpCmdSN/MaxCmdSN ordering > > requirements is a definate violation of the iSCSI specification in a > > simple ErrorRecoveryLevel=0 implementation, let alone a multiple > > connection ErrorRecoveryLevel=1 and above implementation. > > > > One of the key goals of RFC 3347 and the iSCSI draft is to allow iSCSI > > vendors to create interoptable high speed implemenations. Leaving out > > basic parts of the specification to avoid doing the necessary work to > > make the implementation is question interoptable with industry standard > > implemenations is a bad position to put ones self into. > > > > Frankly, I will continue to advicate the point that only > > ErrorRecoveryLevel=1 and above implementations will be allowed use > > multiple connection sessions. Any iSCSI target supporting multiple > > connection sessions in a ErrorRecoveryLevel=0 implemenation is broken > > IMHO and does so to support broken iSCSI ErrorRecoveryLevel=0 initiator > > implemenations and vendors who believe they can get away with only doing > > parts of ErrorRecoveryLevel=1 without doing a complete > > ErrorRecoveryLevel=1 implementation. > > > > Negoitating the ErrorRecoveryLevel=1 key during the leading connection > > of a full feature phase iSCSI login means the supporting the nine (9) > > requirements of within-command and within-connection recovery from > > sections 6.1.4.1 and 6.1.4.2, negoitating the ErrorRecoveryLevel=1 key > > without implementing these features is a clear violation of the > > specification. > > > > In order to support the nine (9) requirements of ErrorRecoveryLevel=1 > > means supporting Fixed Interval Markers or some other framing mechnisim > > to recover from header digest failures where the offset to the next > > iSCSI Opcode cannot be reliably determined. (See section 6.1.4.1, > > Initiator and Target case C, and section 3.2.8) Also in the > > within-command recovery cases from section 6.1.4.1, DataPDUInOrder=No > > and DataSequenceInOrder=No cases must also be considered. > > > > Thanks! > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 16:56:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01187 for ; Thu, 20 Nov 2003 16:56:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwme-00080c-HX for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 16:56:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLuG5N030780 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 16:56:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwme-00080N-CK for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:56:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01092 for ; Thu, 20 Nov 2003 16:56:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwmb-0004T2-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 16:56:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMwma-0004SP-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 16:56:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwmP-0007we-6H; Thu, 20 Nov 2003 16:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwlY-0007tq-QY for ips@optimus.ietf.org; Thu, 20 Nov 2003 16:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00829 for ; Thu, 20 Nov 2003 16:54:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwlT-0004Oh-00 for ips@ietf.org; Thu, 20 Nov 2003 16:55:03 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AMwlT-0004Mx-00 for ips@ietf.org; Thu, 20 Nov 2003 16:55:03 -0500 Received: from phys-giza-1 ([129.147.4.102]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAKLsXxA029635 for ; Thu, 20 Nov 2003 13:54:33 -0800 (PST) Received: from sun.com (dhcp-ubrm05-50-163.Central.Sun.COM [129.147.50.163]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HOO00AWW7IW5M@giza-mail1.Central.Sun.COM> for ips@ietf.org; Thu, 20 Nov 2003 14:54:32 -0700 (MST) Date: Thu, 20 Nov 2003 14:55:03 -0700 From: Paul von Behren Subject: Re: [Ips] [Ips]target online notification In-reply-to: To: wrstuden@wasabisystems.com Cc: dan yo , ips@ietf.org Message-id: <3FBD3837.9000700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 References: <20031114193852.83806.qmail@web20712.mail.yahoo.com> <3FB5320A.4070407@sun.com> Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit wrstuden@wasabisystems.com wrote: > On Fri, 14 Nov 2003, Paul von Behren wrote: > > >>There's a related question for LUN configuration changes - suppose >>the target is a RAID array and someone creates a LUN, or changes >>it's visibility with LUN masking. Is there some mechanism the >>array can use to tell the host drivers to look for changes >>in the LUN configuration. In FCP, this is often done with >>a LIP or RSCN. Does iSCSI allow a target to send an SCN to >>initiators? > > > I'm not that familiar with FCP, but isn't there a SCSI way to notice this? As far as I know, SCSI standards have no mechanism for a target to send a message asynchronously. There have been many proposals, but nothing is currently provided in the T10 specification. There certainly is nothing in common use. > iSCSI can transmit asynchronous UAs back to the initiator, so any > initiator logged into the target can (if there's an appropriate UA) find > out about the LUN change. UAs are a response to an initiator request and are only possible if the initiator is actively sending SCSI requests. If the initiator is idle, then there is no message. And UAs won't help at all to tell an initiator when administrative actions have made the first logical unit available to that initiator (if the initiator thinks there are no units on a target, it won't be issuing any I/Os to get the UA). This forces a "poll the universe" policy which does not scale up. Hence the FC approach of using a transport-specific interface (LIP for loop and RSCN for fabric topologies). I agree that a SCSI/T10 solution makes more sense. But since FC was unable to get this solution, I think it's unlikely that iSCSI will. I would rather have an iSCSI-specific solution available rather than none. Paul > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 17:44:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04314 for ; Thu, 20 Nov 2003 17:44:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxXS-0002mZ-Uo for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 17:44:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKMicOm010689 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 17:44:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxXS-0002mK-On for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 17:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04234 for ; Thu, 20 Nov 2003 17:44:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxXQ-0005id-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 17:44:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMxXP-0005i6-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 17:44:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxWr-0002gT-Lu; Thu, 20 Nov 2003 17:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxW9-0002fD-2l for ips@optimus.ietf.org; Thu, 20 Nov 2003 17:43:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04084 for ; Thu, 20 Nov 2003 17:43:02 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxW6-0005fj-00 for ips@ietf.org; Thu, 20 Nov 2003 17:43:14 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AMxW5-0005fg-00 for ips@ietf.org; Thu, 20 Nov 2003 17:43:13 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 3238440139; Thu, 20 Nov 2003 17:43:14 -0500 (EST) Date: Thu, 20 Nov 2003 14:39:47 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Paul von Behren Cc: dan yo , ips@ietf.org Subject: Re: [Ips] [Ips]target online notification In-Reply-To: <3FBD3837.9000700@sun.com> Message-ID: References: <20031114193852.83806.qmail@web20712.mail.yahoo.com> <3FB5320A.4070407@sun.com> <3FBD3837.9000700@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , On Thu, 20 Nov 2003, Paul von Behren wrote: > wrstuden@wasabisystems.com wrote: > > I'm not that familiar with FCP, but isn't there a SCSI way to notice this? > > As far as I know, SCSI standards have no mechanism for a target to > send a message asynchronously. There have been many proposals, > but nothing is currently provided in the T10 specification. There > certainly is nothing in common use. iSCSI can. Please see the Asynchronous Message PDU, in section 10.9 of the iSCSI RFC. From the RFC: The codes used for iSCSI Asynchronous Messages (events) are: 0 - a SCSI Asynchronous Event is reported in the sense data. Sense Data that accompanies the report, in the data segment, identifies the condition. The sending of a SCSI Event (Asynchronous Event Reporting in SCSI terminology) is dependent on the target support for SCSI asynchronous event reporting (see [SAM2]) as indicated in the standard INQUIRY data (see [SPC3]). Its use may be enabled SCSI Control mode page (see [SPC3]). > > iSCSI can transmit asynchronous UAs back to the initiator, so any > > initiator logged into the target can (if there's an appropriate UA) find > > out about the LUN change. > > UAs are a response to an initiator request and are only possible > if the initiator is actively sending SCSI requests. If the > initiator is idle, then there is no message. And UAs won't help > at all to tell an initiator when administrative actions have made > the first logical unit available to that initiator (if the initiator > thinks there are no units on a target, it won't be issuing any I/Os > to get the UA). This forces a "poll the universe" policy which does > not scale up. Hence the FC approach of using a transport-specific > interface (LIP for loop and RSCN for fabric topologies). > > I agree that a SCSI/T10 solution makes more sense. But since > FC was unable to get this solution, I think it's unlikely that > iSCSI will. I would rather have an iSCSI-specific solution > available rather than none. See above. SAM-2 and SAM-3 agree that the fix needs to be there, and have added it. :-) From looking at SAM-3, section 5.9.7 "Unit Attention condition", there is a list of UA-generating events. One of them, "g)", is "The logical unit inventory has been changed." Thus I think that a UA for inventory changes is the way to go. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 18:04:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05388 for ; Thu, 20 Nov 2003 18:04:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxqE-0003iM-OP for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 18:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKN42Wh014272 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 18:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxqE-0003i7-JU for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 18:04:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05301 for ; Thu, 20 Nov 2003 18:03:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxqB-0006A6-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 18:03:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMxqB-0006A3-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 18:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxqD-0003h9-2F; Thu, 20 Nov 2003 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxq0-0003gn-Nb for ips@optimus.ietf.org; Thu, 20 Nov 2003 18:03:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05240 for ; Thu, 20 Nov 2003 18:03:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxpw-00069F-00 for ips@ietf.org; Thu, 20 Nov 2003 18:03:44 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AMxpv-00067i-00 for ips@ietf.org; Thu, 20 Nov 2003 18:03:43 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel12.hp.com (Postfix) with ESMTP id 8D99D1C012B5 for ; Thu, 20 Nov 2003 15:03:15 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bec059.rose.hp.com [15.23.142.59]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id PAA13150 for ; Thu, 20 Nov 2003 15:03:13 -0800 (PST) Message-ID: <3FBD482C.9060509@rose.hp.com> Date: Thu, 20 Nov 2003 15:03:08 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] iSCSI cmd ordering and tagged task References: <20031120172026.99685.qmail@web20713.mail.yahoo.com> <1069354631.25197.33.camel@subjekt.volcom.net> <3FBD24A5.5080204@rose.hp.com> <1069363640.25196.94.camel@subjekt.volcom.net> In-Reply-To: <1069363640.25196.94.camel@subjekt.volcom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Let me attempt to clarify this if I can. ErrorRecoveryLevel key as the name implies exclusively deals with error management. An OOO command arrival to the extent it happens due to network skew is *not* an error and so its handling is not governed by the ErrorRecoveryLevel key. All the semantics defined in the spec for multi-connection sessions have to be followed regardless of ErrorRecoveryLevel (i.e. even at = 0). If an implementation supports MaxConnections > 1 but not support related iSCSI spec semantics, then it isn't compliant to the spec. Regarding the extent of support for Logout flavors, I cannot speak for specific implementations, but let me note that except for recovery logout which is dependent on ErrorRecoveryLevel=2 support, all other semantics are mandatory to support. M Nicholas A. Bellinger wrote: > Mallikarjun, > > I have come to the conclusion based upon the following examples: > > 0) The handling of out of order StatSNs and their eventual delayed > execution on the Initiator are strictly a within-connection recovery > feature. Why is one out of order execution mechinism defined as > ErrorRecoveryLevel=1 while another is allowed for ErrorRecoveryLevel=0? > It could be argued that since CmdSNs are expected to reguarly be out of > order as they arrive, as compared to an out of order StatSN is usually > attributed to a header or data digest failure in with a response pdu or > datain pdu carrying a status bit. Nevertheless it is an asymmetry. :-) > > 1) The CmdSN timer on the Initiator that checks what CmdSNs have been > acknowledged and possibly issue retries of non-immediate commands is > listed as a within-connection recovery feature in section 6.1.4.2. > Granted it could be argued that this is a implementation issue, but > really any implemenation will have something along these lines (a CmdSN > timer to either retry the CmdSN in ERL>=1 or fail the session in ERL=0) > to determine when a non-immediate CmdSN has been lost for various > reasons. > > > Aside from pointing what I see as minor inconsistencies, I fear that it > becomes very easy for vendors to choose what multiple connection > funtionality not to implement at ErrorRecoveryLevel=0 and leave a window > open for serious interoptabilty issues. From the point of view of > someone who as brought Initiator, Target and Repeater stacks to > ErrorRecoveryLevel=2 in parallel, it became very obvious that > ErrorRecoveryLevel=1 was designed to make implementations as through as > possible and force vendors to seriously take into consideration all the > needed extra funtionality that comes with multiple connection sessions. > > One issue that immediatly comes to mind is the logging out of additional > connections on the fly with a logout request with either the same or > differing CID than the connection it arrived on. It is pure speculation > as to if vendors who ultimately decide to take the multiple connection > per session at ErrorRecoveryLevel=0 route will implement any of this > functionality. IMHO, from the various inquries on the reflector > regarding multiple connections per session and ErrorRecoveryLevel=0, I > seriously doubt to see any of this additional required functionality > being implemented. > > Thanks! > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 18:07:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05883 for ; Thu, 20 Nov 2003 18:07:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxt9-00045K-Cv for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 18:07:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKN73XB015644 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 18:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxt8-00043c-Mc for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 18:07:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05820 for ; Thu, 20 Nov 2003 18:06:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxt5-0006GW-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 18:06:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMxt5-0006GT-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 18:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxt7-00042G-3E; Thu, 20 Nov 2003 18:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxsu-0003yV-8W for ips@optimus.ietf.org; Thu, 20 Nov 2003 18:06:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05768 for ; Thu, 20 Nov 2003 18:06:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxsr-0006G0-00 for ips@ietf.org; Thu, 20 Nov 2003 18:06:45 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AMxsq-0006FI-00 for ips@ietf.org; Thu, 20 Nov 2003 18:06:44 -0500 Received: from phys-giza-1 ([129.147.4.102]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAKN6EUP016434 for ; Thu, 20 Nov 2003 15:06:15 -0800 (PST) Received: from sun.com (dhcp-ubrm05-50-163.Central.Sun.COM [129.147.50.163]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HOO00B94AUEJV@giza-mail1.Central.Sun.COM> for ips@ietf.org; Thu, 20 Nov 2003 16:06:14 -0700 (MST) Date: Thu, 20 Nov 2003 16:06:45 -0700 From: Paul von Behren Subject: Re: [Ips] [Ips]target online notification In-reply-to: To: wrstuden@wasabisystems.com Cc: dan yo , ips@ietf.org Message-id: <3FBD4905.8000109@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 References: <20031114193852.83806.qmail@web20712.mail.yahoo.com> <3FB5320A.4070407@sun.com> <3FBD3837.9000700@sun.com> Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit wrstuden@wasabisystems.com wrote: > On Thu, 20 Nov 2003, Paul von Behren wrote: > > >>wrstuden@wasabisystems.com wrote: >> >>>I'm not that familiar with FCP, but isn't there a SCSI way to notice this? >> >>As far as I know, SCSI standards have no mechanism for a target to >>send a message asynchronously. There have been many proposals, >>but nothing is currently provided in the T10 specification. There >>certainly is nothing in common use. > > > iSCSI can. Please see the Asynchronous Message PDU, in section 10.9 of the > iSCSI RFC. > > From the RFC: > > The codes used for iSCSI Asynchronous Messages (events) are: > > 0 - a SCSI Asynchronous Event is reported in the sense data. Asynchronous event reporting was removed from SAM-3 last November, see http://www.t10.org/ftp/t10/document.02/02-458r0.pdf - and look at recent SAM 3 versions (current is R9). My impression is that AER was considered unimplementable (at least by some). It sounds like the iSCSI spec needs to be updated since this is no longer a valid option. > Sense Data > that accompanies the report, in the data segment, identifies the > condition. The sending of a SCSI Event (Asynchronous Event Reporting in > SCSI terminology) is dependent on the target support for SCSI asynchronous > event reporting (see [SAM2]) as indicated in the standard INQUIRY data > (see [SPC3]). Its use may be enabled SCSI Control mode page (see [SPC3]). > > >>>iSCSI can transmit asynchronous UAs back to the initiator, so any >>>initiator logged into the target can (if there's an appropriate UA) find >>>out about the LUN change. >> >>UAs are a response to an initiator request and are only possible >>if the initiator is actively sending SCSI requests. If the >>initiator is idle, then there is no message. And UAs won't help >>at all to tell an initiator when administrative actions have made >>the first logical unit available to that initiator (if the initiator >>thinks there are no units on a target, it won't be issuing any I/Os >>to get the UA). This forces a "poll the universe" policy which does >>not scale up. Hence the FC approach of using a transport-specific >>interface (LIP for loop and RSCN for fabric topologies). >> >>I agree that a SCSI/T10 solution makes more sense. But since >>FC was unable to get this solution, I think it's unlikely that >>iSCSI will. I would rather have an iSCSI-specific solution >>available rather than none. > > > See above. SAM-2 and SAM-3 agree that the fix needs to be there, and have > added it. :-) And then took it away :-( > > From looking at SAM-3, section 5.9.7 "Unit Attention condition", there is > a list of UA-generating events. One of them, "g)", is "The logical unit > inventory has been changed." Thus I think that a UA for inventory changes > is the way to go. Agreed that UA works fine when the initiator is active. What is missing (now) is the ability to asynchronously notify the initiator. The typical approach for FC drivers is that when the initiator side receives the RSCN, we rerun discovery logic - so some inquiry will see the UA. Paul > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Nov 20 18:27:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07631 for ; Thu, 20 Nov 2003 18:27:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyCZ-0005AO-4G for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 18:27:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKNR7aW019859 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 18:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyCY-0005AE-Px for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 18:27:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07595 for ; Thu, 20 Nov 2003 18:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMyCV-0006eY-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 18:27:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMyCV-0006eV-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 18:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyCT-00059D-BX; Thu, 20 Nov 2003 18:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyBn-00058T-5O for ips@optimus.ietf.org; Thu, 20 Nov 2003 18:26:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07557 for ; Thu, 20 Nov 2003 18:26:04 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMyBk-0006dq-00 for ips@ietf.org; Thu, 20 Nov 2003 18:26:16 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AMyBj-0006dn-00 for ips@ietf.org; Thu, 20 Nov 2003 18:26:15 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 75A7F40139; Thu, 20 Nov 2003 18:26:16 -0500 (EST) Date: Thu, 20 Nov 2003 15:22:46 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Paul von Behren Cc: dan yo , ips@ietf.org Subject: Re: [Ips] [Ips]target online notification In-Reply-To: <3FBD4905.8000109@sun.com> Message-ID: References: <20031114193852.83806.qmail@web20712.mail.yahoo.com> <3FB5320A.4070407@sun.com> <3FBD3837.9000700@sun.com> <3FBD4905.8000109@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , On Thu, 20 Nov 2003, Paul von Behren wrote: > wrstuden@wasabisystems.com wrote: > > iSCSI can. Please see the Asynchronous Message PDU, in section 10.9 of the > > iSCSI RFC. > > > > From the RFC: > > > > The codes used for iSCSI Asynchronous Messages (events) are: > > > > 0 - a SCSI Asynchronous Event is reported in the sense data. > > Asynchronous event reporting was removed from SAM-3 last November, > see http://www.t10.org/ftp/t10/document.02/02-458r0.pdf - and > look at recent SAM 3 versions (current is R9). > > My impression is that AER was considered unimplementable (at > least by some). That's sad. iSCSI implemented it, and our target supports it, so it is implementable in principle. :-) > It sounds like the iSCSI spec needs to be updated since this > is no longer a valid option. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 21 06:06:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09849 for ; Fri, 21 Nov 2003 06:06:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN977-0007u0-Ab for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 06:06:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALB6DlX030370 for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 06:06:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN976-0007tl-Vj for ips-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 06:06:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09831 for ; Fri, 21 Nov 2003 06:05:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN973-0000ZX-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 06:06:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN972-0000ZT-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 06:06:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN96x-0007sR-C8; Fri, 21 Nov 2003 06:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN95z-0007rQ-Je for ips@optimus.ietf.org; Fri, 21 Nov 2003 06:05:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09775 for ; Fri, 21 Nov 2003 06:04:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN95v-0000Xp-00 for ips@ietf.org; Fri, 21 Nov 2003 06:04:59 -0500 Received: from india-ironport-1.cisco.com ([64.104.129.195]) by ietf-mx with esmtp (Exim 4.12) id 1AN95v-0000Wx-00 for ips@ietf.org; Fri, 21 Nov 2003 06:04:59 -0500 Received: from cisco.com (64.104.129.221) by india-ironport-1.cisco.com with ESMTP; 21 Nov 2003 16:44:24 +0530 Received: from cbin3-mira-01.cisco.com (IDENT:mirapoint@cbin3-mira-01.cisco.com [64.104.129.145]) by india-msg-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALGW20s009428 for ; Fri, 21 Nov 2003 16:32:03 GMT Received: from cisco.com (andlx-kvs.cisco.com [64.104.131.176]) by cbin3-mira-01.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AAC49439; Fri, 21 Nov 2003 16:23:26 +0530 (IST) Message-ID: <3FBDF109.206@cisco.com> Date: Fri, 21 Nov 2003 16:33:37 +0530 From: "K. V. Subramaniam" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ips] iSNS: generating SCNs on DD change Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have a question regarding generation of regular SCNs. When a DD member is removed, or if a DD is removed or if DDS is disabled, it affects multiple initiators/targets. Do we then generate regular SCNs to each affected node? For example, consider that due to change in DD, iqn.a can no longer access iqn.b and iqn.c, then do we (a)send an SCN to iqn.a giving the info that some change has occured to SELF and expect it to query iSNS again (b) send an SCN giving OBJECT_REMOVED as reason and listing out iqn.b and iqn.c as the nodes that are no longer visible. Thanks kvs _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 21 10:13:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16891 for ; Fri, 21 Nov 2003 10:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCy1-0004pX-Sb for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 10:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALFD5WX018561 for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 10:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCy1-0004pI-IE for ips-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 10:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16838 for ; Fri, 21 Nov 2003 10:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANCxz-0003Tr-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 10:13:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANCxy-0003To-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 10:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCxx-0004oI-N3; Fri, 21 Nov 2003 10:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCxf-0004nx-O9 for ips@optimus.ietf.org; Fri, 21 Nov 2003 10:12:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16807 for ; Fri, 21 Nov 2003 10:12:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANCxd-0003Th-00 for ips@ietf.org; Fri, 21 Nov 2003 10:12:41 -0500 Received: from [203.199.199.232] (helo=hclnpd.hclt-guindy.co.in) by ietf-mx with esmtp (Exim 4.12) id 1ANCxc-0003TL-00 for ips@ietf.org; Fri, 21 Nov 2003 10:12:41 -0500 Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hclt-guindy.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VL2HAC6V; Fri, 21 Nov 2003 20:41:50 +0530 Received: from priyapc (PRIYA-PC [192.168.19.53]) by pilex.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WKBGGVDA; Fri, 21 Nov 2003 20:41:38 +0530 Message-ID: <086801c3b041$93c57520$5b13a8c0@hcltntl.co.in> From: "Priya Viswambharan" To: "K. V. Subramaniam" , References: <3FBDF109.206@cisco.com> Subject: Re: [Ips] iSNS: generating SCNs on DD change Date: Fri, 21 Nov 2003 20:40:19 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi KVS, Regular SCNs will be generated by the iSNS server to be sent to only those iSNS clients that have registered (through SCNReg) for such state changes. In your example, the iSNS server would send an SCN with the OBJECT REMOVED bit set and listing iqn.b and iqn.c as the nodes that were removed. If iqn.a wants to be doubly sure about iqn.b and iqn.c being no longer registered in the iSNS DB, an iSNS DevAttrQry with the node names as the MessageAttributes (plus some operating attributes for the nodes) may be sent for which the iSNS server would respond with no values in the Operating Attributes since the devices have been removed or have moved to a different DD. Regards, Priya ----- Original Message ----- From: "K. V. Subramaniam" To: Sent: Friday, November 21, 2003 4:33 PM Subject: [Ips] iSNS: generating SCNs on DD change > Hi, > > I have a question regarding generation of regular SCNs. When a DD member is > removed, or if a DD is removed or if DDS is disabled, it affects > multiple initiators/targets. > Do we then generate regular SCNs to each affected node? For example, > consider > that due to change in DD, iqn.a can no longer access iqn.b and iqn.c, then > do we > (a)send an SCN to iqn.a giving the info that some change has occured to > SELF and expect it to query iSNS again > (b) send an SCN giving OBJECT_REMOVED as reason and listing out > iqn.b and > iqn.c as the nodes that are no longer visible. > > > Thanks > kvs > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 21 12:08:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22698 for ; Fri, 21 Nov 2003 12:08:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANElJ-0005F2-AE for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 12:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALH85Sd020140 for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 12:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANElI-0005El-Us for ips-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 12:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22687 for ; Fri, 21 Nov 2003 12:07:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANElH-0005Pg-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 12:08:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANElH-0005Pd-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 12:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANElF-0005Cq-My; Fri, 21 Nov 2003 12:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEkr-00056o-0F for ips@optimus.ietf.org; Fri, 21 Nov 2003 12:07:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22667 for ; Fri, 21 Nov 2003 12:07:23 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEkp-0005P7-00 for ips@ietf.org; Fri, 21 Nov 2003 12:07:35 -0500 Received: from unk-for-smtp.isus.emc.com ([128.222.32.10] helo=mxic1.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1ANEkp-0005OI-00 for ips@ietf.org; Fri, 21 Nov 2003 12:07:35 -0500 Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 12:07:00 -0500 Message-ID: To: ips@ietf.org Date: Fri, 21 Nov 2003 12:06:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] Progress towards RFC publication Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Everyone, Between IESG action and some behind the scenes work by your WG chairs and ADs, significant progress has been made on RFC publication of the ips WG's drafts. -- Recent IESG actions The iSCSI Naming and Discovery and iSCSI String Profile (stringprep) drafts have been approved for RFC publication by the IESG. A minor revision was made to the latter via an RFC Editor note. Congratulations to the authors and thanks to all who have contributed. The iSNS draft was almost approved by the IESG. It needs updates to some of its security text, and we need to have the WG's MIB expert check the SNMP-related aspects of the iSNS draft. The WG chairs will contact the draft authors with specific guidance. The iSCSI boot draft is much improved over its previous version, but new issues have surfaced involving use of DHCP with IPv6 and specification of server name formats (plus some additional minor issues). Also, the references need to be carefully scrubbed to ensure that only the necessary references are normative. The WG chairs will contact the draft authors with specific guidance. Anyone looking at this draft in the draft tracker should note that Randy Bush's (mostly security) comments have been resolved by the current version of the iSCSI boot draft. -- Other drafts in the RFC Editor queue A number of normative references in the IP Storage Security draft have been made informative. This should clear the way for RFC publication of the security draft and the iSCSI draft. The WG chairs and ADs will check whether there is any problem with the current IANA processing of the AES CTR draft. The FC Encapsulation draft is in the process of being published. The FCIP draft has an additional dependence on the FCIP-SLP draft, and will have to wait for it - see below for more on the FCIP-SLP draft. The iFCP draft has an additional dependence on the iSNS draft, and will have to wait for it - see above for more on the iSNS draft. -- Other IPS WG drafts The iSCSI authentication MIB draft needs a revised version that removes the SRP and CHAP credential objects. The MIB draft author should consider this to be a public poke/ding/ request to prepare that revision. Placeholders are to be used as needed so that removal of these objects does not cause any numbering changes to other objects. Both the FCIP-SLP and iSCSI-SLP drafts are currently being held up by a security issue (what is the mandatory-to- implement security mechanism?), in addition to other IESG comments that require minor changes. The WG chairs will work on the security issue with the draft authors and the authors of the IPS security draft. T10 has completed its work related to the iSCSI name extension (allow NAA format names) draft. The authors of that draft have been asked to prepare a revised draft that references the T10 results (e.g., removes the reference to 02-419 and replaces it with a reference to the appropriate revision of SPC-3). That version of the draft will go to IPS WG Last Call. Detailed status info can be found in the IETF draft tracker: https://datatracker.ietf.org/public/pidtracker.cgi Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 21 17:24:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08379 for ; Fri, 21 Nov 2003 17:24:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJhD-0001rc-CB for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 17:24:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMOBAb007158 for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 17:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJhD-0001rN-6B for ips-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 17:24:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08320 for ; Fri, 21 Nov 2003 17:23:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJhA-0002vO-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 17:24:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANJhA-0002vL-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 17:24:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJh3-0001pf-Mb; Fri, 21 Nov 2003 17:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJgW-0001ol-ES for ips@optimus.ietf.org; Fri, 21 Nov 2003 17:23:28 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08217 for ; Fri, 21 Nov 2003 17:23:14 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ANJ31-0004bs-2r; Fri, 21 Nov 2003 16:42:39 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Fri, 21 Nov 2003 16:42:39 -0500 Subject: [Ips] Protocol Action: 'String Profile for iSCSI Names' to Proposed Standard Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , The IESG has approved following document: - 'String Profile for iSCSI Names ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points each have a globally-unique name that must be transcribable, as well as easily compared. This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. It is a profile for iSCSI of RFC 3454, Stringprep. Working Group Summary The working group strongly supported advancement of this specification. Protocol Quality During Last Call, there was some very constructive review by the community. The document was reviewed for the IESG by Paul Hoffman and Allison Mankin RFC Editor Note: Old: In addition, any upper-case characters input via a user interface     should be mapped to their lower-case equivalents. New: In addition, any upper-case characters input via a user interface MUST be mapped to their lower-case equivalents. The reference to [stringprep] in Section 6 should be a reference to [RFC3454]. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 21 17:39:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09247 for ; Fri, 21 Nov 2003 17:39:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJva-0003JW-9f for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 17:39:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMd2Jd012732 for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 17:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJva-0003JH-00 for ips-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 17:39:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09238 for ; Fri, 21 Nov 2003 17:38:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJvX-0003Id-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 17:38:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANJvX-0003Ia-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 17:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJvY-0003HQ-DG; Fri, 21 Nov 2003 17:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJul-0003EX-Ez for ips@optimus.ietf.org; Fri, 21 Nov 2003 17:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09233 for ; Fri, 21 Nov 2003 17:37:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJui-0003IH-00 for ips@ietf.org; Fri, 21 Nov 2003 17:38:08 -0500 Received: from email-out2.iomega.com ([147.178.1.83] helo=email.iomega.com) by ietf-mx with esmtp (Exim 4.12) id 1ANJui-0003I3-00 for ips@ietf.org; Fri, 21 Nov 2003 17:38:08 -0500 Received: from royntex01.iomegacorp.com (unknown [147.178.90.120]) by email.iomega.com (Postfix) with ESMTP id 96F5216A6 for ; Fri, 21 Nov 2003 15:37:38 -0700 (MST) Received: from [147.178.176.49] ([147.178.176.49]) by royntex01.iomegacorp.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Nov 2003 15:37:38 -0700 Subject: Re: [Ips] Protocol Action: 'String Profile for iSCSI Names' to Proposed Standard From: Pat LaVarre To: ips@ietf.org In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1069454227.15688.65.camel@patrh9> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 21 Nov 2003 15:37:07 -0700 X-OriginalArrivalTime: 21 Nov 2003 22:37:38.0517 (UTC) FILETIME=[11118850:01C3B080] Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > New: >=20 > In addition, any upper-case characters input via a user interface > MUST be mapped to their lower-case equivalents. Do we already have lots of precedent for mapping-to-lower-case near here in ietf space? Once upon a time mapping-to-upper-case introduced less noise than mapping-to-lower-case. Is that no longer true? I'm not sure I precisely remember why. Might be that people left accents off of uppercase letters, and doubled vowels in upper case e.g. in Espa=C3=B1ol using CANON to mean ca=C3=B1on and using EE.UU to mean Es= tados Unidos. Curiously yours in truly breathtaking ignorance, Pat LaVarre P.S. Honestly, all I personally know about iSCSI is that in the past and perhaps still now it can accurately count data bytes copied, which places it a level above many SCSI-over-whatever protocols in my estimation. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Nov 21 17:50:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09822 for ; Fri, 21 Nov 2003 17:50:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANK6F-00044k-OR for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 17:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMo3G9015660 for ips-archive@odin.ietf.org; Fri, 21 Nov 2003 17:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANK6F-00044V-KO for ips-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 17:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09812 for ; Fri, 21 Nov 2003 17:49:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANK6D-0003YW-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 17:50:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANK6C-0003YT-00 for ips-web-archive@ietf.org; Fri, 21 Nov 2003 17:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANK6E-00043P-4U; Fri, 21 Nov 2003 17:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANK5X-00042F-9S for ips@optimus.ietf.org; Fri, 21 Nov 2003 17:49:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09794 for ; Fri, 21 Nov 2003 17:49:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANK5U-0003Xa-00 for ips@ietf.org; Fri, 21 Nov 2003 17:49:16 -0500 Received: from [66.155.203.134] (helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1ANK5U-0003WP-00 for ips@ietf.org; Fri, 21 Nov 2003 17:49:16 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hALMmgf9001916 for ; Fri, 21 Nov 2003 17:48:42 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hALMmgiu001911; Fri, 21 Nov 2003 17:48:42 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id hALMmfM01680; Fri, 21 Nov 2003 17:48:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16318.38475.940995.308220@gargle.gargle.HOWL> Date: Fri, 21 Nov 2003 17:48:43 -0500 From: Paul Koning To: p.lavarre@ieee.org Cc: ips@ietf.org Subject: Re: [Ips] Protocol Action: 'String Profile for iSCSI Names' to Proposed Standard References: <1069454227.15688.65.camel@patrh9> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >>>>> "Pat" =3D=3D Pat LaVarre writes: >> New: >>=20 >> In addition, any upper-case characters input via a user interface >> MUST be mapped to their lower-case equivalents. Pat> Do we already have lots of precedent for mapping-to-lower-case Pat> near here in ietf space? Pat> Once upon a time mapping-to-upper-case introduced less noise Pat> than mapping-to-lower-case. Is that no longer true? Pat> I'm not sure I precisely remember why. Might be that people Pat> left accents off of uppercase letters, and doubled vowels in Pat> upper case e.g. in Espa=C3=B1ol using CANON to mean ca=C3=B1on a= nd Pat> using EE.UU to mean Estados Unidos. That's a good reason to go to lower case, because then you don't lose accents. Another problem is that some places keep the accents on uppercase letters when others don't (it's not even the same everywhere for a given language). So downcasing (with accents, if any, preserved) is less dependent on location than upcasing. Also, some letters have no uppercase equivalent. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Nov 24 14:37:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23507 for ; Mon, 24 Nov 2003 14:37:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMWW-0002sj-Um for ips-archive@odin.ietf.org; Mon, 24 Nov 2003 14:37:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOJbSFc011071 for ips-archive@odin.ietf.org; Mon, 24 Nov 2003 14:37:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMWW-0002sM-J2 for ips-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 14:37:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23497 for ; Mon, 24 Nov 2003 14:37:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMWT-00035V-00 for ips-web-archive@ietf.org; Mon, 24 Nov 2003 14:37:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOMWT-00035O-00 for ips-web-archive@ietf.org; Mon, 24 Nov 2003 14:37:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMW5-0002iz-Gy; Mon, 24 Nov 2003 14:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMVh-0002i3-JF for ips@optimus.ietf.org; Mon, 24 Nov 2003 14:36:37 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23484 for ; Mon, 24 Nov 2003 14:36:22 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AOMPn-0005uP-5h; Mon, 24 Nov 2003 14:30:31 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Mon, 24 Nov 2003 14:30:31 -0500 Subject: [Ips] Document Action: 'iSCSI Naming and Discovery' to Informational RFC Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , The IESG has approved following document: - 'iSCSI Naming and Discovery ' as an Informational RFC This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips