|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Status summary on multiple connections
A very crisp clarification. I would like only to point out that speed,
latency and the out of
order delivery by switches are aggravating factors and most DMA schemes
attempt only to find a "good home" for the out-of-order arrivals in order
not
to increase excessively the memory needs of the adapters or of the stack
buffers.
Nothing is presumed to be delivered from TCP to iSCSI for handling (i.e.
processing)
out-of-order in the TCP sense.
Julo
Black_David@emc.com on 02/10/2000 18:35:00
Please respond to Black_David@emc.com
To: ycheng@advansys.com, mark.carlson@sun.com,
randall@stewart.chicago.il.us
cc: David.Robinson@EBay.Sun.COM, ips@ece.cmu.edu (bcc: Julian
Satran/Haifa/IBM)
Subject: RE: Status summary on multiple connections
> 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
---------------------------------------------------
Home Last updated: Tue Sep 04 01:06:55 2001 6315 messages in chronological order |