Changes
simplify; k is unnessary, the parameters are already generous
When a member u accepts a non-explicit-ack message m at time t
* if u did not send m, and they have not acked m by t+MAX_GRACEACK_GRACE_INTERVAL, they should send an explicit-ack* if m is not fully-acked (from their POV) by t+(2*MAX_RTTBROADCAST_LATENCY)+(k*MAX_GRACE) (k slightly > 1) ACK_GRACE_INTERVAL then issue a local UI warning. Cancel the warning if/when full-ack is reached later.
=== Parameters and properties ===
* MAX_RTT BROADCAST_LATENCY should be based on the transport.* MAX_GRACE ACK_GRACE_INTERVAL should be based on expected user communication rate. Both of these should be defined to cover common cases (e.g. 95th-percentile) rather than being mean values.
This guarantees that a warning shows up if we don't reach consistency within the timeout defined above, ensuring timeliness.
In terms of overhead, effectively a user will send a message at least every MAX_GRACE ACK_GRACE_INTERVAL time period, whilst the session has other people talking. When there is a lull in the conversation, there should be no further messages.
I'm confident we can tweak the parameters so servers don't see too much extra load, but have not tried to model this precisely.
