RE: A Transport Protocol Without ACK

["Y P Cheng" <[e-mail]>]

David Black wrote:
> < From: Y.P. Cheng>
> > The main difference between my view and that of ips discussions is the
> > semantics on creating and interpreting the iSCSI headers.  The working
> > group assumes the iSCSI in using TCP/IP will need several system calls:
> > write command, read/write data, and read status. Hence, iSCSI will have
the
> > problem of interlocking.  The working group tries to solve the problem
> > with asymmetric and symmetric models.  However, if the group assumes a
> > single system call to send an iSCSI request, we can let the transport
layer
> > break up iSCSI requests into PDUs of command, data, and status.  The
> > asymmetricmodel is no longer needed.
> I think "system calls" is the wrong word.  The whole point of
> sessions is to take advantage of network fabric parallelism,
> i.e., use two or more NICs on initiator and target.
> This requires the transport layer to figure out which PDU
> to send on which NIC (i.e., which TCP connection) independent of what's
> implemented in hardware or software, and entails logic on the far side to
> put things back in order.  This logic could be in iSCSI or a
> transport like SCTP.
> <snip>
> Because reliable delivery isn't enough.  Congestion control is also
> required.  TCP does congestion control in a fashion that no existing
> SCSI transport or mechanism does.  It's not the only solution, but it
> or an equivalent congestion control solution is REQUIRED.  Please read
>
> http://www.ietf.org/internet-drafts/draft-floyd-cong-04.txt
>

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.  However, I do
have concerns if iSCSI requires the ACK to achieve reliable delivery.  Let
me use the following example to illustrate my concern.

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.

We could take a lesson from the fibre channel FCP using class-3 datagram.
The SCSI protocol is inherited acknowledged by the returning of status PDU.
If an ACK to datagrams is not necessary, then the 2MB buffer requirement in
the above example can be reduced to less than 100KB to accommodate the speed
variation of the host system bus and the connecting media.  By the way,
multiple paths does not solve this problem.  The problem of lost PDU's due
to traffic jam or congested system bus are also still there. However, the
congestion and retransmission problem has already been solved in the
implementation of a fibre channel adapter.  TCP/IP is not the only protocol
providing a solution.

I guess my point is that the iSCSI should allow a transport protocol that
does not require ACK.  (My apology for mentioning UDP in my previous
postings.)  If iSCSI is not limiting itself to TCP/IP, then, the asymmetric
model is also a non-issue for people who design a smart NIC adapter.