RE: iSCSI Reqts: In-Order Delivery

[Black_David@emc.com]

Doug,

Attempting a fast exit ... I agree with the interpretation
of SAM insofar as SCSI responses are concerned - the
description of ABORT TASK in SAM (6.1) is clear that a
SCSI response to an aborted task must not be delivered to
an initiator after the FUNCTION COMPLETE from the ABORT
TASK that aborted it is, and similarly for both ABORT
TASK SET and CLEAR TASK SET.

Since this requirement is contained in the
existing requirement to adhere to SAM, we don't need
any additional text in the iSCSI requirements draft,
right ;-) ?

???,
--David

> -----Original Message-----
> From:	Douglas Otis [SMTP:dotis@sanlight.net]
> Sent:	Friday, April 20, 2001 7:50 PM
> To:	Black_David@emc.com; ips@ece.cmu.edu
> Subject:	RE: iSCSI Reqts: In-Order Delivery
> 
> 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
> 
> 
> > 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
> >