Subject: iSCSI:Intent of sec. 8.4 of draft 07-95

From: "Barry Reinhold" <[email-masked]>
Date: Thu, 20 Sep 2001 14:02:02 -0400

Clause 8.4 states:

"- If the discarded PDU is a response PDU, initiator MUST do
             one of the following -
                       a) Request PDU retransmission with a status SNACK.
                          [OR]
                       b) Logout the connection for recovery and continue
                          the tasks on a different connection instance as
                          described in section 7.1. [OR]
                       c) Logout to close the connection (abort all the
                          commands associated with the connection) "

Is it the intent of the draft to eliminate the action of just dropping the
PDU. (i.e. allowing error recovery by having a SCSI timeout?)

Barry Reinhold
Principal Architect
Trebia Networks
[email-masked]
603-868-5144/603-659-0885/978-929-0830 x138

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 20 Sep 2001 16:25:15 -0700

Barry,

Let me comment on your question.

A lost status PDU causes more than a SCSI timeout to the 
concerned task!  A lost status creates a gap in the StatSN space
that prevents the initiator to acknowledge any StatSNs after
the gap.  Either the lost status has to be recovered, or the
connection has to be done away with - that's what the quoted
text is describing.

Please refer to the following URL and its related thread for 
additional discussion on the editing philosophy behind error 
recovery details in the draft - specifically the internal 
implementation Vs on-the-wire aspects of error recovery.

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06564.html

Regards.
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
[email-masked]

---

From: Santosh Rao <[email-masked]>
Date: Thu, 20 Sep 2001 15:55:17 -0700

Barry,

While the "discard PDU" technique works fine for data-in & r2t pdu's, it does
not work well for status pdu's, due to the current model of statsn
acknowledgement. If you dropped the status pdu's and did not use SNACK, you
would be unable to acknowledge any further status pdu's on that connection,
and the target would be unable to release any further status PDU resources on
that connection. Eventually, the target is likely to run out of resources and
take some action like dropping the connection or session.

Thus, once a statsn is dropped, you will have to perform one of the actions
listed above or could even perform session logout. [un-listed option.].

This is a direct dis-advantage of the statsn acknowledgement scheme which is
a -ve snack. if an in-band technique of positive status acknowledgement were
provided, wherein, the initiator sent a statsn +ve ack indicating the status
pdu's she has received, one could use the "discard pdu" technique with staus
pdu's as well.

This +ve ack mechanism has been suggested for status pdu's but has not been
accepted [yet]. I'm in favor of the simple "discard pdu" approach since it
works fine for most initiator implementations and is the standard  practice
with SCSI-FCP initiators. [FCP, not FCP-2].

Regards,
Santosh