[tor-relays] BitTorrent complaint

[Matt Joyce]

On 12/04/13 15:03, Moritz Bartl wrote:
> On 12.04.2013 13:33, Matt Joyce wrote:
>>>> I assume you mean firewall-based blocking? You could have simply rejected
>>>> those IPs via ExitPolicy (see "man tor"). That's a clear-cut way to tell the
>>>> network you don't accept connections to those IPs, and no risk of being
>>>> labeled a BadExit.
>>> The latter.  I dont know if it complicates routing decisions in the Tor
>>> network to have lots of ip address exceptions at the exits...
>> It possibly does slightly but we are talking about the sort of
>> "complication" that a modern CPU can resolve in timescales short enough
>> I doubt it would make that much difference especially if hash tables
>> were used 
> That's not the issue here. You don't want to make the "routing table"
> (consensus and descriptors) that every Tor client needs to have too
> large. Users in developing countries, on mobile connections or generally
> instable connections already have issues.
>
It would help a lot if we used versioning and stopped sending almost
unchanged data constantly and instead only providing the changes they
are after all text files and there is a whole range of open source
projects out there with the functionality to manage versioning and
incremental updates for text files, the tradeoff of course would be in
the slightly increased disk space requirements for dirmirriors.

That said I'm not arguing that we *should* do this merely that it is
possible and there are technical options to accommodate it if it were
required by enough of the community to pose a potential issue. 
Basically my point is that the it's possible the question therefore more
one of whether we should, I don't particularly see the need and there
are arguments against it I don't like censorship at the best of times
which is why I run the exits I have I am just countering the technical
arguments which I believe are potentially solvable if there was
consensus that it is warranted and therefore are not good reasons to
dismiss the idea.

As for the unstable connections issue, yeah that I can understand that
said tor uses TCP only and TCP is *known* to perform at less than
optimum in the event of unstable connections with random drops, it will
get the data there but it will also do it very slowly interpreting
dropped packets as congestion.  Radio communications frequently cause
TCP to have problems which is why the FAQ for almost any high bandwidth
TCP application will invariably suggest things like "Use a hardwired
connection if possible not wireless".  I'm not dismissing it as an issue
of course but no TCP application is going to work well if the underlying
network infrastructure is poor and I am not sure how that is going to be
solved without A) Replacing TCP with something else (But what?) or B)
Major investment in those networks which is unfortunately unlikely until
there is a large enough user base to create the demand to make someone
with capital actually pay the slightest bit of attention because they
generally are only interested when they can generate a profit.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20130412/2c699011/attachment.pgp>