RE: A Transport Protocol Without ACK

[Michael Krause <krause@cup.hp.com>]

>
>Thank you for pointing out that in addition to mapping a SCSI request to
>iSCSI PDU's, the working group is also addressing the delivery of PDU's to
>prevent deadlock when TCP/IP is used.  It is also assumed that TCP/IP
>provides the congestion and flow control. Whether I like it or not, the
>reality is that many iSCSI implementation will be TCP/IP.

It is a fact of business - there are many applications for hardware based 
TCP/IP implementations beyond iSCSI.

>Assume we wish to perform backup to a device 3000 miles away using iSCSI
>protocol.  It would take 10 milliseconds for an IP packet to travel from the
>source to destination.  Similarly, it takes another 10 milliseconds for the
>ACK to come back.  Lets also assume that the backbone is capable of 1
>gigabit per second throughput.  To keep data streaming on this connection,
>the source needs to send 2 megabytes of data before seeing the first ACK
>coming back.  Similarly, the target must be prepared to buffer 2 megabyte of
>data.  This example becomes much more interesting when we increase the
>backbone connection speed to that of OC-192 at 10 gigabits per second or if
>the backup devices are accepting incoming streams from multiple initiators.
>It needs a lot of memory.

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.

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.

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.

Mike