Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period.

As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period.

For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers.

Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0).