Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"

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

Jon Hall wrote:
> 
> But CRC errors are not really the issue.  It is the
> singular case of a TCP cksum failing to detect what a
> CRC succeeds in detecting, and this occurring to a TCP
> segment containing an iSCSI hdr with a StatSN.
> 
> Is there a reason to believe that iSCSI StatSNs will be
> lost at a higher rate than is currently documented for TCP
> cksum failure?  Or, is the problem a loss of one TCP segment
> in tens (possibly hundreds) of millions of segments.  Where
> the bad segment may contain a StatSN but probably doesn't
> because it is a data pdu.  If the latter, why does a SCSI-level
> timeout and retry (on the initiator) not suffice?  [Note,
> an initiator timeout/retry does not require a connection
> to be closed.]
> 
> I realize that I am being annoyingly repetitious, but it is
> not an idle question.  For some targets, retained rsp status
> is not cheap (and retained rsp data is not tractable at all).
> 
> IMO there appears to be no real need for SNACK.  And, more
> radically, there appears to be no need for StatSNs.

Jon,

The SACK mechanism exists because of StatSN [and holes that can arise in
StatSN]. 

Removal of StatSN allows the removal of SACK mechanism as well. The
reason SACK was introduced can be traced in the thread :
http://ips.pdl.cs.cmu.edu/mail/msg03257.html

The request originally made was to have a SACK (not a SNACK) for StatSN.
i.e. allow individual StatSN that were received to be acknowledged when
holes occurs in StatSN sequence. 

The solution provided in 05 was the Status SACK [or SNACK] which was a
variant of the request made. i.e. the SNACK is a request to re-send the
Status PDU that was dropped, instead of selectively ack'ing the received
Status PDUs and allowing timeout recovery of the dropped Status PDU.

If the rate of TCP checksum escapes is low enough to consider such
errors relatively infrequent [with the probability of affecting a Status
PDU even lower] ,then, both StatSN and S[N]ACK mechanisms are overkill
and should be removed, in an attempt to keep the protocol simple and
free of un-used features.

> 
> Maybe, as Somesh said, this is a dead horse but why include
> something in the spec which suggests a need for target-side
> complexity, while not solving a clear and compelling
> requirement?

Agreed. Both StatSN and SACK are overkill and should be considered for
removal. There is no need to add complexity to targets to retain I/O
state information in anticpation of a SACK. 

- Santosh Rao

> 
> -Jon
> 
> julian_satran@il.ibm.com writes:
> >
> >SNACK is here for two reasons - Status retry (which is cheap) and Data
> >retry as a side benefit.
> >CRC errors are not that rare (although we don't have real data the
> >simulation with file systems seem to indicate that numbers could be as high
> >a 0.0002%). A restart of link - is expensive (slow start) and even if they
> >are far lower for many applications a slow start is a painfull event.
> >
> >Removing them from the spec is not a path we should take lightly.
> >
> >Julo
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