Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"

[Santosh Rao <santoshr@cup.hp.com>]

Mark Bakke wrote:

> Part of the reason that the session recovery mechanism was added
> was to support "non-idempotent" devices, such as tape drives,
> media changers, printers (although there are better ways to get
> to printers over a network than iSCSI), and so on.  Disks can
> usually deal with error recovery at the SCSI level, since it's
> not so bad to (carefully) re-try reads and writes.  Multipath
> drivers, such as PowerPath, deal with these over multiple interfaces
> as well.  However, stream commands do not include the concept
> of a block offset, so sending a write twice will write two blocks
> on the tape, rather than just writing the same location twice as
> in a disk.  SCSI tape drivers do not attempt this sort of recovery;
> it has to either be handled by the application (most applications
> just abort the backup, restore, or whatever), or by the transport,
> which is what the use of StatSN was created to provide.

Mark,

First off, we are talking about scenarios caused by a TCP checksum
escape that was caught by an iSCSI digest [CRC]. GIven the TCP checksum
escape rates that Pierre was quoting in his earlier mail, this is too
low a rate to justify inclusion of intra-task recovery mechanisms in
iSCSI.

Such non-idempotent devices can respond with a Reject indicating a
reason of "command retry reject" when they see a command with the
"retry" bit set. Given the low rate of TCP checksum escapes, the impact
to sequential access media type devices is minimal and the cost of
buffering all data buffers until StatSN has been acknowledged may be a
higher cost compared to the benefits derived from intra-task recovery.

There is also the question of protocol stability and simplicity. If we
keep iSCSI down to minimal additional error recovery other than existing
TCP and SCSI recovery mechanisms, we are enhancing the stability of the
solution since it relies on existing mature error recovery schemes.
Continuing to add new additional error recovery schemes into iSCSI on
top of TCP and SCSI error recovery mechanisms will turn iSCSI into
another nightmare like FC in terms of complexity and interop.

Regards,
Santosh
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard