Re: SNACK and recovery

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

> And at the moment SNACK is not required by the iSCSI
> specification.  Such a target can choose to continue not to
> retain status and hence reject all SNACKs (although the
> result may well be that the TCP connection closes).  

The iSCSI rev 05 does mandate Status SNACK [though there has been talk in
this thread of changing that]. The Status SNACK mechanism, as currently
defined in the spec, will block forward progress of resource release at
targets if it is made optional, [eventually resulting in connection
close].

The lack of ability to handle StatSN SNACK must not result in TCP
connection closes. This is a result of the current SNACK model which only
allows forward progress with resource release if targets support status
SNACK. 

An alternate SACK mechanism which allowed initiators to selectively
acknowledge status PDUs that were received would not result in TCP
connection closes in such scenarios.

The current SNACK mechanism is biased towards targets that retain I/O
state information and penalizes implementations that do not do this [by
blocking forward progress of resource release when holes occur in StatSN].

- Santosh