[or-cvs] add johnny"s further discussion on incentives.

[arma at seul.org]

Update of /home2/or/cvsroot/tor/doc
In directory moria:/home/arma/work/onion/cvs/tor/doc

Modified Files:
	incentives.txt 
Log Message:
add johnny's further discussion on incentives.


Index: incentives.txt
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/incentives.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -d -r1.8 -r1.9
--- incentives.txt	23 Feb 2006 06:52:54 -0000	1.8
+++ incentives.txt	9 Mar 2006 22:21:07 -0000	1.9
@@ -55,6 +55,11 @@
    accept claims from every Tor user and build a complex weighting /
    reputation system to decide which claims are "probably" right.
 
+   One possible way to implement the latter is something similar to
+   EigenTrust [http://www.stanford.edu/~sdkamvar/papers/eigentrust.pdf],
+   where the opinion of nodes with high reputation more is weighted
+   higher.
+
 3. Related issues we need to keep in mind.
 
 3.1. Relay and exit configuration needs to be easy and usable.
@@ -98,6 +103,10 @@
    also through indirect interaction (middle of the circuit). That way
    you can never be sure when your guards are measuring you.
 
+   Both 3.2 and 3.3 may be solved by having a global notion of reputation,
+   as in 2.3 and 2.4. However, computing the global reputation from local
+   views could be expensive (O(n^2)) when the network is really large.
+
 3.4. Restricted topology: benefits and roadmap.
 
    As the Tor network continues to grow, we will need to make design
@@ -164,6 +173,15 @@
    maybe it's an argument in favor of a more penny-counting reputation
    approach.
 
+   Addendum: I was more thinking of measuring based on who is the service
+   provider and service receiver for the circuit. Say Alice builds a
+   circuit to Bob. Then Bob is providing service to Alice, since he
+   otherwise wouldn't need to spend is bandwidth. So traffic in either
+   direction should be charged to Alice. Of course, the same attack would
+   work, namely, Bob could cheat by sending bytes back quickly. So someone
+   close to the origin needs to detect this and close the circuit, if
+   necessary. -JN
+
 3.7. What is the appropriate resource balance for servers vs. clients?
 
    If we build a good incentive system, we'll still need to tune it
@@ -255,15 +273,106 @@
    third approach is to remember which connections have recently sent
    us high-priority cells, and preferentially read from those connections.
 
-   Hopefully we can get away with not solving this section at all.
+   Hopefully we can get away with not solving this section at all. But if
+   necessary, we can consult Ed Knightly, a Professor at Rice
+   [http://www.ece.rice.edu/~knightly/], for his extensive experience on
+   networking QoS.
+
+3.11. Global reputation system: Congestion on high reputation servers?
+
+   If the notion of reputation is global (as in 2.3 or 2.4), circuits that
+   go through successive high reputation servers would be the fastest and
+   most reliable. This would incentivize everyone, regardless of their own
+   reputation, to choose only the highest reputation servers in its
+   circuits, causing an over-congestion on those servers.
+
+   One could argue, though, that once those servers are over-congested,
+   their bandwidth per circuit drops, which would in turn lower their
+   reputation in the future. A question is whether this would overall
+   stablize.
+
+   Another possible way is to keep a cap on reputation. In this way, a
+   fraction of servers would have the same high reputation, thus balancing
+   such load.
+
+3.12. Another anonymity attack: learning from service levels.
+
+   If reputation is local, it may be possible for an evil node to learn
+   the identity of the origin through provision of differential service.
+   For instance, the evil node provides crappy bandwidth to everyone,
+   until it finds a circuit that it wants to trace the origin, then it
+   provides good bandwidth. Now, as only those directly or indirectly
+   observing this circuit would like the evil node, it can test each node
+   by building a circuit via each node to another evil node. If the
+   bandwidth is high, it is (somewhat) likely that the node was a part of
+   the circuit.
+
+   This problem does not exist if the reputation is global and nodes only
+   follow the global reputation, i.e., completely ignore their own view.
+
+3.13. DoS through high priority traffic.
+
+   Assume there is an evil node with high reputation (or high value on
+   Alice) and this evil node wants to deny the service to Alice. What it
+   needs to do is to send a lot of traffic to Alice. To Alice, all traffic
+   from this evil node is of high priority. If the choice of circuits are
+   too based toward high priority circuits, Alice would spend most of her
+   available bandwidth on this circuit, thus providing poor bandwidth to
+   everyone else. Everyone else would start to dislike Alice, making it
+   even harder for her to forward other nodes' traffic. This could cause
+   Alice to have a low reputation, and the only high bandwidth circuit
+   Alice could use would be via the evil node.
 
 4. Sample designs.
 
 4.1. Two classes of service for circuits.
 
+   Whenever a circuit is built, it is specified by the origin which class,
+   either "premium" or "normal", this circuit belongs. A premium circuit
+   gets preferred treatment at each node. A node "spends" its value, which
+   it earned a priori by providing service, to the next node by sending
+   and receiving bytes. Once a node has overspent its values, the circuit
+   cannot stay as premium. It can either breaks or converts into a normal
+   circuit. Each node also reserves a small portion of bandwidth for
+   normal circuits to prevent starvation.
+
+   Pro: Even if a node has no value to spend, it can still use normal
+   circuits. This allow casual user to use Tor without forcing them to run
+   a server.
+
+   Pro: Nodes have incentive to forward traffic as quick and as much as
+   possible to accumulate value.
+
+   Con: There is no proactive method for a node to rebalance its debt. It
+   has to wait until there happens to be a circuit in the opposite
+   direction.
+
+   Con: A node needs to build circuits in such a way that each node in the
+   circuit has to have good values to the next node. This requires
+   non-local knowledge and makes circuits less reliable as the values are
+   used up in the circuit.
+
+   Con: May discourage nodes to forward traffic in some circuits, as they
+   worry about spending more useful values to get less useful values in
+   return.
+
 4.2. Treat all the traffic from the node with the same service;
      hard reputation system.
 
+   This design is similar to 4.1, except that instead of having two
+   classes of circuits, there is only one. All the circuits are
+   prioritized based on the value of the interacting node.
+
+   Pro: It is simpler to design and give priority based on connections,
+   not circuits.
+
+   Con: A node only needs to keep a few guard nodes happy to forward their
+   traffic.
+
+   Con: Same as in 4.1, may discourage nodes to forward traffic in some
+   circuits, as they worry about spending more useful values to get less
+   useful values in return.
+
 4.3. Treat all the traffic from the node with the same service;
      soft reputation system.
 
@@ -300,7 +409,10 @@
    one way through: if there are few exits, then they will attract a
    lot of use, so lots of people will like them, so when they try to
    use the network they will find their first hop to be particularly
-   pleasant. After that they're like the rest of the world though.
+   pleasant. After that they're like the rest of the world though. (An
+   alternative would be to reward exit nodes with higher values. At the
+   extreme, we could even ask the directory servers to suggest the extra
+   values, based on the current availability of exit nodes.)
 
    Pro: this is a pretty easy design to add; and it can be phased in
    incrementally simply by having new nodes behave differently.
@@ -337,5 +449,16 @@
 
 5. Recommendations and next steps.
 
+5.1. Simulation.
+
+   For simulation trace, we can use two: one is what we obtained from Tor
+   and one from existing web traces.
 
+   We want to simulate all the four cases in 4.1-4. For 4.4, we may want
+   to look at two variations: (1) the directory servers check the
+   bandwidth themselves through Tor; (2) each node reports their perceived
+   values on other nodes, while the directory servers use EigenTrust to
+   compute global reputation and broadcast those.
+
+5.2. Deploying into existing Tor network.