RE: ISCSI: Urgent Flag requirement violates TCP.

[Black_David@emc.com]

> >  So, it's ok
> > to parse/frame/etc. the data to set it up for execution
> > of the SCSI command, but DON'T DO ANYTHING until TCP
> > has "delivered" the command and all the data prior to
> > it by sending or being prepared to send the appropriate
> > ACKs.
> 
> This I disagree with.  If a tightly coupled TCP/iSCSI stack where able to
regain
> framing after a lost TCP segment, it is perfectly OK for iSCSI to process
the
> iSCSI messages and deliver them to the SCSI layer (with the exception that
> commands must always be delivered in order), even before the lost segments
> arrive.  This works perfectly well in Fibre Channel today.

Fibre Channel is a bad analogy in this regard because Fibre Channel does not
in general have the ordered delivery requirement that TCP does.  If a frame
(say
frame N) goes missing in Fibre Channel, it's usually the case that
subsequent
frames (i.e., N+1, etc.) can be delivered to the ULP (e.g., SCSI) and
processed.
In this case, it's the responsibility of the ULP to figure out what
happened, including
doing any retransmits.  In contrast, if a TCP segment goes missing,
subsequent
segments can be buffered at the receiver (and ACKed if SACK is being used),
but MUST NOT be delivered to the ULP (e.g., iSCSI or SCSI).  TCP takes
responsibility for sorting out what happened, doing the retransmits, and
hiding
the fact that things went wrong (aside from the fact that they took longer)
from
the ULP.  This is fundamentally different from Fibre Channel.

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

From a SCSI standpoint this is correct, but from a TCP standpoint it is
wrong.
For example, if command B is an iSCSI ping, and SACK is not in use, this is
exactly the disaster of returning SCSI status for a command for which
delivery
of the CDB has not been ACKed by TCP.  Note that SCSI is allowed to complete
command B (e.g., an iSCSI ping) before command A (e.g., A write with R2T
used
for data), but the presentation of commands to SCSI/iSCSI MUST respect TCP's
in-order delivery requirements (e.g., at the point where status from B comes
back,
it had better be the case that TCP has ACKed delivery of A's CDB, but I
still think
the requirement is better described in terms of initiation of command
execution
at the target). 

I have to agree with Doug on the higher level point here -- if one wants a
message
oriented transport in which the messages can be delivered out of order on a
single connection, that's not TCP, and something like SCTP will need to be
used.

Also ... given Matt's recent note that the use of Urgent is not applicable
to all implementations of iSCSI, it appears to me that the use of "MUST" to
describe this requirement in the draft is incorrect and needs to be changed.

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