Re: A Transport Protocol Without ACK

[Randall Stewart <rrs@cisco.com>]

Jim:

Any transport protocol proposal is ok. As long as it can be seen and
reviewed. So far I have seen only two TCP and SCTP.

Oh, a little side note, any transport protocol proposed MUST be able to
show TCP like behavior in the face of congestion. And I think, IMHO, that
this means  that if it is NOT using RFC2581 procedures it MUST show that
it does backoff and share with TCP. It also has a HEAVY burden of proof to
show this facility at least in my mind and I would think in the IESG's mind
as well...

R


Jim McGrath wrote:

> I would expand your search to include non standard protocols (i.e.
> proprietary ones) as well if they offered something and were adequately
> understood by the outside world.  We do that in storage quite a lot -
> indeed, some standard protocols are direct descendants of what were once
> proprietary protocols (e.g. ATA, the most widely used desktop disk
> interface, and ESCON, a dominant mainframe class interface (both of which
> originated from IBM proprietary technologies)).
>
> Jim
>
> -----Original Message-----
> From: Y P Cheng [mailto:ycheng@advansys.com]
> 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.