[tor-dev] Testing Network Node Availability
xli2 at andrew.cmu.edu
Fri May 6 19:10:15 UTC 2016
Thanks for the replies!
1. About the name:
Thanks for the headsup! We'll definitely pay attention to the trademark
rules when we publish our results. We are not planning to roll out our own
version of Tor. I think our most important goal is probably: demonstrate a
possibility of UDP-based protocol to solve some of TOR's hard performance
problems. And hope that you guys would consider using it in future
This leads me to a question about licensing: I believe TOR and QUIC have
different (conflicting) licenses. Would it even be a possibility that QUIC
ever makes it into TOR?
2. About our network config and clarification:
What do you mean by a "real network"?
> Do you mean a test network with your own authorities on non-localhost IP
Yes, our testing framework is using EmuLab with customized bandwidth,
latency, queue size and drop rate.
>From Tor's perspective, we are still using "TestingTorNetwork".
I also wonder why you need to use path restrictions at all.
3. For path restriction, we have our own implementation. We parse the
config file and use the nickname in choose_good_*() functions to return the
corresponding nodes. We have to use this because restricting the middle node*
is very important to us for testing HOL blocking problem.* (We have to
manually create 1-hop overlapping path for two clients and test the
4. Regarding the issue, it's probably not entry guard problem, because: 1)
Shouldn't that give "failed to select hop 0" instead of hop 1? 2) I can see
in our debugging log that we failed on the extending info with the second
node. The node returned by choose_good_middle_server is not NULL but the
routerinfo_t pointer is NULL. Any idea why?
My guess is that consensus is a little short for some reasons, how do I
validate this guess? Does the global router list contain everything on the
5. More observation on this issue:
For both tor and our tor, when I decrease the size of the network (i.e.
number of relays in the network), the hanging issue resolves itself..
I'll try rebase back to an official release today.
On Fri, May 6, 2016 at 8:57 AM, Tim Wilson-Brown - teor <teor2345 at gmail.com>
> > On 6 May 2016, at 21:52, Roger Dingledine <arma at mit.edu> wrote:
> >> (Normally, a client won't re-use any of its 3 guards as a middle or
> >> exit. TestingTorNetwork disables this behaviour.
> > Tim: I think this statement might be wrong? Tor picks its exit first,
> > then picks a current guard that doesn't overlap with the exit, then
> > picks a middle that doesn't overlap with either of them.
> > See e.g. choose_good_middle_server().
> Apologies, I didn't remember or explain the details of path selection very
> When tor is selecting an entry node for CIRCUIT_PURPOSE_TESTING in
> choose_good_entry_server(), it excludes all guard nodes, and excludes the
> exit. This can mean that 1 exit, 3 (or more) directory guards, and possibly
> another 3 (or more) entry guards are excluded. The entry guards are not
> necessarily the same as the directory guards (this can happen if the
> directory guards do not have descriptors, or the entry guards are not
> So if you're excluding 7 or more nodes in a small network, this can cause
> path selection failures.
> Of course, it could be that entry guard selection is failing for other
> reasons, like a lack of nodes in the consensus.
> Without context from the logs, it's hard to tell whether it's testing
> circuits or standard circuits that are causing the path failures.
> Tim Wilson-Brown (teor)
> teor2345 at gmail dot com
> PGP 968F094B
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev