<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yes, wow my English was pretty poor in that post, sorry. ;)</blockquote>
<div class="Ih2E3d"><br>I think Im undestanding you :-). <br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I guess I misunderstood you, sorry. &nbsp;It sounded like you<br>
were suggesting that middle nodes treat such data<br>
differently. &nbsp;I guess you were only referring to exit<br>
nodes then?<br>
<div class="Ih2E3d"></div></blockquote><div class="Ih2E3d"><br>Exactly! <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Makes sense, if you are suggesting to add prioritization<br>
to exit nodes only. &nbsp;Additionally, I would suggest that</blockquote><div><br>Exactly!<br>&nbsp;<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

per port (and even destination IP) rate limiting (instead<br>
of prioritization) would be more useful in some cases.</blockquote><div><br>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.<br>
</div><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
For example, prioritization would be good for bittorrent<br>
since it is primarily considered abusive to the tor<br>
netowork, but may well not (opinions on this vary surely)<br>
be used to abuse services outside of tor. &nbsp;Thus, if the<br>
bandwidth is there, why not let tor transport such<br>
traffic since it would not then be hurting tor?</blockquote><div><br>Yep. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Since there are very good legitimate reasons to want to<br>
email anonymously, a very low bandwidth rate for email<br>
might still make it usable for emailing anonymously but<br>
not for SPAM.</blockquote><div><br>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.<br>
<br>But in fact, I welcome any method of QoS - both port speed limiting or port priorities. The best is both, of course ;).<br>&nbsp;<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

In other words, from an anonymity standpoint, it<br>
seems like you would ideally want all exit nodes<br>
to open up every port, even if they drastically<br>
rate limit the &#39;evil&#39;/abuse oriented ports?</blockquote><div><br>I think it should be better than few high-capacity exits that support these ports.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you are really creative (and desperate,) ;) you<br>
could probably already achieve port rate limiting<br>
by just running several exit nodes with different<br>
exit policies and bandwidths. &nbsp;And prioritization<br>
and rate limiting could probably both be achieved<br>
by adjusting the bandwith and CPU of the<br>
nodes with some OS parameters, i.e. nice+20 for<br>
CPU and other mechanisms for network usage.</blockquote><div><br>A little bit overhead, isnt it? :-)<br></div></div><br>Marek<br>