Re: iSCSI:flow control, acknowledgement, and a deterministic recovery

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

Douglas Otis wrote:
> 
> With multiple connections, if you are not going to use a valid CmdSN, or in
> your case a null CmdSN for all commands, then there would be a need to
> include a timestamp to meet a timely delivery requirement in the same manner
> as used in FC encapsulation.  IP can deliver over any time period.  A
> command could arrive at any time with respect to other connections.  With
> all of your feedback now from just the SCSI layer, the SCSI layer is likely
> to have timed out and restarted and now stray commands finally make an
> appearance (the technician re-inserted the cable).  What did that do?  Yes,
> if this were on a single connection, then TCP could provide some assurances,
> (ignoring digests errors) but you must not make that assumption nor can you
> assume all disruptions are symmetric.

Doug,

The below snippet from my last mail answered your above concern. The
Abort Task is sent on the same connection as the command. (connection
allegiance applied to the abort task as well). The Abort task pushes the
stale data PDUs. There is no need for a timestamp on iSCSI PDUs.

> > As for your second concern regarding I/O timeouts, there is no need for
> > any timestamp. An I/O timeout is dealt with by an Abort Task. The abort
> > task response guarantees that the abort reached the target and pushed
> > all intermediate stale frames. Failure to complete Abort Task leads to
> > higher level error recovery (ex : Logout, or some higher form of task
> > mgmt).

- 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