RE: ISCSI: Urgent Flag requirement violates TCP.

["Merhar, Milan" <mmerhar@pirus.com>]

Forgive my wasting bandwidth, but I have to chime in 
with my agreement with David on this one.

iSCSI can NOT peek at command B, or in fact admit in any 
way that B exists, until TCP finishes delivering A to it.
If you want to be able to process commands independently 
in this way, I believe you're going to have to have multiple 
TCP pipes to deliver them independently as well. 
(And _that_ is yet another long discussion....)

Yes, everyone is itching to smoosh iSCSI and TCP into one 
big ball of embedded logic for performance reasons, but such 
an implementation MUST NOT do anything that modifies its 
externally-visible protocol behavior from that of an 
iSCSI application running on top of a conventional TCP/IP stack.
Otherwise, we set ourselves up for an interoperability nightmare,
which will surely drive this WG's efforts off into the weeds.

- milan

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, November 08, 2000 9:27 AM
> To: matt_wakeley@agilent.com; Black_David@emc.com; ips@ece.cmu.edu
> Cc: dotis@sanlight.net
> Subject: RE: ISCSI: Urgent Flag requirement violates TCP.
> 
> 
> > >  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

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