RE: A Transport Protocol Without ACK

[julian_satran@il.ibm.com]

Dear Mr. Cheng,

I am baffled by your taxonomy. VI and I2O are basically interface (API)
definitions and
each of them has a different purpose. VI was ment to be a
User-Space-to-User-Space
communication interface and I2O well... a panacea for drivers.

We are trying to build a protocol (to which an API is assumed but not
mandated).

Could you be a bit more specific in what you criticize or propose?

Julo

"Y P Cheng" <ycheng@advansys.com> on 19/09/2000 03:52:10

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

To:   "'Ips@Ece. Cmu. Edu'" <ips@ece.cmu.edu>
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  RE: A Transport Protocol Without ACK




From: randall@stewart.chicago.il.us
> I see no viable transport protocol here and I don't see this
> conversation of any use unless you get exact details AND point
> to a internet draft that defines EXACTLY how it works (or possibly
> some other standards document).

Both I2O and VI are transport protocols which define the format of a
request
to a transport service provider, i.e. an adapter card.  I2O is used but not
limited to deliver SCSI requests and VI is used for any payload including
IP
packets.  VI is mapped into FC with the device headers between the FC
header
and data payload.  VI can certainly be used for delivery of SCSI requests
too.  Both protocols require the service provider to have reliable delivery
and reception.  VI defines different QoS.

> > I don't claim any credit about this transport layer protocol. Every
fibre
> > channel and Infiniband adapter designer knows about this protocol --
> > although there is no standard.  I am sure the TCP accelerator card is
doing
> > the same.  This protocol is a great alternative to the use of TCP/IP
and
> > should be incorporated into iSCSI.
>
> No it is not. You are not offering an alternative yet..

I did not imply iSCSI should use I2O or VI.  In fact, the purpose iSCSI is
to map SCSI requests into IP packets as well as to define the delivery .
It
seems to me that the working group has set its mind on TCP/IP and is
believing this is the only solution.  The consensus seems if there is any
other solutions that address flow control and congestion, it would end up
like TCP/IP.  I am simply pointing out if we keep an iSCSI request as a
single atomic transaction without separating it into the
TCP/IP-stream-oriented Writes and Reads that each deals with a single DU,
then, the deadlock problem goes away.  While the work group thinks we
should
take advantage the flow control and congestion management of TCP/IP, there
are alternatives known as BB-credit and EE-credit management.  The fibre
channel adapters make reliable delivery, lost packet detection, and
retransmission without TCP/IP.

Randall, you are right, I did not spent time to provide the working group a
draft defining such transaction-oriented protocol.  All I have provided is
an idea that besides TCP/IP.  The designers for SCSI and fibre channel
adapters have solved the head-of-queue blocking, the congestion, and
retransmission problems.  The transaction-oriented WRITE-REQUEST and
READ-RESPONSE, in my humble opinion, allows us to implement iSCSI simpler
than that of WRITE and READ stream requests.  The performance cost of
requiring ACKs on every DU with size greater than MTU on a network with
long
latency is very expensive..  By defining a greater ACK granularity is an
attempt to solve this performance problem.  If we do wish to ACK on every
DU, then, on a long latency network, we must have a method to stream the
PDUs to ensure the performance.  The method should not consume a large
amount of memory space.  One should never ignore the TCP/IP
memory-to-memory
copy overhead when the backbone will be running at OC-192 speed in the near
future.  Finally, please don't ever ask two NIC cards to synchronize with
each other.  It is really hard to do as those of us in business of
designing
NIC cards can testify.

Y.P. Cheng, CTO, ConnectCom Solutions Corp.