Re: ISCSI: Urgent Flag requirement violates TCP.

[Matt Wakeley <matt_wakeley@agilent.com>]

Black_David@emc.com wrote:

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

And that is already specified in the iSCSI standard that this is 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.

I think software has to deal with it anyway.  Let's use your scenario, except
take the case where nothing is dropped or re-ordered.  What's to say that the
disc drive has to complete A before it completes B (the abort)?  What if it just
immediately acknowledges the abort, then cleans up and sends the completion for
A?

This scenario you describe can also happen legitimately if more than one TCP
connection is used in a session.  Send command A down TCP connection #1 and send
command B down TCP connection #2.  iSCSI says that command A must be delivered
to SCSI before command B, and it does exactly that.  But when sending the
data/status back, even if SCSI completes command A before B, the TCP connections
themselves could deliver the data/status for B to the initiator before A.

>
> FWIW, this can't happen in Fibre Channel because the completion of A won't
> be retransmitted.

It won't be retransmitted, but it could get re-ordered in the FC traffic, so the
FC software/firmware also has to deal with it.

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

As I show above, I think they have to already deal with it anyway.

-Matt Wakeley
Agilent Technologies