Yes, wow my English was pretty poor in that post, sorry. ;)
I think Im undestanding you :-).
I guess I misunderstood you, sorry. It sounded like you
were suggesting that middle nodes treat such data
differently. I guess you were only referring to exit
nodes then?
Exactly!
Makes sense, if you are suggesting to add prioritization
to exit nodes only. Additionally, I would suggest that
Exactly!
per port (and even destination IP) rate limiting (instead
of prioritization) would be more useful in some cases.
I think it is very similar view to the same problem and it depends on ease of possible implementation. Somebody has plenty of bandwidth and is happy when it is used for tor, but feels that supporting (for example) HTTP is better than torrents. With prioritization / portspeed limits, there wouldnt be a reason to close non-https ports, just to give them slower performance.
For example, prioritization would be good for bittorrent
since it is primarily considered abusive to the tor
netowork, but may well not (opinions on this vary surely)
be used to abuse services outside of tor. Thus, if the
bandwidth is there, why not let tor transport such
traffic since it would not then be hurting tor?
Yep.
Since there are very good legitimate reasons to want to
email anonymously, a very low bandwidth rate for email
might still make it usable for emailing anonymously but
not for SPAM.
Im not sure it will work. When you tight up port 25, there will be the same(similar) amount of spam, but because of speed restriction, there will not be enough connectivity for regular users :-). With priorities, you will be able to handle big amount of request, when your exit will have free capacity.
But in fact, I welcome any method of QoS - both port speed limiting or port priorities. The best is both, of course ;).
In other words, from an anonymity standpoint, it
seems like you would ideally want all exit nodes
to open up every port, even if they drastically
rate limit the 'evil'/abuse oriented ports?
I think it should be better than few high-capacity exits that support these ports.
If you are really creative (and desperate,) ;) you
could probably already achieve port rate limiting
by just running several exit nodes with different
exit policies and bandwidths. And prioritization
and rate limiting could probably both be achieved
by adjusting the bandwith and CPU of the
nodes with some OS parameters, i.e. nice+20 for
CPU and other mechanisms for network usage.
A little bit overhead, isnt it? :-)