Latency vs. Reordering
hughes@ah.com (Eric Hughes) writes:
For the Nth time, it's not latency, it's reordering which is important. True. For small numbers of files re-ordering is important. On the large scale, latency serves both purposes. I tend to think of these things on the large scale, which is the reason I pointed things that way.
--jeff
True. For small numbers of files re-ordering is important. On the large scale, latency serves both purposes. I tend to think of these things on the large scale, which is the reason I pointed things that way. That's fine, but say reordering if you mean reordering, and not something else that merely yields reordering. Reordering is the important concept. Latency is a derivative concept. Reordering is more important than latency. If you use the "collect-and-shuffle" method of reordering, you get _guaranteed_ reordering. If you use random delay, you get no guarantees until you do the detailed mathematical analysis of just how much reordering that gets you. Merely _measuring_ the amount of reordering in a continuous message stream is an interesting definitional problem. Calculating these measures will require some fairly sophisticated probability theory, and NO ONE HAS DONE THAT YET. Cryptography is about assurances as much as actual security. Adding latency now yields NO GUARANTEES about the amount of reordering, because the work has not yet been done. Adding latency gives only warm fuzzy feelings, and no understanding. The maxim applies here: "I you don't understand how it works, don't trust it." Eric
participants (2)
-
hughes@ah.com -
Jeff Gostin