Subject: Re: iSCSI: DAP Last Call Comments

From: "Julian Satran" <[email-masked]>
Date: Sun, 14 Jul 2002 10:18:06 +0300

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) +++

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.

+++ the only bound required by protocol is stated here. The mechanisms 
described in 6 allow machines with different implementations to 
interoperate. The text is not vague. It just does say only what needs to 
be said. +++

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)

+++ the statement refers to unsolicited data for different commands on a 
given connection and is correct+++

T                p 73            4.2 Text Mode Negotiation: 6th paragraph: 
3rd sentence: change the
"should" to a "must"

+++ so long as it is lower-case fine +++
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".

+++ Irrelevant is completely define and allows us to be build easier 
packages tolerant to different parameter combinations in a few exchanges. 
+ We may do it implicitly but explicit is better++

T                p 73            4.2 Text Mode Negotiation: 9th paragraph: 
specify that a
"key=NotUnderstood" is applicable for "X-keys" only.

+++ It practically says this for the current version. We do not want to 
forbid it for other keys in future versions +++

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.
+++
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. +++

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.
+++

---

From: "Dave Peterson" <[email-masked]>
Date: Mon, 22 Jul 2002 15:31:39 -0500

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

  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.

  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.

   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.