Re: iSCSI: too much recovery?

[julian_satran@il.ibm.com]

Jon,

1)Read digest as CRC. Sometimes you may want a stronger one with
authentication but the you will not use CRC.

2) You don't need ordering only simple acknowledgement to free resources.
As such per connection  is simpler to implement and maintain. You may
choose to do what you suggested
and recover by retrying but most of this group consider this too drastic.

3)SACK is there to recover lost (digest error) responses or data blocks.

4)Logout response is there to make sure that you had an orderly close (not
necessarily a shutdown - e.g., take out an adapter for maintenance)  and no
other recovery is needed. Recall that it can be sent on a healthy
connection for a bad one.

Julo

"Jon Hall" <jhall@emc.com> on 16/03/2001 18:21:48

Please respond to "Jon Hall" <jhall@emc.com>

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: too much recovery?




Hi,

I have some questions...

1) Why is there a header digest, is the TCP cksum not sufficient
   for iSCSI headers?

2) Why is the StatSN per connection and not per session?  Why not
   adopt the model that once the target sends a StatSN it may release
   the associated resources and need not retain that task's state?
   If the initiator does not see the StatSN it must recover and retry.

3) Similarly, why is there a SACK Request pdu?

4) And, why is there a Logout Response pdu?  Why not send a Logout
   and wait for the peer to close the connection.  If the connection
   does not close send another Logout and close the connection.

Implicit is an overarching question -- when errors happen will it be
possible for iSCSI peers to communicate in the manner that the spec
seems to assume?

Thanks,
Jon