Re: iSCSI : Holes in StatSN

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

Julian,

I did'nt hear back on my issues related to attempting per-PDU recovery, namely
:

a) This goes back to attempting to recover a portion of the I/O as opposed to
command level recovery. I believe the WG consensus at Orlando was to use
command level recovery (?)

b) A request to re-send a Data PDU within an I.T.T must be qualified by (I.T.T
+ missing_DataSN).
The I.T.T & DataSN CANNOT be reliably extracted from the PDU in the cases of a
header format error or header digest error. IOW, the per-PDU scheme does not
solve all the cases.

Regarding overlapped data xfers, FCP prohibited it and seems to have no
problems with this. Also, this feature is un-used in most cases. I don't
believe restricting iSCSI to support a sub-set of the optional features of
SAM-2 violates either T10 philosophy or SAM-2. OTOH, specifying guidelines
that mandate which features shall be used and un-used (along the lines of
FC-PLDA and FC-FLA documents) is the only reliable recipe for
interoperability.

Regards,
Santosh


julian_satran@il.ibm.com wrote:

> Santosh,
>
> Overlaps and out of order delivery and gaps are not forbidden by SAM . I
> think we have to go to T10 for that I can't see a good reason to do it. We
> have a good solution without asking for it .  I can see large and important
> future application that will relay on overlaps and/or gaps and I am not
> going to foolishly do something to disable or harm their efficient
> implementation.  I think that T10s philosophy of keeping the target master
> of the transfer and not limiting it in any way is too valuable to ignore.
>
> IMHO your request violates our charter without any good reason to support
> it.
>
> Julo
>
> Santosh Rao <santoshr@cup.hp.com> on 01/02/2001 03:53:13
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI : Holes in StatSN
>
> julian_satran@il.ibm.com wrote:
>
> > With a data sequence we may want to use a similar mechanism to ask for a
> > missed data block as soon as we see one of its successors or the status.
>
> Julian,
>
> The missing data PDU is missing due to either a header format error, header
> digest error or data digest error. [in all other cases, TCP ensures
> reliable
> delivery].
>
> In 2 of the above 3 cases, [header format error & header digest error] the
> initiator CANNOT do a safe interpretation of the PDU header. Without
> interpreting the PDU header, the initiator does NOT get the Initiator Task
> Tag. Any request to re-send a particular data PDU MUST be qualified by :
> I.T.T + missing_DataSN [+ T.T.T + CmdSN, optionally].
>
> Since I.T.T. cannot be reliably determined in 2 of the 3 cases, such a
> re-send request cannot be reliably achieved.
>
> The alternate proposal that was made should be considered in its place,
> which
> was to :
> - dis-allow overlapped data xfer's
> - initiators do a count check
> - a command level retry is performed at the iSCSI layer on detecting an
> underrun [due to a missing PDU].
>
> On several ocassions, requests from different people have been made on this
> list to dis-allow overlapped data xfers. Can a WG consensus be sought on
> this
> issue to see if the benefits of allowing overlapped data xfer's offset its
> complexities and justify its support ?
>
> Regards,
> Santosh
>
>  - santoshr.vcf
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