RE: failure detection

[<john.loughney@nokia.com>]

Iljitsch,


>Somewhat to my disappointment, there were no opinions about 
>which of the two failure detection mechanisms is better, 
>either during the sessions or afterward on the list.

At least for me, I'm still puzzeling over how to capture failure ...
Between 2 hosts, tcp traffic may work but not udp traffic (mostly due
to stupid middleboxes). Is this a failure from the shim point of view?

Also, different transports have different concepts of what 'failure'
is. When is a path considered failed? Classical TCP failure
(retransmission
of the the same packet x times)?  Too high bit-error rate?  I think we
might 
run into circumstances where if we let the shim layer decide
conclusively
that a path has failed, it might decide much later that the path is bad
than what the transport layer knows.

I think we should avoid any transport layer functions in the shim layer
(or at least as much as possible).  I'm leaning more towards the
rich-api
type of functionality, where the shim provides as much info as it can
to the transport layers, and let the transport layers make decisions.

I'm also wondering if the failure detection mechanism should be a
pluggable
option; I've been thinking how the shim layer would work in wireless
environments,
and I don't think I'd like to have fast heartbeating, as that would
drain
batteries unnesscesarily.  Could it be possible to have this
functionality
as optional?  

John