Subject: RE: [rddp] Connection Startup

From: "Jim Pinkerton" <[email-masked]>
Date: Fri, 3 Oct 2003 14:48:30 -0700

> DAT quotation is a red hearing since it is just an API and not a
> protocol or an appication.
> 

My point exactly. But for probably the opposite reasons than you
intended 
:-)

> There is a requirement for current applications using existing RDMA
> transport technology
> to rely on the RDMA transport provided connection establishment.

I agree there as well - where "current applications using existing RDMA
transport technology" is a euphamism for porting InfiniBand apps to
iWARP.

The reason I bring this up so strongly is for *new* protocols, which are
designed to run on top of IWARP, and don't care about compatiblity with
InfiniBand, I see no need for this capability. It's far more optimal to
embed their config data in their existing configuration handshakes, and
not add a new round-trip handshake.

It's specifically because I do care about enabling "current applications
using existing RDMA transport technology" that I think this capability
should be supported - it's a technology to bridge existing apps to
iWARP. Oh, and it's also a technology that enables an existing API to
work as well...

Jim

> -----Original Message-----
> From: Kanevsky, Arkady [mailto:[email-masked]]
> Sent: Friday, October 03, 2003 2:05 PM
> To: Jim Pinkerton; Caitlin Bestler
> Cc: [email-masked]; David Black
> Subject: RE: [rddp] Connection Startup
> 
> > From: Jim Pinkerton [mailto:[email-masked]]
> > First, I agree that for DAT (which was defined for
> > InfiniBand, as well as older, proprietary MAC layer
> > encapsulations of RDMA) there is a need, at least as DAT is
> > currently defined.
> 
> There is a requirement for current applications using existing RDMA
> transport technology
> to rely on the RDMA transport provided connection establishment.
> Some applications can define their own protocol for connection
> establishment.
> SDP is an example of it.
> 
> DAT quotation is a red hearing since it is just an API and not a
> protocol or an appication.
> 
> Arkady
> 
> 
> Arkady Kanevsky                                email:
[email-masked]
> Network Appliance                              phone: 781-768-5395
> 375 Totten Pond Rd.                            Fax: 781-895-1195
> 3rd Floor                                      http: www.netapp.com
> Waltham, MA 02451-2010                         general phone:
> 781-768-5300
> 
> 

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 3 Oct 2003 17:33:45 -0500

> not add a new round-trip handshake.

That is a valid concern when adding an RDMA mode to an *existing*
protocol, such as iSCSI. And the number of *existing* protocols
that are LLP neutral is, well, pretty much zero.

Use of an RDMA negotiation message *after* other negotiations would
indeed be a wasteful additional round-trip. The intent is to support
applications that only need minimal simple parameters exchanges in
order to establish the session. When this topic has been discussed
in the DAT Collaborative, there has been little interest in engaging
in more complex session setup.

The only thing that *must* be negotiated before enabling RDMA is
the essential RDMA configuration (identifying any existing session,
RDMA read credits, maximum untagged message size, etc.) to the
extent that it is not pre-dictated as constants for that ULP.

The general conclusion I have seen application developers who
are working on an RDMA specific applications is that complex
detailed negotiations can be done *after* the connection is
established.

Now you can argue that they were merely thinking that way
because that is the only model that InfiniBand supported.
Or perhaps, that is the only model that InfiniBand
supported because it is a fine model that meets the
needs of ULP designers who are assuming RDMA capability.