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

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

On 27-mei-2005, at 23:37, Erik Nordmark wrote:

> > I would think that if one side triggers reachability testing, the   
> > other side would also do it. The probes in one direction can also   
> > function as replies in the other direction, cutting down on the   
> > number of packets exchanged.

> I'm not sure we'd end up with both ends triggering reachability  
> testing at about the same time, because that would seem to assume  
> some form of periodic reachability testing even when there is no  
> ULP traffic. Such background chatter seems undesirable.

I'm not sure what you mean here...

What I'm getting at is that one end says "hey, can you still hear  
me?" and then the other end says "sure, and can you still hear me?".  
The first party then replies with "yes" and we know that there is  
reachability in both directions.

Obviously it would be possible for one end to test reachability and  
for the other end to do nothing, but that means more packets and  
longer delays until certain failures are detected.

There is of course a corner case where both ends trigger reachability  
testing independently at the same time, but I think if we design the  
protocol carefully, this shouldn't be problematic.

> Thus I think we'd want a packet driven trigger of reachability  
> testing (much like NUD). When A sends a ULP packet to B, it checks  
> whether it has current reachability information for B, and if not  
> it triggers reachability testing.

Disagree. I think we should assume reachability until we get a hint  
that there is none. So if A sends a packet to B, B does nothing and  
will 99% likely in due course send a packet back because transports  
tend to work in both directions. However, if A doesn't get a reply  
and the packet it sent earlier isn't one that is known to go  
replyless (i.e., TCP ack-only or fin packets, A triggers reachability  
testing.

> With such an approach, only in the case that B receives the ULP  
> packet and this makes it send a ULP packet back (e.g., a TCP ACK),  
> might B trigger reachability testing.
> But when B doesn't receive the packet it would not trigger  
> reachability testing at the same time as A does.

As per my suggestion, there would normally not be any reachability  
testing as long as packets flow in both directions. When there is a  
bidirectional failure AND both ends were sending data at the same  
time (= not when data is flowing in one direction and just acks in  
the other), there would probably be reachability testing triggered in  
both directions at the same time.

Do you consider this problematic?