Re: Failure Detection (was Re: soft state (was Re: shim6 and bit errors in data packet headers

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

Hi Marcelo,

On 4-jun-2005, at 12:33, marcelo bagnulo braun wrote:

> > - if recent rx and recent tx: be happy, everything works
> > - if no recent rx and no recent tx: session is idle, do nothing
> > - if recent rx, but not recent tx: send keepalive
> > - if recent tx, but not recent rx: failure likely, start full  
> > reachability testing procedure

> i asume that receiving a keepalive does not increment Rx, right?  
> because if it does, then i think you could end up exchanging only  
> keepalives, and i guess we don't want that...

Right, when no recent tx and recent rx just keepalives, don't send  
keepalives. The other side will then stop sending keepalives as well  
so the state goes to idle.

> full reachability testing procedure does include verifying if  
> currently used locator pair is working through a reachability test,  
> right?

Right, and exploring other locator pairs until a working one is found  
or we know that none of them work.

> > The improvement over what you propose and/or NUD is that when  
> > there is no outgoing traffic, we just send keepalives, which could  
> > theoretically be just IPv6 headers without a payload. Since these  
> > are unidirectional they don't take up bandwidth in the other  
> > direction, as there is traffic flowing in that direction anyway.

> right, this would reduce 50% of the signalling in this situations i  
> guess

Yes, 50% of the packets and probably a bit more of the data as the  
keepalives can be very small, they don't have to carry any data or  
signalling.

> > There wouldn't be any advantage in combining this with positive  
> > feedback from ULPs, except maybe some small implementation  
> > optimization. However, listening for negative feedback could be  
> > useful to start reachability tests faster than the regular shim  
> > timeout.

> imho, ULP feedback should supersede this mechanism, since it it the  
> most reliable feedback imho.

:-)  I hope so.

Obviously TCP does really well here, but UDP-based stuff is a  
different story.

> I mean, if we have negative ACK from the ULP, then we must perform  
> a reahcbaility test to verify current locator pair (even if the Rx  
> ANd Tx are not detecting any problem)

Right: the ULP can have detected the problem faster, and, better safe  
than sorry.

> If we have positive ACK from the ULP, we should be fine and do  
> nothing, even if the TX and RX are detecting a failure)

If we only receive and don't send but the ULP is happy we still need  
to send keepalives because we can't know that the ULP at the other  
side is also providing positive feedback.

If we only send and don't receive but the ULP is happy (how does it  
know it can be happy??) I guess we can go either way without much harm.

So basically positive feedback wouldn't (have to) change our behavior.

> Rx and Tx are to be used when there is no info from ULP
> The reasons for this is that ULP really know for sure if  
> communication is progressing adequately. Tx and Rx are just  
> guessing. For instance, Rx could be fooled by an attacker injecting  
> packets with spoofed source address, in order to keep the  
> communication in a given path.

That's true.

On the other hand, I wouldn't necessarily put too much trust in what  
weird ULPs have to say. But as long as what they have to say can only  
help or hurt themselves I don't really care, of course.

Iljitsch