RE: Status summary on multiple connections

[Black_David@emc.com]

> Both of you forget about the case when multiple PDUs are inflight, say N,
> N+1, and N+2, and one of them has CRC error, say N+1.  The receiver throws
> away N+1 because the bad CRC.  N+2 is received long before N+1 is
> retransmitted after a timeout by the sender.  Of course, a sequence number
> inside the PDU will ensure sequentially.  However, as I stated in another
> posting, all software realize such problem and will not count on
sequential
> delivery by a transport.

Let me try to head off some confusion here.  PDU is a dangerous acronym
because it could refer to layer 2 (e.g. Ethernet) packets, layer 4 TCP
segments
or iSCSI information units at layer 5.  For this discussion, layers 2 and/or
4
are the intended context.  If packet/segment N+1 has an (e.g., Ethernet) CRC
error, TCP has to buffer N+2 and can't deliver it to the application.  The
concern that's behind discussions of things like RDMA and the Urgent
pointer is in the details of how to buffer N+2.  If the N+1/N+2 boundary is
not at
the start of an iSCSI PDU, N+2 gets tossed into some memory somewhere
and copied out when N+1 arrives and it's possible to resume processing
of the stream at the iSCSI level; this can be slow.  One of the goals
of the RDMA and Urgent discussion is to identify the iSCSI boundary in the
TCP data, either by forcing the boundary to the TCP N+1/N+2 boundary or
providing a pointer to where it is inside N+2 so that all or most of N+2 can
go through iSCSI processing on receipt and hit the right place in memory
the first time.  Handing a SCSI command found in N+2 to the SCSI device
before getting the N+1 data is prone to cause a variety of peculiarities.
For example, if the command in N+2 is a task abort of a command
in N+1, the Initiator is going to be rather surprised when the abort fails
and the
task that was supposed to be aborted executes after the failed abort (which
may be observable via a different iSCSI session).  There are doubtless cases
in which this can be done safely, but they'll need some careful
investigation.

David Robinson's contention that the WG shouldn't spend time on optimizing
cases in which packets are lost because they're not going to happen often
enough
for optimizations to make a significant difference is an open issue that the
WG
will need to come to a conclusion on.

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