Re: Ordered delivery capability notification

[Matt Wakeley <matt_wakeley@agilent.com>]

A better solution is to change "SHOULD deliver the commands to the target SCSI
layer in the order specified by CmdSN" to "MUST".

-Matt

Pierre Labat wrote:
> 
> 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.