Re: A Transport Protocol Without ACK

[Randall Stewart <rrs@cisco.com>]

Jim McGrath wrote:

> Actually the burden of proof issues is why I suggest we look at some things
> that are actually being used today (since you don't have to guess how they
> behave).  That is one of TCP's great strengths, and a bit of a weakness for
> SCTP (no offense to SCTP supporters, but it certainly does not have a big
> and long "track record" yet, and so I can understand the concerns others may
> have as to whether things would work out as well in practice as they do in
> proposal).
>

Jim:

SCTP's congestion control comes right from RFC2581 and it is the same has
TCP. Now it is true you may get bad implemenations of congestion control
in SCTP... but this same fact holds true for TCP. There are good and bad
implemenations of TCP CC in the market... most of the bad have dwindled away
(hopefully).  My point is that IF the WG decides to go ahead with some
UDPish transport protocol and they DO NOT follow RFC2581 then there
is a extreme burden of proof on that transport protocol.

SCTP's behavior is known.. it is the same as TCP. Is all of the individual
implementations
behavior known... i.e. how folks implemented it? no, and neither do we know
all the behaviors of the TCP implemenation... the postive thing for TCP is that
MOST
of the implemenations now out there have been corrected ...

R



> Jim
>
> PS Personally, I'm a big believer is copying stuff that works, making the
> minimum amount of required changes, and then doing a rapid but controlled
> deployment (I've been involved in a lot of those sorts of things in ATA and
> SCSI).  Having been involved in both these sorts of endevors and the
> opposite (big, clean sheet of paper efforts, like 1394 (no offense to
> 1394/Firewire supporters, but I was working on it a decade ago)), I know how
> easy it is to underestimate the work required by the latter, and to be
> turned off by the "inelegance" of the former.  For me, life has become too
> short - I'm willing to accept inelegance as the price for speed of
> deployment.
>
> -----Original Message-----
> From: Randall Stewart [mailto:rrs@cisco.com]
> Sent: Tuesday, September 19, 2000 4:38 AM
> To: Jim McGrath
> Cc: 'Y P Cheng'; 'Ips@Ece. Cmu. Edu'
> Subject: Re: A Transport Protocol Without ACK
>
> 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.