Subject: iSCSI: DAP Last Call Comments

From: "Dave Peterson" <[email-masked]>
Date: Sun, 7 Jul 2002 15:19:17 -0500

T	p 36	2.2.2.1 Command Numbering and Acknowledging: 7th paragraph: if not in
this document, where is the means to request immediate delivery for a
command?
T	p 38	2.2.2.2 Response/Status Numbering and Acknowledging: 4th paragraph:
this paragraph is too vague which may result in different error recovery
initiations being implemented.
T	p 43	2.2.4 iSCSI Full Feature Phase: 16th paragraph: last sentence is not
correct since out of order data delivery is allowed (if negotiated)
T	p 73	4.2 Text Mode Negotiation: 6th paragraph: 3rd sentence: change the
"should" to a "must"
T	p 73	4.2 Text Mode Negotiation: 8th paragraph: the use of "Irrelevant" is
a potential interoperability problem. Need to further specify the use of
"Irrelevant".
T	p 73	4.2 Text Mode Negotiation: 9th paragraph: specify that a
"key=NotUnderstood" is applicable for "X-keys" only.
T	p 103	6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry
remain broken rendering it useless for tape operation. SCSI level error
detection and recovery is the preferred mechanism. Refer to previous emails
sent via the IPS reflector regarding this matter.
T	p 128	8.6 Considerations for State-dependent devices: last paragraph:
don't agree with the statement that error recovery at the iSCSI level
(specifically Retry in its current state) is advisable. Retry at the SCSI
level is feasible and is not difficult (i.e., READ POSITION and LOCATE
commands). This paragraph should be removed.
T	p 214	11.11 BidiInitialR2T: this text key provides no value and needs to
be removed. InitialR2T should be used for both uni and bidirectional
commands. In addition, if BidiInitialR2T were to be used, it will not
function via an iSCSI-FCP gateway.

---

From: [email-masked]
Date: Thu, 25 Jul 2002 19:14:27 -0400

A quick process note.  Dave Peterson does have open WG Last
Call technical issues on iSCSI Retry and recommendations for
SCSI vs. iSCSI recovery in the email below that didn't make
it into the comprehensive list of technical issues posted earlier.
 
I think the issues are textual as opposed to ones that
will result in any need for protocol changes, and I'm
attempting to work out some satisfactory text offline
with Dave and Julian (it'll be posted here when agreed to).
 
Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

-----Original Message-----
From: Dave Peterson [mailto:[email-masked]]
Sent: Monday, July 22, 2002 4:32 PM
To: Julian Satran
Cc: Ips@Ece. Cmu. Edu
Subject: RE: iSCSI: DAP Last Call Comments

Howdy Julian,
Comments to your comments below...dap

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Sunday, July 14, 2002 2:18 AM
To: Dave Peterson
Cc: Ips@Ece. Cmu. Edu; [email-masked]
Subject: Re: iSCSI: DAP Last Call Comments

Dave - Comments in text - Thanks, Julo 

	"Dave Peterson" <[email-masked]> 
Sent by: [email-masked] 

07/07/2002 11:19 PM 
Please respond to "Dave Peterson" 

        To:        "Ips@Ece. Cmu. Edu" <[email-masked]> 
        cc:         
        Subject:        iSCSI: DAP Last Call Comments 

T                 p 36                 2.2.2.1 Command Numbering and
Acknowledging: 7th paragraph: if not in
this document, where is the means to request immediate delivery for a
command?

+++ in some API document provided by your friendly implementer - there is no
iSCSI CAM (no pun intended) +++ 
 
dap: I hope an application (client) does not have to deal with multiple ways
via different vendors to request immediate delivery. Sounds like this should
be added to the iSCSI HBA API so we don't have to deal with differing vendor
implementations to enable/disable this feature.

T                 p 103                 6.1.1 Usage of Retry and 6.7 SCSI
Timeouts: the semantics of Retry
remain broken rendering it useless for tape operation. SCSI level error
detection and recovery is the preferred mechanism. Refer to previous emails
sent via the IPS reflector regarding this matter. 
+++ Dave. The retry scheme for connection recovery implies that the other
two levels are there. 
So even if I would agree with your POW (which I am not) for practical
reasons the mechanisms described 
will have to stay. 
+++ 
 
dap: again, without a standardized method for error detection (see the
options I listed) to determine when the retry may be performed, the retry
functionality is broke/useless/inconsistent for tape applications. This is
not an implementation detail as some suggest. This must be consistent across
vendor implementations for a tape application to work consistently.
   
T                 p 128                 8.6 Considerations for
State-dependent devices: last paragraph:
don't agree with the statement that error recovery at the iSCSI level
(specifically Retry in its current state) is advisable. Retry at the SCSI
level is feasible and is not difficult (i.e., READ POSITION and LOCATE
commands). This paragraph should be removed. 
+++ that is not what we repeatedly hear. I will however make a "softer"
statement. +++  
 
dap: I don't know who is feeding you this information. READ POSITION is and
has been mandatory to implement for tape devices for quite a while now.
Additionally I'm on the verge of making LOCATE mandatory (in reality if READ
POSITION is implemented, so is LOCATE). Any backup app/application client
worth anything uses READ POSITION (and LOCATE). I have a major problem with
any text that suggests otherwise. The use of READ POSITION and LOCATE
mitigates the need for retry (and most error recovery) at the transport
level, and this is where I want to go. Retry at the application level simply
must not be performed without first:
1. determine the position of the device using READ POSTITION, then
2. (re)position the device if neccessary, then
3. continue
This is not difficult, provided READ POSITION/LOCATE are supported.
 
If the offending paragraph is indeed targeted for legacy device support, it
certainly does not say that. In reality, todays inplementations use READ
POSITION/LOCATE extensively and (legacy) devices that do not support these
commands are very rare for this type of tape application/environment.
I expect that a legacy tape device will be front-ended by a bridge device
(i.e., I don't expect to see a native-iSCSI legacy tape device). This legacy
tape device will not support the desirable functionality (such as FCP-2
error detection and recovery) thus placing a burden on a bridge device if
the desired goal is to be achieved.
Furthermore, the legacy devices will generally be of the Parallel SCSI
variety, not FCP. The FCP-x tape devices I know of each support READ
POSITION/LOCATE.
 
The offending paragraph (draft 15):
"For many of those state changing commands the execution model also assumes
that the command is executed exactly once. For those commands a retry at
SCSI level is not feasible or very difficult and error recovery at iSCSI
level is advisable."
must be removed.

Note: The connection reassignment capability does provide use for tape
applications, e.g, will hopefully keep the application running. I have no
problem using the retry functionality in this context.
 
T                 p 214                 11.11 BidiInitialR2T: this text key
provides no value and needs to
be removed. InitialR2T should be used for both uni and bidirectional
commands. In addition, if BidiInitialR2T were to be used, it will not
function via an iSCSI-FCP gateway.

+++ A gateway can easily map the keys. We don't know enough to decide
off-hand to remove it. 
But I am still listening. 
+++ 

 dap: There is no reason to have a different key to indicate whether or not
an R2T will be used for bidi commands. InitialR2T works just fine for both.
FCP uses just one parameter (i.e., write FCP_XFER_RDY disabled) for both and
all is well. What more can I say, other than remove the key.