From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 65004c1049c20776490bacfe3a808be84907fa9456c428b6868ee376a8b2348b
Message ID: <9408062302.AA17213@ah.com>
Reply To: <199408060555.AAA06154@pentagon.io.com>
UTC Datetime: 1994-08-06 23:31:20 UTC
Raw Date: Sat, 6 Aug 94 16:31:20 PDT
From: hughes@ah.com (Eric Hughes)
Date: Sat, 6 Aug 94 16:31:20 PDT
To: cypherpunks@toad.com
Subject: Remailer ideas
In-Reply-To: <199408060555.AAA06154@pentagon.io.com>
Message-ID: <9408062302.AA17213@ah.com>
MIME-Version: 1.0
Content-Type: text/plain
Given a connectionless network absolute delivery is impossible (well, not
completely, but just about...)
Here is a theme I'm going to mention a few times today: the complexity
class of probabilistic algorithms is the one that matters most for
practical applications.
Which is to say, that when you have a partially unreliable
connectionless network, you can't, can not, can never _assure_
delivery. You can, however, set up the protocols so that the
assurance in delivery is arbitrarily close to probability one, even
though it can't ever actually reach it.
Here's the fallacy which is common, that something which is
probabilistically bounded but is not deterministically bounded is
somehow flawed.
Or, rather, you can trust expected values.
Hal's random-send spool has an expected value of latency which is
approximately the size of the spool but has no deterministic upper
bound for that latency. Fine. Great. No problem. There should be
zero hesitation here, because the expected value -- the probabilistic
average -- is what you want.
When you start off with probabilistic assumptions about the underlying
reliability of the network, the best you can get is probabilistic
answers. Even if the network components are deterministic, you still
get probabilistic results. Adding probabilistic components also gives
you probabilistic results. So what's the bid deal?
The hesitation to accept a probabilistic measurement is still
all-too-frequent. I will refrain from commenting on why I think that
is, and merely admonish folks not to pull their punches and bewail a
probabilistic result about device behavior.
Eric
Return to August 1994
Return to “tcmay@netcom.com (Timothy C. May)”