[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?