Re: iSCSI:Intent of sec. 8.4 of draft 07-95

[Santosh Rao <santoshr@cup.hp.com>]

Barry Reinhold wrote:

> Clause 8.4 states:
>
> "- If the discarded PDU is a response PDU, initiator MUST do
>              one of the following -
>                        a) Request PDU retransmission with a status SNACK.
>                           [OR]
>                        b) Logout the connection for recovery and continue
>                           the tasks on a different connection instance as
>                           described in section 7.1. [OR]
>                        c) Logout to close the connection (abort all the
>                           commands associated with the connection) "
>
> Is it the intent of the draft to eliminate the action of just dropping the
> PDU. (i.e. allowing error recovery by having a SCSI timeout?)

Barry,

While the "discard PDU" technique works fine for data-in & r2t pdu's, it does
not work well for status pdu's, due to the current model of statsn
acknowledgement. If you dropped the status pdu's and did not use SNACK, you
would be unable to acknowledge any further status pdu's on that connection,
and the target would be unable to release any further status PDU resources on
that connection. Eventually, the target is likely to run out of resources and
take some action like dropping the connection or session.

Thus, once a statsn is dropped, you will have to perform one of the actions
listed above or could even perform session logout. [un-listed option.].

This is a direct dis-advantage of the statsn acknowledgement scheme which is
a -ve snack. if an in-band technique of positive status acknowledgement were
provided, wherein, the initiator sent a statsn +ve ack indicating the status
pdu's she has received, one could use the "discard pdu" technique with staus
pdu's as well.

This +ve ack mechanism has been suggested for status pdu's but has not been
accepted [yet]. I'm in favor of the simple "discard pdu" approach since it
works fine for most initiator implementations and is the standard  practice
with SCSI-FCP initiators. [FCP, not FCP-2].

Regards,
Santosh
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard