RE: A Transport Protocol Without ACK

["Douglas Otis" <dotis@sanlight.net>]

Cheng,

The feature you desire is out of sequence data processing.  As far as SCSI
is concerned, either the request is completed with read data or a write
response and has nothing to do with return of ACKs except in the condition
where a sequence must be maintained.  The principle feature VI offered was
out of order delivery and SCSI typically also has this behavior.  TCP is a
constriction to this freedom and it represents a sizeable performance loss
with head of queue blocking.  To design a system that requires head of queue
blocking, recovery must process at twice a normal rate due to parked frames.
A pointer scheme as a TCP option to provide framing and out of sequence
processing opens the window of allowable sequences increasing susceptibility
to spoofing and muddles the state of the receiver.  A second pass of TCP is
not likely to produce the same frame boundaries and is ugly to handle.  What
happens when this pointer is wrong.

SCTP provides these features and removes the multiple independent
connections. SCSI protocol expects the target to be in control of the
exchange.  Allowing advanced sending in the form of a credit from the target
does not change SCSI protocol.  Creating check-conditions as a means of
control violates SCSI and will likely choke the applications.  Discarding
data is a waste of network bandwidth.  As it is intended to be the
aggregation of many logical devices, IP transport can not provide flow
control to each device.  You need an additional scheme.  In the case of FC,
the solicitations from the target seems like a small cost compared to the
present specification.

Doug


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Y
> P Cheng
> Sent: Monday, September 18, 2000 5:52 PM
> To: 'Ips@Ece. Cmu. Edu'
> 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.
>