Re: iSCSI Reqts: In-Order Delivery

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

Charles Monia wrote:

> > (1) MUST provide ordered delivery of SCSI commands from
> >       the initiator to the target in the absence of transport
> >       errors visible to iSCSI (e.g., iSCSI CRC failure,
> >       unexpected TCP connection closure).
> 
> Does the term "SCSI commands" include task management functions as well?  If
> not, it should.


Charles,

Could iSCSI use a variant of the approach FCP-2 takes to solve the
ordering issue for task mgmt error recovery ?

The FCP-2 task management error recovery scheme is :
- task mgmt function uses CRN 0
- task mgmt function is executed immediately with no ordering latencies
- both initiator & target clear all resources that can be cleared
un-ambiguously.
- any ambiguous exchanges shall be aborted by the port that detects the
ambiguous state.

In the case of iSCSI, an analogous approach could be :
- task mgmt function uses immediate delivery flag for the task mgmt PDU.
- task mgmt fn executed immediately avoiding any ordering latencies.
- initiator & target clear all resources that can be cleared
un-ambiguously.
- initiator uses Abort Task to explicitly abort all active outstanding
I/Os at the time the task mgmt fn was issued to avoid any ambiguous
stale PDUs of an exchange from appearing at the target. 

Such an approach would avoid latencies on the execution of the task mgmt
fn while still flushing out all the stale PDUs upon completion of the
initiator actions for that task mgmt fn.

Regards,
Santosh



> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Friday, April 20, 2001 7:11 AM
> > To: ips@ece.cmu.edu
> > Subject: iSCSI Reqts: In-Order Delivery
> >
> >
> > About a week ago, Santosh Rao wrote:
> >
> > > I object to the following requirement :
> > >
> > > " MUST support ordered delivery of SCSI commands from the
> > initiator to
> > > the  target, to support SCSI Task Queuing. "
> >
> > In the hopes of driving this discussion to closure,
> > let me summarize my understanding of this situation:
> >
> > - SAM2 expects ordered delivery, but does not mandate
> >       it.  Section 4.6.2 of SAM2r16 says:
> >
> >   For convenience, the SCSI architecture model assumes
> > in-order delivery
> >   to be a property of the service delivery subsystem. This
> > assumption is
> >   made to simplify the description of behavior and does not
> > constitute a
> >   requirement.
> >
> >       I will observe that there is well-known code for disk
> >       initiators (e.g., staircase/elevator/etc. command queue
> >       reordering for seek optimization) that relies on this
> >       expectation for performance (not correctness).  IMHO,
> >       making in-order delivery purely OPTIONAL would not be
> >       consistent with the spirit/intent of the above SAM2 text.
> >
> > - In existing SCSI transports, transport errors (e.g., CRC failure)
> >       can cause ordering issues at higher levels.  Both Parallel SCSI
> >       and Fibre Channel initially drop anything that has a transport
> >       error.  IF the higher level code retries AND other commands were
> >       executed before the error was noticed by the retry logic, THEN
> >       the retry occurs in a different place in the command sequence
> >       from the original command.  I believe that existing tape
> >       implementations usually either don't retry, or spoon-feed the
> >       tape one command at the time to make sure no other command can
> >       get in the way.  FCP-2 has the ability to prevent other commands
> >       from being executed ...
> >
> > - iSCSI has to face this issue because we're incorporating a retry
> >       mechanism into the base protocol.  Parallel SCSI and FCP-1 could
> >       ignore this because they didn't do retries.  FCP-2 has a retry
> >       mechanism, but makes order preservation of retries negotiable -
> >       order of command delivery in the face of retries is only assured
> >       if CRN is in use, and that is controlled by a settable bit in a
> >       mode page (FCP2r7, 4.3).  The Initiator can choose not to set
> >       this bit, and the Target can refuse to allow the
> > Initiator to set
> >       it.
> >
> > - CRN is a relatively new mechanism, and both it and the associated
> >       FCP-2 retry mechanism are likely to be implemented for/used by
> >       tapes.  Disks will still have an expectation of
> > in-order delivery
> >       in some cases, even though neither of these mechanisms
> > are in use.
> >       IMHO, Santosh's proposal to use CRN for all
> > expectations/requirements
> >       of ordering doesn't seem like a good idea for this reason.
> >
> > So, let me try the following proposal to resolve this issue/objection:
> >
> > (1) MUST provide ordered delivery of SCSI commands from
> >       the initiator to the target in the absence of transport
> >       errors visible to iSCSI (e.g., iSCSI CRC failure,
> >       unexpected TCP connection closure).
> > (2) MUST specify the ability to preserve ordered delivery
> >       of SCSI commands even in the presence of transport
> >       errors.  A mechanism MUST be provided to allow
> >       Initiators and Targets to negotiate this preservation
> >       on a per-session or finer granularity basis,
> >
> > The Rationale for (1) is the combination of the SAM2 expectation
> > plus the fact that there are situations in which disks expect
> > this ordering in the absence of mechanisms like CRN that can
> > enforce it.  The Rationale for (2) is to provide support
> > analogous to FCP-2 - this should be sufficient for tapes to
> > obtain the behavior they require.
> >
> > Comments?
> >
> > Thanks,
> > --David
> >
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> >
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