Re: iSCSI: too much recovery?

["Jon Hall" <jhall@emc.com>]

Julian,

OK, Thanks.  But... :-)

julian_satran@il.ibm.com writes:
>1)Read digest as CRC. Sometimes you may want a stronger one with
>authentication but the you will not use CRC.

For data sure, why on iSCSI headers?  Does not the StatSN
mechanism derive from the notion that a header digest/CRC
fails?  Is it possible that this header digest/CRC is not
providing much over and above the TCP cksum.  While retry
based on StatSN is causing a good bit of complexity in the
protocol?

>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.

I get confused, why is per connection easier than per
session?  The target's task state must be maintained at the
session level.  Pushing StatSN into the connection makes per
connection state more complicated; it now contains a subset
of the session's task state.

Stepping back, if my naive model is too drastic, what
specifically are the error cases that can be recovered, and
is their frequency such that the complexity of all the retained
state is warranted?  If the error in question is a pdu that
passes the TCP cksum but fails an iSCSI header CRC, that may
happen but is that going to be a frequent event?  Since initiator
recover and retry must be implemented in any case...

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

Sorry to be dense, but the questions above...

>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.

Assuming a healthy connection, what additional information is in
the Logout Response pdu that is not seen by the Logout sender when
the Logout receiver closes the connection?  Or, asked another way,
if response=1 in the Logout Response pdu, what happens...

Thanks,
Jon

>"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
>