1. Is there a maximum duration of packet loss between any single (or all) nodes that can be tolerated without impacting the membership within corosync?
2. Is there a difference between tolerating packet loss for node membership versus group membership changes?
3. Is there a way to adjust the duration of the loss tolerance, extending to some greater time?
4. During an event with loss, is there some ramification to communication between group members, such as EAGAIN for senders?
5. Is the loss impacted by the choice of communication (mcastaddr vs udp point to point)?
6. Does the volume of communication over a group potentially impact the tolerance to loss or expected results from the sender/receiver of the group communication?
7. Does the frequency of packet loss impact the policy (for example a periodically busy network causing intermittent packet loss)?
8. Once communication is re-established how long before membership change events allow the node back in?
9. How long until the individual members resume? (never, isolated group must be closed and re-opened?).
background:
For high hardware availability it might be desirable to have two switches allowing no single point of failure. Various switch vendors handle duplicity of hardware in many different ways. For example, one vendor might detect the failure of a switch and then reset the remaining switch to take over some responsibilities resulting in an outage (link down) of all connections for as long as 10 seconds (I know, unbelievable but true!)! Other configurations / hardware may lead to a single failure resulting as much as 0.5 seconds of packet loss to all messages, but retain link. Internal bonds may exhibit behaviours that drop packets for 200-400msec. Still other failure scenarios may drop packets for times reaching up to 60 msec.
discussion:
Is there a designed tolerance to packet loss by the group communications infrastructure (cpg) in the various versions (1.4.2, 2.x) and what the expected results are below and above that threshold for membership changes?
Thank you for considering such an extensive query...
speculation:
the token retransmit value defaults to 1000 with a token retransmits before loss count value of 4, allowing up to 4 seconds of failure before triggering a membership change. Group membership and node membership run in parallel, but group membership does not automatically reform into larger group. The problem count threshold and timeout hold a tight duration (~50msec) so loss frequency greater than this value are considered independent events. Senders get EAGAIN type responses once an internal outbound queue reach a threshold but this threshold is very high and may lead to large memory use by application for fast senders/slow receivers or faced with lossy or intermittently congested networks.
dan
_______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
