RE: Why FCP doesn't need RDMA? It has a better way.

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

Matt,

The TCP specification does not end at protocol structures.  You should not
expect it is okay to go about redefining use of pointers, bits, data
placement, buffer use and expect the API to accommodate changes.  TCP is not
suitable for SCSI and you appear to know this.

End schemes to fix TCP; address the issues of TCP and SCTP.  Do not stand on
desires for TCP over SCTP or that a pact was made to promote TCP.  SCTP
performance will be superior to TCP using either hardware or software.  SCTP
is easier to accelerate in hardware than TCP and any resulting SCSI standard
will change substantially as a result of the features of SCTP.  Even if
there was a generic RDMA option, SCSI would look more like Firewire as a
result.  A debased version of RDMA has already been offered that avoids
stepping on accepted options.

To talk seriously about your concerns, SCTP is a legitimate aspect of this
topic.  Your false notion makes TCP even less sacrosanct.

Doug



> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Matt Wakeley
> Sent: Friday, September 29, 2000 8:08 AM
> To: IPS Reflector
> Subject: Re: Why FCP doesn't need RDMA? It has a better way.
>
>
> "Randall R. Stewart" wrote:
>
> > "GUPTA,SOMESH (HP-Cupertino,ex1)" wrote:
> > >
> > > Even iSCSI does not really need RDMA. The underlying note in
> > > the whole debate is really the preservation of message boundaries.
> > >
> > > If we could use one of the reserved bits in the TCP header to say,
> > > do the repacketize or adjust segment boundaries, and each TCP
> > > segment starts with an iSCSI header, there should be no need for
> > > another protocol (or TCP option header).
> > >
> >
> > I don't think you can go playing with TCP option bits. This implies
> > changing TCP and I don't see this in the WG charter. If bits need
> > to be changed then a draft needs to be written and submited to
> > the proper WG.. in this case I would say transport area WG...
>
> I agree.  There is no need to use new option bits.  Please read my
> draft
> http://www.ietf.org/internet-drafts/draft-wakeley-iscsi-msgbndry-00.txt
>
> It describes a proposal to discover message boundaries using the existing
> TCP mechanisms (the urgent pointer).
>
> >
> >
> > I think in some respects this is exactly what Costa has done... Now
> > as far as message boundary preservation, you get this for free
> > with SCTP.. and has Douglas as already pointed out, you could very
> > easily implement in SCTP the ability to copy a specific stream
> > into receive buffers .. i.e. tell the sender, but the data on
> > stream X and then as it arrives dump it directly to user buffers.
>
> Randall, please stop telling us all about the fabulous features
> of SCTP.  We
> are all sick to death of hearing about SCTP.
>
> -Matt
>
> >
> >
> > This would take a bit of work, but so does the RDMA solution :/
> >
> > R
> >
> > > The iSCSI header contains enough information in it to enable
> > > the recepient to determine where to put the data.
> > >
> > > Somesh
> > >
> > > -----Original Message-----
> > > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > > Sent: Thursday, September 28, 2000 8:29 AM
> > > To: 'Matt Wakeley'; IPS Reflector
> > > Subject: RE:Why FCP doesn't need RDMA? It has a better way.
> > >
> > > >  I object to mandating iSCSI use an RDMA option because:
> > > >
> > > >  - (main reason) there isn't any standardized mechanism now, and I
> > > >    don't want to hold up iSCSI while one crawls through the
> > > >  standards process.
> > > >
> > > >  - I don't think RDMA is needed.  FCP doesn't use it, and it
> > > >  works great with
> > > >  the
> > > >    FC protocol chips that "accelerate" FCP.
> > >
> > > Actually, RDMA is not needed in FCP because all protocol chips
> > > implemented perform a real peer-to-peer DMA straight to the
> > > data areas specified by the user's interaction with the operating
> > > systems allocation algorithms.  The combination of the FCP/SCSI
> > > pointer structure, task tagging, and the FC relative offset
> perform the
> > > function you would otherwise have to use RDMA to accomplish.
> > >
> > > Bob Snively
> > > Brocade Communications           Phone  408 487 8135
> > > 1745 Technology Drive
> > > San Jose, CA 95110               Email   rsnively@brocade.com
> >
> > --
> > Randall R. Stewart
> > randall@stewart.chicago.il.us or rrs@cisco.com
> > 815-342-5222 (cell) 815-477-2127 (work)
>