RE: a vote for asymmetric connections in a session

["Y P Cheng" <ycheng@advansys.com>]

Julo wrote:
>I hove some trouble with your note as it contains many items
>some that where repeatedly discussed and already agreed upon,
>some with smaller or larger misunderstandings (like the duplex
>issue - the links are in fact used in duplex mode <snip> ...

Being a late comer into this discussion, I do apologize for repeating some
subjects that were already been agreed before.  However, I do have problems
with the iSCSI over TCP -- see my reply to the TCP speed thread -- and the
sliding window, alternate path retry, wedge driver, and load balance issues.
I don't understand the deadlock issue when a iSCSI adapter can accept
hundreds and even thousands SCSI requests and execute them atomically.  Let
me explain this.

An iSCSI NIC adapter accepts a SCSI request and builds a table entry in its
internal memory describing the SCSI session.  It sends the request datagram
to a target.  When a response comes back in the form of datagrams, the
adapter refers back to the table entry and quickly moves the datagrams to
the application software.  There is no possibility of deadlock and there are
hundreds or thousands of the table entries in the adapter's local memory --
limited by the local memory size, of course.  A target iSCSI NIC adapter
waits for incoming requests after the application software has already been
in "listening" mode. Like its initiator counterpart, referring to the table
entries, the incoming datagrams can be moved to the application without
delay.  Of course, an NIC adapter can be both initiator and target.

I am not familiar with the context of previous discussions which require TCP
and sliding window to support iSCSI.  With regard to the full-duplex
transmission, while a target can piggy back the acknowledge in its
datagrams, there is no SCSI command starting data transfers in both
directions today.  Although we could add such commands in the future, in
general the need for acknowledge on transport with long latency on the net
is bad.  As I said, the SCSI status gives the ultimate acknowledge anyway.
I don't know if we need to define iSCSI in such a manner that it would
require a very complicated driver implementation to work with legacy
Ethernet adapters.

If the new information introduced creates confusion, I do apologize.

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
julian_satran@il.ibm.com
Sent: Monday, September 11, 2000 6:42 AM
To: ips@ece.cmu.edu
Subject: RE: a vote for asymmetric connections in a session

Dear Mr. Cheng,

I hove some trouble with your note as it contains many items some that
where
repeatedly discussed and already agreed upon, some with smaller or larger
misunderstandings (like the duplex issue - the links are in fact used in
duplex mode
even for iSCSI as R2T and data can flow on the same links and outbound and
inbound data can be used simultaneously with different commands, deadlocks
are not
caused by execution speed - or lack of,  a NT miniport serves a port driver
which in turns serves a class driver, UDP is not more efficient than TCP -
although is has a better matching datagram model it lacks reliable delivery
and congestion control, etc.).

I will try to summarize your subject line position for my (and our list
records) - and please correct if I am wrong:

- you are against the asymmetric model as it requires more work to execute
a SCSI
command than the symmetric model.

Regards,
Julo

"Y P Cheng" <ycheng@advansys.com> on 11/09/2000 02:13:02

Please respond to "Y P Cheng" <ycheng@advansys.com>

To:   John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL,
      black_david@emc.com
cc:   ips@ece.cmu.edu
Subject:  RE: a vote for asymmetric connections in a session