Re: Comments on the Draft (sync loss)

[David Robinson <David.Robinson@EBay.Sun.COM>]

> Section: General
> There's no framing of the headers and data on the buffers from TCP. If
> anything goes wrong with the parsing, its difficult if not impossible to
> recover. It only takes one length field to be 'off'. If this happens the
> target will probably generate lots of "Opcode not understood" messages.   We
> suggest one of two methods: 1) after seeing consecutive "Opcode not
> understood" messages it should shut down the connection if this doesn't
> solve the problem then reset the target, or 2)  When the target finds that
> it is out of sync with the initiator ( on receipt of an "Opcode not
> understood"), it will send a new iSCSI "Out of Sync" command to the
> initiator.  The initiator will assume at the reception of the "Out of Sync"
> command that all unacknowledged outstanding requests have been dropped.  The
> initiator then sends the next command with the OOB (out of band) bit set,
> and with the OOB offset pointing to the beginning of the iSCSI header.  The
> target, after sending the "Out of Sync" command, should ignore every thing
> on that connection and wait for the OOB data to re-sync again.  This
> exchange could also work if sent from the initiator to the target.

The loss of sync is an extremely rare event, either the sender sent a
request shorter than it indicated, the TCP stack caused corruption,
or the receiver misinterpreted the request.  All are severe bugs
somewhere, in practice with NFS over TCP which has no framing, sync errors
are so rare that it is ignored.  Instead of going through a complex process
of setting OOB to resync, then determine which messages need to
be resent, why not instead simply drop the connection and do the
common lost connection recovery.  The symptoms and state that needs
to be recovered is virtually identical.

Lets try to stay simple and not overly complicate the recovery process.

	-David