i think most of my points are mentioned, indeed
it's just that i was not too familiar with the language
the difference is that my ideas don't break any privacy or network neutrality rules.
they are simply "circuit persistence" (or "transfer length") based (also ip-based at exits), no traffic analysis involved. thus, the disincentive is also more legal: long transfers simply face repeated "reconnection" (or make "reconnection" desirable, by lowering priority).
lowering bandwidth instead of (or in addition to) priority management is a good idea, though
also, my idea is lower-impact, but is less exposed to the arms-race risk mentioned in the pdf (page 5, bottom)
s/but /it /
i am against using "protocol recognition" tools
arma: it's just too... inviting, if you know what i mean
here's what "lower impact" means: basically, we're just shaping everybody's use of tor to resemble web browsing patterns. this means p2peers can still "browse the web" much more heavily than genuine web surfers.
but there's a natural advantage in this: while currently the p2p bastards enjoy better continuity in downloading large files, we poor surfers have to suffer the whole lag/latency before each page starts to load.
so it's just fair to shape tor's traffic patterns to resemble web surfing (and make everything else suffer from the same consequences), because it's the most important protocol, but ironically the most sensitive and always the first victim of abuse
actually i think this is a good design principle ("shape tor's traffic patterns to resemble web surfing") (it shouldn't affect chat and im, i guess)
but are you all AMASSED IN EUROPE? :))