RE: iSCSI Reqts: In-Order Delivery

[Black_David@emc.com]

Doug,

At the moment, I'm trying to resolve the last call
issue around the requirements draft.  In what you've
written, I see an issue with the iSCSI specification
draft, but not a need for any change to the
requirements draft.

Thanks,
--David

> -----Original Message-----
> From:	Douglas Otis [SMTP:dotis@sanlight.net]
> Sent:	Friday, April 20, 2001 9:37 PM
> To:	Black_David@emc.com; ips@ece.cmu.edu
> Subject:	RE: iSCSI Reqts: In-Order Delivery
> 
> David,
> 
> iSCSI has presently made providing this impossible.  You can not make
> assumptions about relative delivery rates between connections.  This can
> and
> should be fixed.  As you know, I like my solution but there are many
> others.
> 
> Doug
> 
> 
> > 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
> > > >
> >