Delivery-Date: Wed, 03 Sep 2014 22:48:20 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id D78B71E0E71;
	Wed,  3 Sep 2014 22:48:18 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id C7AC324966;
	Thu,  4 Sep 2014 02:48:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id D939224567
 for <tor-talk@lists.torproject.org>; Thu,  4 Sep 2014 02:48:10 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VO-Axw7fnZD6 for <tor-talk@lists.torproject.org>;
 Thu,  4 Sep 2014 02:48:10 +0000 (UTC)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com
 [IPv6:2607:f8b0:4001:c05::231])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id B1B1323A7F
 for <tor-talk@lists.torproject.org>; Thu,  4 Sep 2014 02:48:10 +0000 (UTC)
Received: by mail-ig0-f177.google.com with SMTP id r10so352131igi.4
 for <tor-talk@lists.torproject.org>; Wed, 03 Sep 2014 19:48:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=cyblings.on.ca; s=google;
 h=message-id:date:from:user-agent:mime-version:to:subject:references
 :in-reply-to:content-type:content-transfer-encoding;
 bh=QsmrZX9AG9mBvwpdST0M80i9a4muDkWH4xFS2AAricc=;
 b=ckkdXY967j62HLqVQ69vv7HAfYE1G72qwDzcxkUAo7e3ligvfEGd9s2oFMGg6j3AAu
 7Y1EVTQRItEktWOO9SfmG+d3vq8Kyza6n1sW+NsQ8Oii21L8sdkJjpx9bQ5bmtGiGEi5
 bLDdPFvn1kQeh2eVvYUwo20gHRjtcf+7aYmfI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
 :subject:references:in-reply-to:content-type
 :content-transfer-encoding;
 bh=QsmrZX9AG9mBvwpdST0M80i9a4muDkWH4xFS2AAricc=;
 b=j7//JuhymP7TGxeXAiHSiNvkBtSlP8HwIDqzDVKige4jStkHpVkGQgPHfInv3i7zZ1
 bqGrtcP6Ol6NQ5DK8s+nHA6MIV5iZbVt+fFYkOdfGcS5tNb5ss3oF7jBYUZOXfWliVDd
 voghsqO1hTQfVGqbrEOKYO1VMgMz62X7d7byj837q0jHoczPpYuV/Cmwe//m4o2z83Ac
 LjIj1AYAZvcaW4CSi1WMSFkPGzi4KtPzHm9zdL22pG6i+V3BPOVMrS38pKkJ1jKrolOC
 naGwJzAyJJZ/L6evtx+ZSkAxgIaFrZK3zW9mBNy0TWM514UhWLlNzZ62f8W/gtFq8QO2
 XA6Q==
X-Gm-Message-State: ALoCoQmjCFSQAz8hHzzZk6lMu03mcEqO1eqN1sCnWukZSJbkfbNdpB9IFSP1zyke5wW09AY3Oh72
X-Received: by 10.42.237.197 with SMTP id kp5mr1394044icb.49.1409798888446;
 Wed, 03 Sep 2014 19:48:08 -0700 (PDT)
Received: from [192.168.1.2] (69-196-152-198.dsl.teksavvy.com.
 [69.196.152.198])
 by mx.google.com with ESMTPSA id e4sm7185758igl.18.2014.09.03.19.48.07
 for <tor-talk@lists.torproject.org>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 03 Sep 2014 19:48:07 -0700 (PDT)
Message-ID: <5407D2E3.7070808@cyblings.on.ca>
Date: Wed, 03 Sep 2014 22:48:03 -0400
From: krishna e bera <keb@cyblings.on.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <CADop2NGjDi3x-hKxRC7wBAWu5cYWzkHe+hg703UuxkPiSC2X=A@mail.gmail.com>
 <20140904022543.GV8819@moria.seul.org>
In-Reply-To: <20140904022543.GV8819@moria.seul.org>
Subject: Re: [tor-talk] Tentative results of analysis of data on
	metrics.torproject.org
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 14-09-03 10:25 PM, Roger Dingledine wrote:
> On Wed, Sep 03, 2014 at 04:10:13PM -0700, Virgil Griffith wrote:
>> https://docs.google.com/document/d/1SaBK664SchhZOP9XBsB8KK63k4xlmMTlkhfF28f2204/pub
> [...]
> - Figure 3 is a bit weird. Our bandwidth-per-relay stat is a function of
> how many total relays we have, but not really a function of the growth
> in total relays. So if for example we added a bunch of fast relays,
> but we also added even more slow relays, then this graph would show
> that bandwidth-per-relay isn't growing. So I guess the question is:
> what conclusions should we draw from Figure 3? If it levels off or goes
> down in the future, does that indicate a bad thing in any way?
> 
> Or said a different way, maybe we should be graphing the mean bandwidth
> of the fastest k relays in the network? That's sort of what we had in
> mind with
> https://metrics.torproject.org/bandwidth.html#advbwdist-relay
> and it better shows the growth in capacity of the network, in a way
> that wouldn't be dragged down by adding a whole bunch of fast relays
> (which people use) but also adding a whole bunch of slow ones (which
> people don't use).

What about using the mean bandwidth of relays flagged as "Fast"?
Or are these metrics analyses used to establish the "Fast-speed"
threshold value itself, as defined in the Tor directory spec?


> Which leads to: we want something that takes into account Tor's
> "clients choose relays proportional to their bandwidth" load balancing.
> From your transition text between Figure 3 and Figure 4 it looks
> like you're trying to use bandwidth-per-relay as a stand-in for
> expected-bandwidth-for-the-client, which I think it isn't because clients
> don't select relays uniformly.

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

