Re: [tor-dev] Testing Network Node Availability

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 versions.Â

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 addresses?

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 interference.)Â

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 consensus?Â

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.Â

Thanks,Â

Li.Â

On Fri, May 6, 2016 at 8:57 AM, Tim Wilson-Brown - teor <teor2345@xxxxxxxxx> wrote:

> On 6 May 2016, at 21:52, Roger Dingledine <arma@xxxxxxx> 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 well.

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 directories).

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

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev