Re: iSCSI: too much recovery?

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

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