[openib-general] Semantics of transport neutral connection establishment (was Re: [swg] Re: private data...)

[Caitlin Bestler]

I believe a review of what the implementer of a transport neutral
daemon for an RDMA protocol would be expecting from a Connection
Management service:

-- It expects that it can listen for connection requests on a specific
   16-bit port number (with traditional TCP port number semantics) on
   either a specific IP Address or for all IP Addresses associated with
   the network device.
-- It will receive connection requests that were initiated by active peers
   that wish to establish a reliable connection for the purpose of 
   exchanging RDMA messges.

   This Connection Request will identify:
	1) The remote IP Address of the active peer. This will be
authenticated
         in the sense that the address is known to have more meaning than 
         just being a value made up by a remote user-mode peer. If it is a
lie
         then privileged software is complicit in the lie. The address may be
         even more authenticated than that.
	2) The destination IP address that the active peer requested. That
is, if
         the network device supports multiple addresses concurrently (as with
a
         web farm) the connection request will identify *which* address was
         specified by the remote active peer.
	3) Private Data supplied by the remote peer to establish its
identity,
         the required characteristics of the desired connection and/or other
         application specific purposes. The private data is supplied prior to
	   connection establishment specifically to enable
selection/configuration
	   of the RDMA QP. Note that on a transport neutral basis the passive
side
	   application cannot assume that the QP is fully configured to match
credit
	   requirements of the remote peer -- it must configure QP capacities
itself.
-- It will NOT receive connection requests from remote peers seeking to
connect
   with similar services based upon streaming socket semantics (SDP or plain
TCP).

-- If it so chooses, it may accept the connection request by supplying a
compatibly
   configured RDMA QP and response private data.
-- If it so chooses, it may reject the conneciton request. 



Many of these requirements point to why the additional data is needed, and
why taking
the first N bytes of the existing private data is requried.

The key requirement that I belive requires that "65th bit" is that a client
seeking
a streaming mode daemon cannot initiate a connection with an RDMA mode daemon
and 
start mis-exchanging data.

If anyone cares to google you can find out that I had a low opinion of the
value
of this requirement when it was discussed in the IETF RDDP WG.  Well,
actually it
wasn't discussed, it was imposed by fiat by the Transport Area directors.

But despite my low opinion of it, it is part of IP based RDMA connection
establishment.
And in the interest of transport neutrality an InfiniBand option to emulate
IP based
connection establishment should emulate it as well.