Contrary to UNICAST, which acks every message, UNICAST2 never acks messages, but only asks the sender to retransmit a message when a gap has been detected.
However, the drawback of this (negative ack) mechanism is the so called last-message-dropped problem: when A sends messages [1..5] to B, but 5 is dropped by the transport, as A doesn't retransmit messages until it gets a retransmission request from B, B only gets messages [1..4].
B will not ask A to retransmit message 5, as B doesn't know A sent message 5 in the first place.
If A doesn't send message 6 for B to detect 5 is missing and asking A for retransmission, B won't get that message.
The way this is currently handled is with stable messages. A STABLE message is sent from B to A every stable_interval ms or whenever M bytes from A have been received. In the worst case, B will have to wait stable_interval ms until it finally receives message 5 from A.

SOLUTION:
In addition to time and size based STABLE messages, we could send a STABLE message whenever the batch of messages removed from the receive window has completed and the receive window is empty.

This would send a STABLE message immediately when a single message has been received (and no other messages from A are in the receive window), but it would send another STABLE message only when all (e.g.) 200 messages from A have been processed and the receive window is empty.

With this new mechanism, we could even remove the time-based STABLE messages !

Example:

• At time T0, messages M1 and M2 are received. A STABLE message for M2 is sent.
• At T+500 (ms), messages M3-M100 are received. A STABLE message for M100 is sent
• At T+1500, M101 is received. A STABLE message for M101 is sent.
• At T+2000, M102 is received. A STABLE message for M102 is sent.
• At T+2010, M103-M500 are received. A STABLE message for M500 is sent

(Note that the example above didn't take size-based STABLE messages into account)

This is similar to the ACK based scheme in UNICAST where we only send an ack for the last message in a batch (or for a single message if not batch has been received).

This new mechanism needs to be configurable: if enabled, the time-based STABLE mechanism would be disabled.