Subject: iSCSI: too much recovery?

From: "Jon Hall" <[email-masked]>
Date: Fri, 16 Mar 2001 11:21:48 -0500

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

---

From: [email-masked]
Date: Fri, 16 Mar 2001 17:46:27 +0200

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" <[email-masked]> on 16/03/2001 18:21:48

Please respond to "Jon Hall" <[email-masked]>

To:   [email-masked]
cc:
Subject:  iSCSI: too much recovery?

Hi,

I have some questions...

Thanks,
Jon

---

From: "Jon Hall" <[email-masked]>
Date: Mon, 19 Mar 2001 10:03:48 -0500

Santosh Rao writes:
>StatSN needs to be on a per-connection basis. If StatSNs were on a per-session
>basis, consider the following problem :
>
>- StatSN 1 is sent out on connection 1
>- StatSN 2 is sent out on connection 2
>
>Since these 2 status' are sent on different connections, StatSN 2 could arrive
>prior to StatSN 1. The initiator detects a hole in StatSN (StatSN 1 is missing)
>and issues a Status SACK to request StatSN 1, whereas StatSN 1 is still on its
>way to the initiator.
>
>Also, StatSN per connection avoids sharing StatSN state across connections [and
>thereby, NICs].

Oh, that's what the SACK pdu is for :-).

Seriously, I'm wanting to understand why the target is retaining
the state necessary to support the SACK pdu.  Because, it seems
that the complexity that follows is large (for example, what about
the potential for task tag collision?).

Unless I'm missing something, the problem StatSN solves is a
lost/corrupt iSCSI header.  Since this is in the context of a
TCP "reliable" byte stream, it happens when a TCP cksum fails to
see corruption that an iSCSI CRC/digest does see.  Assuming that
the greater part of a iSCSI/TCP stream is data, this will happen
mostly to data packets (which presumably are covered by a separate
iSCSI data CRC).

If that thinking holds, then it seems important to answer the
question, what is the frequency of an iSCSI header digest/CRC
failure?  From this comes, is this event sufficiently rare that
initiator recovery and retry is acceptable?  Although some of my
earlier questions presume the answer, I don't know the answer.

-Jon