Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h089p5601043 for ips-outgoing; Wed, 8 Jan 2003 04:51:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h089p4W01038 for ; Wed, 8 Jan 2003 04:51:04 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h089ovv4012452; Wed, 8 Jan 2003 10:50:57 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h089ou3J146788; Wed, 8 Jan 2003 10:50:56 +0100 To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: timeouts MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Wed, 8 Jan 2003 11:50:44 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/01/2003 11:50:56, Serialize complete at 08/01/2003 11:50:56 Content-Type: multipart/alternative; boundary="=_alternative 00355F1FC2256CA8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00355F1FC2256CA8_= Content-Type: text/plain; charset="US-ASCII" The timeout in 9.3 is for missing things not connection teardown. I thought the text is explicit enough but obviously it is not. How about: iSCSI recovery actions are often dependent on iSCSI time-outs being recognized and acted upon before SCSI time-outs. Determining the right time-outs to use for various iSCSI actions (command acknowledgements expected, status acknowledgements, etc.) is very much dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI driver). As a guide, the implementer may use an average Nop-Out/Nop-In turnaround delay multiplied by a "safety factor" (e.g., 4) as a good estimate for the basic delay of the iSCSI stack for a given connection. The safety factor should account for the network load variability. For connection teardown the implementer may want to consider also TCP common practice for the given infrastructure. Julo --=_alternative 00355F1FC2256CA8_= Content-Type: text/html; charset="US-ASCII"
The timeout in 9.3 is for missing things not connection teardown. I thought the text is explicit enough but obviously it is not.

How about:

iSCSI recovery actions are often dependent on iSCSI time-outs being recognized and acted upon before SCSI time-outs. Determining the right time-outs to use for various iSCSI actions (command acknowledgements expected, status acknowledgements, etc.) is very much dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI driver). As a guide, the implementer may use an average Nop-Out/Nop-In turnaround delay multiplied by a "safety factor" (e.g., 4) as a good estimate for the basic delay of the iSCSI stack for a given connection. The safety factor should account for the network load variability.  For connection teardown the implementer may want to consider also TCP common practice for the given infrastructure.

Julo

--=_alternative 00355F1FC2256CA8_=--