iSCSI: Ordered delivery capability notification]

[Pierre Labat <pierre_labat@hp.com>]

Hoops! I forgot to add the "iSCSI"  prefix

---

• To: ips@ece.cmu.edu
• Subject: Ordered delivery capability notification
• From: Pierre Labat <pierre_labat@hp.com>
• Date: Wed, 10 Jan 2001 19:45:14 -0800
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=us-ascii
• Organization: Hewlett Packard ATM-SISL
• Sender: plabat@cup.hp.com

Julian,


Where:
======

1.2.2.1 Command numbering

"iSCSI supports ordered command delivery within a session"

"The target iSCSI layer SHOULD deliver the commands to the target
SCSI layer in the order specified by CmdRN".


Problem:
=======
An initiator is unable to know if the iSCSI target layer support ordered

 command delivery. Hence it cannot trust iSCSI to have ordered delivery.

Hence all the iSCSI ordering mechanism becomes useless because
it can't be trusted.
The problem is not that iSCSI target layers can't support ordered
delivery,
the problem is that the initiator/application doesn't know anything
about it.


Solution:
======

a) Add a Login/Text key
Ordered:<yes|no>

b) Put the explanation in for the key:
"If the target answered "yes" and is unable to maintain the order for
  whatever reason, it must notify the initiator and drop the session"

If the target answered "yes", when it receives a  "retried" command
(retry bit),
it must be able to retry the command in such a way that the effect
on the initiator and target device when the command completes
is the same as if the command would have not needed to be retried.
This doesn't mean always restart from where left, a READ
can have all the data re-transmitted because it is transparent
a completion time.

---