On M/N reordering schemes: A relatively simple way to avoid the unlucky message sitting in the queue problem would be to store a timestamped, ordered list of messages waiting to go. The key word in the above sentence is the word "unlucky". When I formalize the word unlucky, I get "expected value is arbitrarily close to zero". Therefore, I completely ignore this situation, because it just doesn't happen often enough to worry about. If you have a higher level protocol which corrects errors, then staying in a mix too long is just another cause of failure. It should be tallied up with the rest of the causes of failure and then, once its contribution to unreliability has been established, ignored. The probabilistic reasoning which says that "the message will get out with the following distribution of latencies" is perfectly fine, and as long as the systemic consequences of late messages have a fixed upper bound, the total effect of delayed messages does also. Estimate the damage, and if it's workable just don't worry about it. And when I claim that some folks just empathize too much with that poor little datagram who went on an incredible journey through lots of out-of-the-way place to finally come home, well, I'm exactly half joking. Eric