[openib-general] [PATCH ] RFC IB/cm do not track remote QPN in timewait state

[Michael S. Tsirkin]

Quoting r. Sean Hefty <mshefty at ichips.intel.com>:
> The CM should track remote QPs that are either:
> 
> 1. Part of an active connection, or
> 2. A connection that has been placed into timewait.

Agree here.

> The CM should detect attempts to connect such remote QPs, and reject them.

That's stretching what the spec says though. It says reject in case 1.

> The 
> entire paragraph is referring to stale connection handling,

Not really, stale connection handling is the one below.
This paragraph talks about release in general.

> and I believe the 
> reference to timewait is included as part of that general discussion.

So CM currently tracks the remote QPN that QP in timewait *as* connected to.
What you get then is, e.g.:
- local side sends dreq
- remote side sends drep, places qp in timewait
- local side gets drep places qp in timewait
- remote side gets out of timewait reuses qp and sends req
- local side sees remote QP was used as peer for local qp
  that now is in timewait, and rejects the connection

And here we are, connection request that was part of a perfectly
valid connection setup sequence gets rejected as supposedly stale.

In your interpretation, I see no way *not* to get rejects which
breaks applications such as SDP which are careful to perform
DREQ/DREP sequence gracefully, but report rejects directly to the user.

-- 
MST