From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp141.iad.emailsrvr.com (smtp141.iad.emailsrvr.com [207.97.245.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 466E321F21C for ; Sat, 19 Jan 2013 05:39:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2678E1A03E6; Sat, 19 Jan 2013 08:39:07 -0500 (EST) X-Virus-Scanned: OK Received: from legacy3.wa-web.iad1a (legacy3.wa-web.iad1a.rsapps.net [192.168.2.219]) by smtp24.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id F37D01A027F; Sat, 19 Jan 2013 08:39:06 -0500 (EST) Received: from reed.com (localhost [127.0.0.1]) by legacy3.wa-web.iad1a (Postfix) with ESMTP id DE91821680AC; Sat, 19 Jan 2013 08:39:06 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sat, 19 Jan 2013 08:39:06 -0500 (EST) Date: Sat, 19 Jan 2013 08:39:06 -0500 (EST) From: dpreed@reed.com To: "Maciej Soltysiak" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130119083906000000_76575" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1358602746.910329141@apps.rackspace.com> X-Mailer: webmail7.0 Cc: ju@klipix.org, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] =?utf-8?q?fq=5Fcodel_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 13:39:08 -0000 ------=_20130119083906000000_76575 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ATor should be following the same rules as routers - buffer minimally, si= gnal 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.=0A =0ARemember - using fq_codel in a "home router= " does not fix the real problem in the DOCSIS deployment, nor does it fix t= he 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.=0A =0ABut Tor i= s a system of "routers" (onion-y ones), and its own "software" needs to be = fixed.=0A =0AIs anyone actually fixing the Tor router layer?=0A =0AThat's n= ot sufficient, because the layer 2 below the IP layer *under* Tor will stil= l be bad.=0A =0ABut it may not be worth fixing one layer without fixing the= other.=0A =0ATor's buffering should be studied.=0A =0A-----Original Messag= e-----=0AFrom: "Maciej Soltysiak" =0ASent: Saturday, = January 19, 2013 5:03am=0ATo: "Dave Taht" =0ACc: ju@kl= ipix.org, cerowrt-devel@lists.bufferbloat.net=0ASubject: Re: [Cerowrt-devel= ] fq_codel through Tor=0A=0A=0A=0AFunny you should ask. Being inspired by T= or's Jacob Applebaum's keynote at #29C3 ( [http://isoc-ny.org/p2/4650] http= ://isoc-ny.org/p2/4650 ) I started a tor node. Without throttling the effec= t on my box was similar to bittorrent : instantly dozens of connections con= suming in total 4-5 MB/s inwards and outwards. Observed in iptraf. ssh felt= a bit laggy.=0AI think much depends on your exit a policy. If you allow al= l no port restrictions (default) you might be serving a lot, perhaps even b= it torrent;=0AI saw a headline somewhere about ways to circumvent tor polic= y to run torrents.=0ASO unbloated devices may be keen on unbloating to stil= l live with being generous to tor which is very important for the project a= s the main issue with it is it's slowness.=0AMaciej=0AOn 19 Jan 2013 09:57,= "Dave Taht" <[mailto:dave.taht@gmail.com] dave.taht@gmail.com> wrote:=0A[h= ttps://srv1.openwireless.org/pipermail/tech/2012-December/000332.html] http= s://srv1.openwireless.org/pipermail/tech/2012-December/000332.html=0A=0AI h= aven't the foggiest idea what this traffic would look like. Is it even poss= ible to induce bufferbloat through tor?-- =0ADave T=C3=A4ht=0A=0AFixing buf= ferbloat with cerowrt: [http://www.teklibre.com/cerowrt/subscribe.html] htt= p://www.teklibre.com/cerowrt/subscribe.html =0A____________________________= ___________________=0A Cerowrt-devel mailing list=0A[mailto:Cerowrt-devel@l= ists.bufferbloat.net] Cerowrt-devel@lists.bufferbloat.net=0A[https://lists.= bufferbloat.net/listinfo/cerowrt-devel] https://lists.bufferbloat.net/listi= nfo/cerowrt-devel=0A=0A ------=_20130119083906000000_76575 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= Tor should be following the same rules as routers - buffer minimally, signa= l congestion quickly (by packet drop, ECN, etc. on an end-to-end basis).&nb= sp; I bet it does *not* do the latter at its layer, and I bet the underlyin= g (non Tor) layer does not.

=0A

 =0A

Remember - using fq_codel in a "home = router" does not fix the real problem 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 buff= ers in your cable modem uplink, which are not shared with other users.

= =0A

 

=0A

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

=0A

 

=0A=

Is anyone actually fixing the Tor router l= ayer?

=0A

 

=0A

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

=0A

&n= bsp;

=0A

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

=0A

=  

=0A

Tor's buffering should be stu= died.

=0A

 

=0A

-----Original Message-----
From: "Maciej Soltysiak" &l= t;maciej@soltysiak.com>
Sent: Saturday, January 19, 2013 5:03am
To: "Dave Taht" <dave.taht@gmail.com>
Cc: ju@klipix.org, cerow= rt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] fq_codel t= hrough Tor

=0A
=0A

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 throt= tling 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 i= ptraf. ssh felt a bit laggy.

=0A

I think much depends on your exit a policy. If you allow all no port r= estrictions (default) you might be serving a lot, perhaps even bit torrent;=

=0A

I saw a headline somewh= ere about ways to circumvent tor policy to run torrents.

=0A

SO unbloated devices may be keen on unbloa= ting to still live with being generous to tor which is very important for t= he project as the main issue with it is it's slowness.

=0A

Maciej

=0A
On 1= 9 Jan 2013 09:57, "Dave Taht" <da= ve.taht@gmail.com> wrote:
=0A
https://srv1.openwireless.org/pipermail/tech/2= 012-December/000332.html
=0A
I haven't the foggiest idea what = this traffic would look like. Is it even possible to induce bufferbloat thr= ough tor?
=0A--
Dave T=C3=A4ht

Fixing bufferbloat wit= h cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_____= __________________________________________
Cerowrt-devel mailing list=
Cerowrt-devel@= lists.bufferbloat.net
https://lists.bufferbloat.net/listin= fo/cerowrt-devel

=0A
=0A
 ------=_20130119083906000000_76575--