Re: iSCSI: StatSN Field in R2T messages.

["Julian Satran" <Julian_Satran@il.ibm.com>]

Gwendal,

StatSN is just "piggybacked" on R2T - 9.8.2 says specifically it is not advanced (R2Ts are counted with Data-In).
It can help detect holes in the response sequence.
For Data-In as you have guessed it is used actively (and advanced)  when S=1 and reserved otherwise.
And yes we could have chosen to present it and not advance it when S=0 but the decision not to do so was
to avoid having too many fields processed for a Data PDU (in the early days we contemplated Data PDU to have nothing else than the placement information for a Remote DMA).

Julo

"Gwendal Grignou" <ggrignou@silverbacksystems.com> Sent by: owner-ips@ece.cmu.edu 06/26/2002 10:15 PM Please respond to "Gwendal Grignou"

To:        <ips@ece.cmu.edu>         cc:                 Subject:        iSCSI: StatSN Field in R2T messages.

Hello,

I have a question about the rational of having StatSN field populated in
R2T messages. R2T messages and Data IN without S bit are the only
messages that are not a response to an iSCSI request. Data IN without S
bit has the StatSN field reserved (9.7.4), but not for R2T messages.
I wonder how StatSN is used by the initiator in the R2T message: if the
R2T is a retransmission, it will carry the StatSN sent the first time
(according to 9.16, the target is not allowed to change StatSN), so it
is meaningless for the initiator ; if the R2T is not a retransmission,
StatSN will the same value as the last StatSN sent in the last iSCSI
response (9.8.2), so several R2Ts for the same command may have
different StatSN, if another iSCSI response is sent between 2 R2Ts.

The only advantage I see is the possibility for the initiator to detect
a missing iSCSI response a little earlier, while receiving R2Ts rather
than while receiving a iSCSI response, but for the sake of simplicity
and coherency, I am wondering if StatSN field can be marked as reserved
for R2T messages.

Gwendal.