Re: MPA issue (3): Rejected Connection bit

On Apr 7, 2004, at 6:24 PM, Teisberg, Robert wrote:

> Caitlin Bestler wrote:
>
>>
>> The typical use is when the private data sent by the active
>> side was unacceptable to the passive side, or for some other
>> ULP reason the connection is not to proceed further.
>>
>> This capability is assumed by RDMA-aware APIs such as uDAPL
>> and IT-API. Without this capability they must simulate the
>> rejection bit by sending options that they know will be
>> rejected. An "honest" reject bit is a far cleaner solution.
>>
>
> "Must" is a little strong.  An alternative is to silently
> drop the connection.  The API will report this as "connection
> lost" or "connection reset" or something equally mysterious.
> This is hardly ideal but not totally unworkable.
>
>

The APIs make a distinction between a connection request
refused by the peer and those that failed for other reasons.
This is an important distinction. If a connection failed for
"other" (non-peer) reasons, the chance of another session
request being honored is very low -- but the chance that the
same session will be accepted at some later time is good.

If the connection was rejected by the peer, the opposite
is true.

Generally the applications themselves do not care about
exactly what network error killed the connection, but there
is a very big difference between "cannot communicate
with X" and "X does not want to talk with you."