[openib-general] [PATCH] rdma_cm iWARP connection setup timeouts reported as rejects.

[Caitlin Bestler]

> -----Original Message-----
> From: openib-general-bounces at openib.org 
> [mailto:openib-general-bounces at openib.org] On Behalf Of Steve Wise
> Sent: Monday, January 08, 2007 6:55 AM
> To: Mirko Benz
> Cc: openib-general at openib.org
> Subject: Re: [openib-general] [PATCH] rdma_cm iWARP 
> connection setup timeouts reported as rejects.
> 
> On Mon, 2007-01-08 at 12:13 +0100, Mirko Benz wrote:
> > Hi,
> > 
> > What could be the reasons for these timeouts to occur?
> 
> One way: If the host is not reachable but the next hop 
> neighbour is, then the connection attempt will timeout.
> 
> Another way is if, for some reason, the MPA negotiation 
> doesn't complete in a timely manner.  For instance, if the 
> passive side never rdma_accept()s the connection, then the 
> active side should eventually timeout the attempt and return 
> a timeout error to the consumer.
> 
> 

One very important additonal example of "MPA negotiation failure"
is the case where only one end of the TCP connection was anticipating
the usage of MPA.

For example, if an ssh client mistakenly tried to connect to 
an iWARP port, both sides would just sit there waiting for
the other one to say something. An eventaul timeout is the
only way out of this.

> > How should an application handle this?
> > 
> 
> Applications should handle connection timeouts however they want.
> Usually they just report it to the user.
> 
> 

One way to look at it is that "host unreachable" is an *optimized*
error report that deals with certain conditions where the unreachability
can be quickly determined. In the more general case, the fact that a
given host/service is currently unavailable is only known by its failure
to answer.

In most cases corrective action (either get the remote service
restarted,
make the path to it work, or select another service) is up to the user.