Re: address pair exploration, flooding and state loss

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 27-mei-2005, at 17:28, marcelo bagnulo braun wrote:

> > However, if we assume that bidirectional connectivity is the most  
> > common, the fact that A sent something and B didn't get it is a  
> > good hint for B that this address probably won't work in the  
> > opposite direction either.

> > Since we want to arrive at one or two "good enough" pairs as  
> > quickly as possible, such hints could be valuable.

> ok, this is a choice that we need to make: do we think that the  
> bidirectional connectivity case will be common, so it makes sense  
> to provide an optimized support for it?

Most failures break connectivity in both directions. Only when the  
unreachability is because of ingress filtering (or maybe some other  
filtering), unidirectional reachability is much more likely.

> (because, this could also apply to the other threat that we are  
> having, about detecting outages, right?

How is this "other"??

> well, i guess i would always reply quite fast, but i would always  
> include info about past probes... but i guess i will be able to see  
> this point clearer once we have sketched a protocol

We have to be careful with this stuff: suppose a link for a site with  
many hosts goes down, then all those hosts are going to do  
reachability testing for all their sessions at the same time.

From your other message:

> > I would think that if one side triggers reachability testing, the  
> > other side would also do it.

> wouldn't this mean assuming bidirectional connectivity?

> I mean, would also do this is the locators used in one direction  
> differ from the ones used in the other direction?

I don't understand...

If the upper layers are communicating, there is some kind of  
reachability. Could be that it's 2 x unidirectional hidden by shim  
magic, but still.

If packets aren't flowing at it looks like this isn't because  
applications are idle, we need to test reachability. At this point we  
don't assume bidirectional reachability: it's highly likely that the  
current testing was triggered by an outage, so it's even possible  
that there is _no_ reachability.

The thing is that we need to decide which paths are most likely to be  
viable, and test them quickly. If that doesn't work, we have to start  
checking less and less likely paths until we've tested everything in  
every direction at least two or three times.