[ofa-general] some questions on stale connection handling at the IB CM

[Or Gerlitz]

Hi Sean,

Basically, I am trying to understand when a "stale connection" as defined by
12.4.1 handling is carried out by the CM and what are the cases where it
must be handled at the app level (if there are such).

Looking on the code, I see that the CM sends a reject message with the reason being
IB_CM_REJ_STALE_CONN when it gets a REQ or REP whose <QPN, CA GUID> pair is already
present at the remote-qpn rb tree (and in another case which I don't fully understand).

On the other side, when the CM receives a reject message with that reason, the local handle
(id) is moved to the timewait state, where my understanding is that it will sit there for a while
and then a reject/stale-connection callback will be delivered to the user, the id will be removed.

What I don't see is issue of "DREQ, with DREQ:remote QPN set to the remote QPN from the REQ/REP"
as stated in 12.9.8.3.1 (below), is it really missing or I am reading the code wrong?

Also, its quite clear to me that from the view point of the application there are stale
connection cases which the CM can not catch, eg a client DREQ did not arrive to the server
side CM and then the client REQ uses a different QPN, etc. My understanding is that in such
cases the responsibility to close the stale connection/qp is on the server app.

Or.

12.9.8.3.1 REQ RECEIVED / REP RECEIVED
(RC, UC) A CM may receive a REQ/REP specifying a remote QPN in REQ:local QPN/REP:local QPN
that the CM already considers connected to a local QP. A local CM may receive such a REQ/REP
if its local QP has a stale connection, as described in section 12.4.1. When a CM receives
such a REQ/REP it shall abort the connection establishment by issuing REJ to the REQ/REP.
It shall then issue DREQ, with DREQ:remote QPN set to the remote QPN from the REQ/REP, until
DREP is received or Max Retries is exceeded, and place the local QP in the TimeWait state.