Re: ISCSI: Why the use of the Urgent Pointer

["Dick Gahan" <Dick_Gahan@eur.3com.com>]

Matt Wakeley Wrote:-

>It sounds to me that you think my "TOE" requires the urgent pointer.  My "TOE",
>just like all other "TOE"s, does not require framing.

>It is the "iSCSI" engine sitting on top of the "TOE" that requires the framing.
>This is because in the storage world, received data is placed into
pre-allocated
>buffers that were supplied specifically for the I/O. iSCSI needs the framing in
>order to place the data where it belongs when it comes off the link, thus
avoiding
>buffering and copying.

I understand that the TOE function does not require the framing function but
your iSCSI needs the
framing function BECAUSE your TOE does not have much memory to buffer up streams
when
data is lost. (The reason for having framing is to reduce memory requirements on
the TOE).

Thus some other application - non iSCSI - using the TOE is using a TOE without
much memory.
That application has no explicit framing information - hence if its TCP
connection loses a segment
the application cannot process succeeding segments until the missing one is
found. All the data between
the missing segment and the end of the window, or until the resend happens
should ideally be buffered.
Your TOE with very little memory on board, cannot buffer much - so follow on
segments  might be thrown away.
This is because you have designed a TOE function with small amount of memory to
service an
application like iSCSI which can use out of order TCP segments. Most
applications cannot.

Thus I think the TOE designed like you suggest is not a general purpose TOE
function and may not be
suitable for efficient movement of data on networks where there is some loss and
apps with big windows
 which rely on in sequence delivery. One lost segment would result in many lost
segments.


On another point
You present  your arguments based on having 1Gps connection dedicated to an
iSCSI session over
one TCP connection (effectively). This implies a large window and if one segment
is lost then a large buffer
on the TOE adapter may be required. To use gigabit effectively this is not
always required.
If you have 10 TCP connections in the session then each connection could have
0.1 the window
of the dedicated solution. If 1 segment is lost you only have to buffer up
1/10th of the data since
the other 9 connections should still work satisfactorily.

Now  I admit I could have missed something here, especially if an initiator is
talking with a single target. However if an
initiator is talking to 10 seperate targets then the above should be ok. The
Gigabit line gets used and
the buffering can be kept smaller (even on higher delay links) and nothing gets
thrown away when a segment is lost.

Another case is if you design your TOE adapter to work only in a LAN
environment. Short delay means a small
window size can keep the Gps line saturated for 1 TCP connection. If a customer
wants to buy more memory to make
the TOE work better in a high speed WAN environment thats there choice. And this
may be the Gps adaptor used
to backup storage to a remote site for disaster recovery. But all adaptors do
not need this much memory (whatever
it is).

So I'm still not convinced that your solution is a thing good overall.

Dick Gahan
3Com



PLANET PROJECT will connect millions of people worldwide through the combined
technology of 3Com and the Internet. Find out more and register now at
http://www.planetproject.com