RE: a vote for asymmetric connections in a session

[David Robinson <David.Robinson@EBay.Sun.COM>]

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

Having worked on NFS over UDP on high latency lossy links (old ARPAnet)
the allure of saving a transport level ACK by leveraging the
fact that the session layer is datagram-like is fatally flawed
in practice. Works great on a LAN, but when faced with packet
loss due to congestion the session layer is required to maintain
adaptive timers, track round trip times, and base retransmissions
primarily on timeouts. The dropped packet creates huge latency
bubbles while waiting for timeouts, overly aggressive retransmissions
further clog congestion, all of these problems are solveable but the
result looks remarkably like TCP.  In fact this is what we did do to
NFS over UDP, implementing the various algorithms found in TCP, albeit
poorly.  Today, most NFS clients speak TCP by default with a minor
penalty for local servers but a major win for distant servers.

iSCSI should only consider a reliable connection oriented or reliable
datagram transport protocol!  Ultimately you can't get away from a
transport level ACK without an overly complex session protocol.

	-David