RE: A Transport Protocol Without ACK

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

> From: Michael Krause [mailto:krause@cup.hp.com]
> Sent: Sunday, September 17, 2000 7:43 AM
> Any type of reliable service requires the data to be persistent until
> acknowledged.  It would be a poor implementation that chose to
> use adapter resources to perform this retransmission buffering.

No, the adapter does not buffer the data for recovery.  See my detailed
descriptions of SEND-REQUEST and RECEIVE-RESPONSE in another posting.  The
data for transmission and retransmission are directly from the application
software.  This is what SCSI adapters have been doing for many years.  This
is what iSCSI should do.  No resource is wasted in the adapter.

> Similarly, the initiator does not send data in TCP unless one has the
> window space which indicates the target can receive the data.  The
> reception of this data does not require excessive buffering either since
> one can use flow through DMA techniques to maintain balance.

You are talking about RTT from a target, right?  The flow through DMA in the
adapter is what I am talking about for not needing buffers.

> Many of the problems in this area are really implementation specific and
> with some thought, one can implement a thin device and high
> performance.  The issue is how to insure the windows / buffer
> resources are
> kept in balance at any distance without creating jitter.

I think it is more than implementation. Whenever there are queues, there
will be head-of-queue blocking that creates deadlock.  Creating asymmetric
queue is trying to remove the head-of-queue blocking.  When SCSI requests
and responses are treated like atomic transactions instead of multiple
PDU-reads and -writes in a transport protocol, it is easy to retry on the
same connection or retransmit on a different connection.  There is no need
for additional buffer space.  Many have said that after solving all the
transmission and congestion problems, eventually one comes back to something
similar to TCP/IP.  However, the SCSI protocol give us certain attributes
that we can have reliable delivery and reception without TCP/IP.  The FCP is
an example.  VI provides different QoS without using stream-oriented READ
and WRITE functions.  We can certainly have many VI connections in one
system.

Let me repeat, a fibre channel adapter today is capable of executing
hundreds or thousands SCSI-over-FC (FCP) requests without queuing and
resource allocation issues. When the FC is replaced by an IP network the
probability of retry becomes higher due to dropped packets. We just have to
make sure the transport protocol allows retransmission on the same
connection or a different connection.