Subject: RE: iSCSI Reqts: In-Order Delivery

From: [email-masked]
Date: Fri, 20 Apr 2001 16:37:33 -0400

Focusing solely on the discussion needed to resolve the
(last call) issue in the requirements draft:

(A) Charles suggests that "ordered delivery of SCSI commands"
	should include task management commands.  That
	was the intent of the proposal and words should be
	added to make this clear.  Section 7.3 of the -06
	version of the main iSCSI document contains an
	initial version of a description of how task management
	commands can be executed immediately but have the
	effects they would have had if delivered in order.

(B) Doug is concerned that the task management response
	may arrive before the responses to one or more
	commands that were affected by the task management
	command.  While his technical concern is valid,
	and has/is being discussed, I don't think foreclosing
	that discussion by requiring session-wide
	synchronization of responses in the requirements
	document is the right thing to do.  Hence I would
	not change the proposal to require such synchronization.

Thanks,
--David

p.s. Here's the proposal and brief Rationale:

> > 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.
> 
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 20 Apr 2001 16:50:04 -0700

David,

I suggested one solution that has several benefits.  This one suggestion is
not the only option to resolve this issue.  Connection Allegiance does not
resolve state with respect to Management requests.  Off hand I can think of
several other options as these requests are clearly indicated.  How this
problem is resolved should be considered a separate issue, but there is this
requirement that should not be overlook.  My interpretation of SAM places
this obligation on the transport.

Doug