Re: [tor-dev] connectivity failure for top 100 relays

2018-05-02 Thread teor
On 3 May 2018, at 06:41, nusenu wrote: >> What are the guidelines to avoid getting blocked by the tor network? > > stay under the public thresholds? > https://www.torproject.org/docs/tor-manual-dev.html.en#_denial_of_service_mitigation_options Those are the defaults. You'll need to stay under

Re: [tor-dev] HS v3 client authorization types

2018-05-02 Thread teor
> On 3 May 2018, at 02:09, George Kadianakis wrote: > > I think my approach here would be to try to support both auth types by > the time we launch this feature (under the "standard" auth type), and > then in the future as we get more insight on how people use them, we > should start allowing to

Re: [tor-dev] connectivity failure for top 100 relays

2018-05-02 Thread dawuud
> can you let me know the start and end date of the scan (2018-03-12?) so I can > check how many of > the relays you scanned (the top 100 relays by cw? at the time) that scan only took an hour or so to perform and I posted the e-mail minutes after the scan, so you can refer to the date in the e

Re: [tor-dev] connectivity failure for top 100 relays

2018-05-02 Thread nusenu
> I think that many of my previous scans were not useful and > showed inaccurate I'm glad that it turned out that these previous results might have been inaccurate (because the results were scary if found to be accurate) > results because the IP address i was scanning > from might have gotten b

Re: [tor-dev] connectivity failure for top 100 relays

2018-05-02 Thread dawuud
I think that many of my previous scans were not useful and showed inaccurate results because the IP address i was scanning from might have gotten black listed by dir-auths? or perhaps blocked by many relays by the anti-denial-of-service mechanisms in tor? i got rid of that virtual server and lost

Re: [tor-dev] HS v3 client authorization types

2018-05-02 Thread George Kadianakis
Suphanat Chunhapanya writes: > Hi, > > On 04/28/2018 06:19 AM, teor wrote: >>> Or should we require the service to enable both for all clients? >>> >>> If you want to let the service be able to enable one while disable the >>> other, do you have any opinion on how to configure the torrc? >> >> I

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

2018-05-02 Thread teor
Hi Nick, Juga asked me to comment on your review, so she could read it before our bandwidth meeting this week. If I don't comment on a suggestion, you should assume I agree with it. Backwards Compatibility Nick asked about backwards compatibility. This format uses semantic versioning. Tor 0.2

Re: [tor-dev] Tor Terminology + torspec

2018-05-02 Thread Nick Mathewson
On Wed, May 2, 2018 at 4:56 AM, Iain Learmonth wrote: > Hi All, > > Looking at the recent work on the Tor bandwidth measurements document > format, I've noticed there are a few places where language can be > ambiguous [0]. This morning, I noticed more ambiguity in some metrics > tools [1]. We cou

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

2018-05-02 Thread Iain Learmonth
Hi, On 02/05/18 10:31, teor wrote: > So let's try to keep "relay measurement" and "relay bandwidths" as > separate concepts. Aaah, ok. Yes, I much prefer "Relay Bandwidth" as the name for the section in §2. There are then also lots of references to measurement in §2.2, that should also be changed

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

2018-05-02 Thread juga
juga: >>> Each relay_line MUST include the following key_value in arbitrary order: >> >> Do existing implementations accept arbitrary order here? > > Good question, it seems like bw must be behind node_id, but they can > have things in front and behind. I probably should create a ticket to > add

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

2018-05-02 Thread teor
On 2 May 2018, at 19:18, Iain Learmonth wrote: >> "Measurements Results" describes how the bandwidths are created by >> some generators. But a generator that believes self-reported results >> doesn't measure, it just aggregates. (As does a peerflow-style generator.) >> > I'm not sure I understa

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

2018-05-02 Thread Iain Learmonth
Hi, On 02/05/18 09:59, teor wrote: > Let's use: > Tor Bandwidth List Format As we are already using this for the directory lists, I think this makes sense as a name for the format. > "Measurements Results" describes how the bandwidths are created by some generators. But a generator that believes

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

2018-05-02 Thread teor
On 2 May 2018, at 18:34, juga wrote: 2. Format details Bandwidth measurements MUST contain the following > sections: - Header (exactly once) - Relays measurements (zero or more times) >>> >>> Grammar suggestion: "Relay measurements". >> >> In this case, this would

[tor-dev] Tor Terminology + torspec

2018-05-02 Thread Iain Learmonth
Hi All, Looking at the recent work on the Tor bandwidth measurements document format, I've noticed there are a few places where language can be ambiguous [0]. This morning, I noticed more ambiguity in some metrics tools [1]. We could do with a glossary. The problem though is not the lack of a glo

Re: [tor-dev] Proposal: Tor bandwidth measurements document format

2018-05-02 Thread juga
Hi Iain, Iain Learmonth: > Hi, > >> Tor Bandwidth Measurements Document Format > > "Measurement" could mean a method for performing a measurement, a single > measurement task, a schedule for a repeating measurement task, a > measurement result or a few other things. I also wondered whether tha