From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D106721F20C for ; Sat, 19 Jan 2013 08:42:26 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id k10so7941791iea.29 for ; Sat, 19 Jan 2013 08:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Mrl1d3mWOE3/Ygo4uQCu634MYLbz2L7X+tWOCrz/UZI=; b=om7lvQptMnor9ft6DPCEMPeCsVLyZLypv62fR9vB0bTM8hVSoOZF8aPSKK5ttf03Nu hvTkNOJs9Cc2oBFaDWJLxl4rZhyXnwkNTHm2pqvVYzQ8mj8Nc5WzotlIA2Vo/PbWuQf3 MLFA7vVFgrrCTBoH/HBliv4GegpACLmc2eeCmwoCNcDVzw07refBPJho28mtmzF9K67C q8av8WEbPSM8Nv5BiXL7cWZV6YC7JUW9efwC3aFnohojfImCTGLjpe2kgWh5QhSOJrcl l/HbsLSWQXIWUw82iDscs9nb6EWoiNCQQnpAU2IQv0QdpZ+I2/r7RHlHBEJhKuxdt4Qd C6Iw== MIME-Version: 1.0 X-Received: by 10.50.196.164 with SMTP id in4mr4954619igc.86.1358613745971; Sat, 19 Jan 2013 08:42:25 -0800 (PST) Received: by 10.64.135.39 with HTTP; Sat, 19 Jan 2013 08:42:25 -0800 (PST) In-Reply-To: <1358602746.910329141@apps.rackspace.com> References: <1358602746.910329141@apps.rackspace.com> Date: Sat, 19 Jan 2013 11:42:25 -0500 Message-ID: From: Dave Taht To: dpreed@reed.com Content-Type: multipart/alternative; boundary=14dae93405c9b731f904d3a6e956 Cc: cerowrt-devel@lists.bufferbloat.net, ju@klipix.org Subject: Re: [Cerowrt-devel] fq_codel through Tor X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 16:42:27 -0000 --14dae93405c9b731f904d3a6e956 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jan 19, 2013 at 8:39 AM, wrote: > Tor should be following the same rules as routers - buffer minimally, > signal congestion quickly (by packet drop, ECN, etc. on an end-to-end > basis). I bet it does *not* do the latter at its layer, and I bet the > underlying (non Tor) layer does not. > > > > Remember - using fq_codel in a "home router" does not fix the real proble= m > in the DOCSIS deployment, nor does it fix the real problem in the LTE > deployment. By fixing the "outgoing rate" less than the "service rate", > you just never use (hopefully) the buffers in your cable modem uplink, > which are not shared with other users. > > > > But Tor is a system of "routers" (onion-y ones), and its own "software" > needs to be fixed. > > > > Is anyone actually fixing the Tor router layer? > > > > That's not sufficient, because the layer 2 below the IP layer *under* Tor > will still be bad. > > > > But it may not be worth fixing one layer without fixing the other. > > > > Tor's buffering should be studied. > Agreed. Tor qualifies as pretty interesting traffic. It would be my hope, however, that with a rate shaper on and fq_codel on top of that, that you'd hardly notice it was there, if you were acting as a relay, and if you used it yourself, except for laggy things like dns. In looking through their full transparent proxy stuff, https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy It looks like that, and polipo and the tor build I already have in cero is enough to do some serious fiddling with tor https://trac.torproject.org/projects/tor/wiki/doc/CentralizedTorServer Hmm. I wonder what TFO does to tor's notions... Anyway: I'm not terribly interested in routing all traffic through it personally, but I wouldn't mind setting up a redirect for .onion domains, and routing .onion through tor to (for example) setup test web servers on various sides of the onion to observe what happens. and... Can something like netperf get run through it? > > -----Original Message----- > From: "Maciej Soltysiak" > Sent: Saturday, January 19, 2013 5:03am > To: "Dave Taht" > Cc: ju@klipix.org, cerowrt-devel@lists.bufferbloat.net > Subject: Re: [Cerowrt-devel] fq_codel through Tor > > Funny you should ask. Being inspired by Tor's Jacob Applebaum's keynote > at #29C3 ( http://isoc-ny.org/p2/4650 ) I started a tor node. Without > throttling the effect on my box was similar to bittorrent : instantly > dozens of connections consuming in total 4-5 MB/s inwards and outwards. > Observed in iptraf. ssh felt a bit laggy. > > I think much depends on your exit a policy. If you allow all no port > restrictions (default) you might be serving a lot, perhaps even bit torre= nt; > > I saw a headline somewhere about ways to circumvent tor policy to run > torrents. > > SO unbloated devices may be keen on unbloating to still live with being > generous to tor which is very important for the project as the main issue > with it is it's slowness. > > Maciej > On 19 Jan 2013 09:57, "Dave Taht" wrote: > >> https://srv1.openwireless.org/pipermail/tech/2012-December/000332.html >> I haven't the foggiest idea what this traffic would look like. Is it eve= n >> possible to induce bufferbloat through tor? >> -- >> Dave T=E4ht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --14dae93405c9b731f904d3a6e956 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jan 19, 2013 at 8:39 AM, <dpreed= @reed.com> wrote:

Tor should b= e following the same rules as routers - buffer minimally, signal congestion= quickly (by packet drop, ECN, etc. on an end-to-end basis).=A0 I bet it do= es *not* do the latter at its layer, and I bet the underlying (non Tor) lay= er does not.

=A0

Remember - using fq_codel in a "home r= outer" does not fix the real problem in the DOCSIS deployment, nor doe= s it fix the real problem in the LTE deployment.=A0 By fixing the "out= going rate" less than the "service rate", you just never use= (hopefully) the buffers in your cable modem uplink, which are not shared w= ith other users.

=A0

But Tor is a system of "routers" = (onion-y ones), and its own "software" needs to be fixed.

=A0

Is anyone actually fixing the Tor router la= yer?

=A0

That's not sufficient, because the laye= r 2 below the IP layer *under* Tor will still be bad.

=A0

But it may not be worth fixing one layer wi= thout fixing the other.

=A0

Tor's buffering should be studied.

<= /font>

Agreed. Tor qualifies as pretty inte= resting traffic. It would be my hope, however, that with a rate shaper on a= nd fq_codel on top of that, that you'd hardly notice it was there, if y= ou were acting as a relay, and if you used it yourself, except for laggy th= ings like dns.

In looking through their full transparent proxy stuff,= =A0


It looks like that, and polipo and the tor build I alre= ady have in cero is enough to do some serious fiddling with tor
<= br>

Hmm. I wonder what TFO does to tor's notions...

Anyway:

I'm not terribly= interested in routing all traffic through it personally, but I wouldn'= t mind setting up a redirect for .onion domains,
=A0and routing .onion through tor to (for example) setup test web serv= ers on various sides of the onion to observe what happens.=A0
and...

Can something like netperf get = run through it?



=A0

-----Original Message-----
From: "M= aciej Soltysiak" <maciej@soltysiak.com>
Sent: Saturday, January 19, 2013 5= :03am
To: "Dave Taht" <dave.taht@gmail.com>
Cc: ju@klipix.org, cerowrt-devel@lists.bufferbloat.net=
Subject: Re: [Cerowrt-devel] fq_codel through Tor

Funny you should ask. Being ins= pired by Tor's Jacob Applebaum's keynote at #29C3 ( http://isoc-ny.org/p2/4650 ) = I started a tor node. Without throttling the effect on my box was similar t= o bittorrent : instantly dozens of connections consuming in total 4-5 MB/s = inwards and outwards. Observed in iptraf. ssh felt a bit laggy.

I think much depends on your ex= it a policy. If you allow all no port restrictions (default) you might be s= erving a lot, perhaps even bit torrent;

I saw a headline somewhere abou= t ways to circumvent tor policy to run torrents.

SO unbloated devices may be kee= n on unbloating to still live with being generous to tor which is very impo= rtant for the project as the main issue with it is it's slowness.

Maciej

On 19 Jan 2013 09:57, "Dave Taht" <= dave.taht@gmail.co= m> wrote:
https://srv1.openw= ireless.org/pipermail/tech/2012-December/000332.html
I haven't the foggiest idea what this traffic would look like. Is = it even possible to induce bufferbloat through tor?
--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.tek= libre.com/cerowrt/subscribe.html
__________________________________= _____________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel




=
--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://w= ww.teklibre.com/cerowrt/subscribe.html=20 --14dae93405c9b731f904d3a6e956--