-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Paritesh Boyeyoko: > On Friday 01 Nov 2013 14:39:28 Gordon Morehouse wrote: > >> Completely aside from the ethical and censorship-related buzzsaw >> you're about to run into for posting this (perennial) question, I >> believe some actual developers on Tor have written a paper about >> the problems with Bittorrent et al (and I think there's a more >> specific one than the Why Tor Is Slow[1] paper) but I can't >> currently find it. Anybody know? >> >> 1. >> https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf >> >> >> NB: the above paper is from 2009. > > I've just had a quick scan of that paper and it makes for an > interesting read. :) I'm going to go away and read it properly but > a couple observations. And I swear there's a more bittorrent-specific paper but I can't find it. > 2.3 Throttle certain protocols at the client side I agree this is > not a good idea BUT it sparked off another idea in my head. In > order to get better utilisation of slower relays, would it be worth > introducing a behaviour whereby "slow" circuits are deliberately > built for low volume traffic? > > For example, sending email and IM messages doesn't (usually) > require a huge amount of bandwidth, so when the Tor client detects > that a user wants to send/receive data on certain slow ports such > as POP3, IMAP4, MSA and Jabber it deliberately builds a "slow" > circuit to handle that traffic. Obviously it would have to be port > based, but since people tend to send data on well-known ports, it > shouldn't be an issue. That might have at least been thought about, but it's a good idea. It'd also help with better allocating bandwidth offered by "slow" or "fast but at the bottom end" nodes, which I've seen devs in here say they are well aware is not optimally allocated. > > I think this would play well with the circuit-bonding work here > > http://freehaven.net/anonbib/#pets13-splitting > > > 3.1.2 Better Support for relay operators This caught my eye: "We > lose relays when the operator reboots and forgets to set up the > relay to start on boot." Does installing the .deb package (for > example) not configure Tor to start on boot, in the same way that > Apache would be? I ask because I haven't rebooted my VPS yet. :p I've not seen this with .debs, but Windows? If so, maybe the "restart on reboot?" dialog - if there is one, and not a hidden checkbox - should be front and center when opting to relay traffic. > 3.1.3 Facebook app to show off your relay I liked this bit: > "Opportunities for expansion include allowing relay operators to > form âteamsâ, and for these teams to be ranked on the contribution > to the network. (Real world examples here include the SETI > screensaver and the MD5 hash crack challenges.)" I'd go for an embeddable badge, first. Then maybe a Facebook app. It's only a hunch, but I think we'd get a lot more mileage out of an embeddable badge (for web sites, tumblr, and anything else tumblr-like that allows embedding) than out of a Facebook app, though if there were time, money and spoons[1] to do both, I'd certainly do both with the Facebook thing coming second. Well, maybe. Nobody should be on Facebook, least of all anybody who is running Tor for the right reasons, but we have reality to contend with here. My hunch is based on demographics, BTW. :P > What would be really interesting would be to find sponsors (read: > hosters) willing to put their name to it and gain/risk some > publicity. Start by asking XMission, GANDI and maybe even (though they don't do VPS) NearlyFreeSpeech.net if this ever happens. Also, dig back into news articles about industry response to the NSA wiping its butt with the Fourth Amendment, and see which VPS providers were yelling the loudest, especially the mom-n-pop to mid-tier providers. $.02. Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSdnZyAAoJED/jpRoe7/uj0ywH/3c9d5uTsVJWtSkwd/YSuVpU +Q5Az2Wd1Pes45z8Zx/fRtvhlJ7/qtZloXxVyDLg7KjUjJktiCgJaDO7j8mw9/NO S5W2JFHtr8j8AukDdMzCpocD06O1Chhq7cmq+DzdZji+jENR2iB4jbKzvNNkVCNg duAiPnNPiEl/6m5ViiFuO38P+qag0nNN4lnnOnHcvodXfmU4Qxgzd/zwEoKpF0ET qKOmb3zKsxF3bqq1Ab2+hLafhdkJYThOszbJuiCwA+q+D94lDIJ5nFftq4lhWqN2 WcGASJpzOLR9CnkykMPiTYHVuM2RZZWTEeVlN10eAynpzO9qeNYFHk2KTeUoZsY= =Owji -----END PGP SIGNATURE-----
Attachment:
0x1EEFFBA3.asc
Description: application/pgp-keys
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays