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

["GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@am.exch.hp.com>]

This was just to point to what the real underlying requirement
a number of people were expressing i.e. to preserve message
boundaries in TCP segments.

I will respond to the urgent pointer proposal on that thread.

Somesh

-----Original Message-----
From: Matt Wakeley [mailto:matt_wakeley@agilent.com]
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)