Re: ISCSI: Urgent Flag requirement violates TCP.

[Matt Wakeley <matt_wakeley@agilent.com>]

"Merhar, Milan" wrote:

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

I disagree. Please explain why.

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

We already have that - optional multiple TCP connections per session.


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