On 25-okt-2005, at 17:52, Erik Nordmark wrote:
The protocol as described by the state machine doesn't seem to work for ULPs that, even when they are "unhappy", space their retransmissions more than3 seconds apart.
[...]
When I asked Jari about this before I think he said it was an attempt to avoid a FBD keepalive message after the ULPs go silent (and are happy). But I think this is fundamentally unavoidable. If the ULPs finish exchanging packets, then I don't see how we can avoid having one end (the one that lastreceived a ULP packet) send a single FBD keepalive to the peer.
It is avoidable if after the final data packet, the other end sends an ACK and the protocol is smart enough to accept an ACK as an indiciation that communication works, but doesn't generate a keepalive after an ACK. In my draft, I assume that packets shorter than 20 bytes (excluding 20 bytes IPv6) are ACKs so FBD keepalives aren't generated for them.
This will of course lead to some extra work when a protocol only sends <= 20 byte packets in at least one direction, but I don't think that's too much of a problem.
I don't understand the comment text that says:The REAP design allows performing both failure detection and address pair exploration in the same sequence of messages, without a need to designate a specific point when the current address pair is declaredinoperational and the search for a new pair begins.It seems like the timout event that triggers a message with Y=no is quite different than the one that triggers a message with Y=yes. And the one that causes a message with Y=no is the point at which the current address pairhas been declared inoperational. So I'm not convinced it is helpful to be able to have the "FBD keepalive" (the payload reception report) and the event reception report in the same shim6 message.
Especially as keepalives will be relatively frequent so it's helpful to keep them as small as possible.