RE: MPA issue (3): Rejected Connection bit

Carrier, John said:

> * if the Request Frame is invalid or if the ULP rejects the connection,
> MPA will transition to an 'inactive' state after sending the Reply Frame
> with the rejected bit set to 1.  In this state, the TCP connection is
> open, but MPA is no longer consuming any of the TCP data stream; instead
> any received data goes directly to the ULP.
>

The two reject cases should be distinquished.

If the Request Frame is invalid the request is being rejected by
the MPA layer, not by the ULP. There is no Private Data available
for a response.

If it was rejected by the ULP, there will be Private Data supplied
in accordance with the specific protocol. Providing a zero length
Private Data may have specific meaning under that protocol.

Generally, if the Request Frame itself is invalid the most likely
cause is a misdirected connect request by a non-RDMA client.
Such a client will not be able to parse the Reply Frame anyway
(and given that it cannot format a Request Frame there is little
reason to believe that it will).

In that case I believe the correct respsonse to an invalid request
frame would be to simply terminate the connection.

This means that invalid MPA Request Frames will be lumped with
other "network related" errors from the initiating ULPs perspective.
In my opinion this is a better grouping than lumping it with a
peer reject, particularly if it forces the ULP to specify a non-zero
lenght "nothing" message just to prove it was the ULP that had
indeed said nothing.

If someone can suggest a reason why this error is of particular
signifigance to the source ULP then I could see having a distinct
error bit. But my suspicion is that this error will seldom be seen
between actual RDMA peers, and more often be the result of
a misdirected non-RDMA client.