[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
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?