RE: ISCSI: Urgent Flag requirement violates TCP.

[Black_David@emc.com]

Let me see if I can put a fast end to the ordering discussion.  Matt
originally
wrote: 

> > For example, if the following iSCSI messages are sent:
> >
> > Command A sent to target  ->
> > Command B sent to target  ->
> > <- target sends data/status for command A
> > <- target sends data/status for command B
> >
> > If the TCP segment containing the data/status for A was lost, but
framing was
> > regained to receive the data/status for B, there is nothing wrong with
> > completing command B even though a message for command A was lost and
> > needs retransmitting.  Indeed, the initiator SCSI layer would not know
the
> > difference than if the disk drive completed command B first instead of
A.

And Matt subsequently wrote:

>  iSCSI already specifies that SCSI commands are to be
> delivered to SCSI in the same order they were presented to iSCSI (and it
> achieves this by useing the Command reference numbers).  Therefore, there
should
> be no requirements on the "orderness" on the SCSI/iSCSI interface based on
what
> the lower level transport is.

That's part of the solution, but may not be the entire story.  The easiest
scenario to
understand is the transmission of commands to the target.  If the command
for
A is dropped, having the target complete B and send the response before A
is retransmitted is clearly wrong because command A was supposed to be
presented to the target first, so this has to be disallowed.  For
data/status, the
situation is less obvious, but still a potential problem.  Suppose command B
aborts
command A; if A's data/status is dropped and retransmitted, and B's
data/status
is presented to SCSI on arrival, the completion of A arrives after an abort
of A
has failed because there was nothing to abort at the target (A was complete
at the target when B arrived to abort it).  This seems peculiar to say the
least, and I can easily envision software/firmware getting confused by it.  
FWIW, this can't happen in Fibre Channel because the completion of A won't
be
retransmitted.  If this is going to be allowed, it and related peculiarities
need to
be carefully documented, and I suspect that there are some existing OS
implementations of SCSI that will get indigestion as a result.  I'm not sure
that
this is a good idea.

The issue of whether the Urgent feature should be a "MUST", "SHOULD", or
"MAY" will
need to be determined by the WG.  My concern about the use of MUST in this
instance
is based on the following text from Section 6 of RFC 2119 (which defines
MUST):

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmissions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

It is not clear to me that the Urgent feature is "required for
interoperation or to limit behavior
which has potential for causing harm".  I'm prepared to be convinced
otherwise, and would like
to hear from implementers other than Matt on this subject, and specifically
comments on
his statement that:

	... high speed implementations will require framing in order
	to prevent a massive amount of buffer resources to "buffer up" TCP
segments that
	arrive after a dropped TCP segment.

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
---------------------------------------------------