[freenet-dev] Statistics Project Update #4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/24/2012 12:48 PM, Zlatin Balevsky wrote: > The way we dealt with this problem in Gnutella was to cap the max > htl at each hop. Even if an attacker sent a message with very high > htl each node on the path would reduce it to a small value before > forwarding. Not sure if this will work with Freenet. Currently at each hop the HTL is capped to the maximum HTL. Is this what you mean? I can see why you'd want to cap to something smaller then. > can you tell what is the absolutely lowest htl value that will give > "good enough" performance? That's somewhat of an issue: I don't think these number-of-appearance CDFs are a good way to show effectiveness, but I don't know how else to visualize it. > We should discuss this in more detail and have more people involved > before releasing these changes. I can see evanbd's point but the > side effects of very high htl must be taken into account as well. By all means! We're planning to have another review session in #freenet either Friday May 25th shortly after 3:15 BST or sometime Saturday, depending on when toad_ has time. You and any others are very welcome to join the discussion! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPvmoNAAoJECLJP19KqmFu3i8QAI9zCbqpUZGZ+UzBDqYAMQya PSdB/WOWIiuare1FfC8X/IPLC2NzPwZJNLguZJXiaRphJwDWUrKfdlcaav/F1t8U kIQNGcdvNf1SAPpRm/dyo1U6N60bj7J3cMVN2NXWVJdi/qHZmpHj++2Nm0QrEo1g yUmL09v+eZqCjBfDt+S/+wRuppn6zbuUgcLrTtPnlfvj3/3FKjFaJyti4f7LuN97 BzXYfydw6iQmwP6aMIPZ+f/aT7W6T7PXUclnSdQckJi5wl4eoZJ/C2g6AX4CK6Rv RY2zG1wBpXZdoWIoG6jkHU9YrdYHi+kYsBtpQe2qNxznNEOVXlzjpRH69I2Ld831 gEifMIbVAJlEyH1dtDSTrZwjZJCpfl/C+0agCyXTlpWGLoKkKk2od0MwECY4Hw12 egvqIlTuArMD27gohJxAIOiSsgX7Mux7J1GCXuv4R4voMidPuj1JwvVYzIlSHQsO 8pIwFXjGFQLeKtsNTH045vyUeQ0++Lrq1qBTpOZm7XtBfhpB+vzUqHL2IwOdxlGj RiSDLHXpekrjqq+dJju6Iz2jNTJvDZfD/LkdM8lxE83vqinik5hk4DHzb9qR2JER BlPjIxs3jVvVRIiACFy8CShBUuk0jsSYTEAEuyjErPfDPnj9REqg2fdW8Lqe0hiM zcssQFCqgyCFY9HXq6QL =YNFP -END PGP SIGNATURE-
[freenet-dev] Statistics Project Update #4
> > On 05/23/2012 10:47 PM, Zlatin Balevsky wrote: > > On a global scale, the if the rate of new probe requests is higher > > than the rate at which existing ones expire the number of active > > probes at any moment will not reach balance. Higher HTL makes a > > ddos against the probe mechanism easier; in this scenario the > > internal limit of 5 simultaneous probes ends up assisting the > > attacker. > > Good point. I'm not sure what to do to improve that behavior though. I > can add some rate limiting if that looks like it'll be necessary. The way we dealt with this problem in Gnutella was to cap the max htl at each hop. Even if an attacker sent a message with very high htl each node on the path would reduce it to a small value before forwarding. Not sure if this will work with Freenet. > > > Would it be possible to simulate a single-digit HTL network? My > > intuition suggests the graph of effectiveness of probes vs. HTL has > > a logarithmic shape. > > Indeed it is possible to simulate, and that was the subject of my > second update on this project. [1] My main findings are here, [2] > where one can see that it's true that an HTL of 5 or 10 or so could > provide pretty good distribution already. can you tell what is the absolutely lowest htl value that will give "good enough" performance? > > evanbd, my mentor for this project, suggested the maximum HTL of 50. > Here's some of his reasoning from the #freenet logs: > > 2012-05-09: > "So it looks to me from the graphs like HTL 20 is plenty for the new > probes. Which I take to mean we should set the default HTL as at least > 30, possibly 40. Because your nice simulated graphs don't have > problematic behaviors like clustering or partitioning or whatever :) > Basically, I think we should have a fairly high *maximum* HTL (at > least 50), and have the actual HTL be a user-specified parameter." > > 2012-05-19: > "And the plan is to send the requests at < max HTL, assuming that we > don't need the full 50. It looked from graphs like 20 was sufficient, > so I want to send at 30." We should discuss this in more detail and have more people involved before releasing these changes. I can see evanbd's point but the side effects of very high htl must be taken into account as well. -- next part -- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120524/ee685047/attachment.html>
[freenet-dev] Statistics Project Update #4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2012 10:47 PM, Zlatin Balevsky wrote: > On a global scale, the if the rate of new probe requests is higher > than the rate at which existing ones expire the number of active > probes at any moment will not reach balance. Higher HTL makes a > ddos against the probe mechanism easier; in this scenario the > internal limit of 5 simultaneous probes ends up assisting the > attacker. Good point. I'm not sure what to do to improve that behavior though. I can add some rate limiting if that looks like it'll be necessary. > Would it be possible to simulate a single-digit HTL network? My > intuition suggests the graph of effectiveness of probes vs. HTL has > a logarithmic shape. Indeed it is possible to simulate, and that was the subject of my second update on this project. [1] My main findings are here, [2] where one can see that it's true that an HTL of 5 or 10 or so could provide pretty good distribution already. evanbd, my mentor for this project, suggested the maximum HTL of 50. Here's some of his reasoning from the #freenet logs: 2012-05-09: "So it looks to me from the graphs like HTL 20 is plenty for the new probes. Which I take to mean we should set the default HTL as at least 30, possibly 40. Because your nice simulated graphs don't have problematic behaviors like clustering or partitioning or whatever :) Basically, I think we should have a fairly high *maximum* HTL (at least 50), and have the actual HTL be a user-specified parameter." 2012-05-19: "And the plan is to send the requests at < max HTL, assuming that we don't need the full 50. It looked from graphs like 20 was sufficient, so I want to send at 30." Thanks, operhiem1 [1] https://emu.freenetproject.org/pipermail/devl/2012-May/036373.html [2] http://imgur.com/a/Z8SBS#2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPvkPRAAoJECLJP19KqmFubrYQAIhYpXGr/vKjwjVGKHMdyKD4 O+ZQUlrabCBojO6aKAxFNMiTPNlnJTijcylzYcTvtTp/K3jx8IgAC/rIlNDUFBXJ mmM/9DoIVHKdLAtG6MEqFnMZO7xU3UnCijL557gp3beMLNvvJ0akP75xXM6vDJhr dFtxA7yysSgydFk4v+aUYm/JntpRuCEAKgR5XyKOo/KeiXIyv4L0zOhoTc5pbf+N bTqfz2Udx1x/liPNcxaznNhB7oxcAwEZFcTacDc44AJ475T2ta4JUnRwoCbNM+Lb VAXl8ArO1oBqrpy1+2GSivyz4pKNKvU7ItJR6/ok/TX3rePjUNkbYrx92NfidDZ5 vjkc8BR1C2NiGa5gC0PySK40tJYwNnOAnTSYusnSaEIIXE0YrDuM3WXJsyQE2i/v +V88os8J8rIdygzQDsukjD7krCuR0WCJDDalF19NkI+fiCdMF15KbJlWaGYBwtl+ rBeWSdHd9QrtTyZR/721YWOWj9tMUirK0xXKFe1LZh+tIG61xkSBYXZlqbpvbnJv A9UGcvPBIw3tFTel+VR0NsjVhmsbmdyZdxCI8je3lc6y0iDE1IsgvdTWxpK8Ix1R jjIEUcGK+ft7zFKXZx6UGFfezLaDvjX7VrNbCMSReAbz0Go0IuVDv3vY17LTtR2k 4jcYo5sZxYWlDZYPX1Cx =kWS1 -END PGP SIGNATURE-
[freenet-dev] Transport Plugins Update
Hi Chetan, Your changes sound good! At Wed, 23 May 2012 22:30:40 +0530, > The official coding period has started. So after a few more additions > I will merge them to "Transports" branch and begin working on a new > branch "PacketTransports". > Also awaiting some code review, after nextgens becomes free. > > For the coming week- > > 1. Work and finish handleNewTransport > 2. Finish the PeerConnection object > 3. List the changes needed for multiple transport support in PeerNode > (implementing PeerConnection list) > 4. Figure out PeerNode code to use different transports > > Later on I will mainly work on NewPacketFormat which needs to be > changed so that they are more generic for Packet Transports. Hope to > have toad's and zidel's help then. Thanks for the overview! > ArneBab - Flog is coming too. Sorry :) :) No worries. I?ll be glad to see it become more active, but I?ll be mostly disconnected for the next 10 days anyway (we moved and don?t yet have internet in the new home). Best wishes, Arne
Re: [freenet-dev] Statistics Project Update #4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2012 10:47 PM, Zlatin Balevsky wrote: On a global scale, the if the rate of new probe requests is higher than the rate at which existing ones expire the number of active probes at any moment will not reach balance. Higher HTL makes a ddos against the probe mechanism easier; in this scenario the internal limit of 5 simultaneous probes ends up assisting the attacker. Good point. I'm not sure what to do to improve that behavior though. I can add some rate limiting if that looks like it'll be necessary. Would it be possible to simulate a single-digit HTL network? My intuition suggests the graph of effectiveness of probes vs. HTL has a logarithmic shape. Indeed it is possible to simulate, and that was the subject of my second update on this project. [1] My main findings are here, [2] where one can see that it's true that an HTL of 5 or 10 or so could provide pretty good distribution already. evanbd, my mentor for this project, suggested the maximum HTL of 50. Here's some of his reasoning from the #freenet logs: 2012-05-09: So it looks to me from the graphs like HTL 20 is plenty for the new probes. Which I take to mean we should set the default HTL as at least 30, possibly 40. Because your nice simulated graphs don't have problematic behaviors like clustering or partitioning or whatever :) Basically, I think we should have a fairly high *maximum* HTL (at least 50), and have the actual HTL be a user-specified parameter. 2012-05-19: And the plan is to send the requests at max HTL, assuming that we don't need the full 50. It looked from graphs like 20 was sufficient, so I want to send at 30. Thanks, operhiem1 [1] https://emu.freenetproject.org/pipermail/devl/2012-May/036373.html [2] http://imgur.com/a/Z8SBS#2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPvkPRAAoJECLJP19KqmFubrYQAIhYpXGr/vKjwjVGKHMdyKD4 O+ZQUlrabCBojO6aKAxFNMiTPNlnJTijcylzYcTvtTp/K3jx8IgAC/rIlNDUFBXJ mmM/9DoIVHKdLAtG6MEqFnMZO7xU3UnCijL557gp3beMLNvvJ0akP75xXM6vDJhr dFtxA7yysSgydFk4v+aUYm/JntpRuCEAKgR5XyKOo/KeiXIyv4L0zOhoTc5pbf+N bTqfz2Udx1x/liPNcxaznNhB7oxcAwEZFcTacDc44AJ475T2ta4JUnRwoCbNM+Lb VAXl8ArO1oBqrpy1+2GSivyz4pKNKvU7ItJR6/ok/TX3rePjUNkbYrx92NfidDZ5 vjkc8BR1C2NiGa5gC0PySK40tJYwNnOAnTSYusnSaEIIXE0YrDuM3WXJsyQE2i/v +V88os8J8rIdygzQDsukjD7krCuR0WCJDDalF19NkI+fiCdMF15KbJlWaGYBwtl+ rBeWSdHd9QrtTyZR/721YWOWj9tMUirK0xXKFe1LZh+tIG61xkSBYXZlqbpvbnJv A9UGcvPBIw3tFTel+VR0NsjVhmsbmdyZdxCI8je3lc6y0iDE1IsgvdTWxpK8Ix1R jjIEUcGK+ft7zFKXZx6UGFfezLaDvjX7VrNbCMSReAbz0Go0IuVDv3vY17LTtR2k 4jcYo5sZxYWlDZYPX1Cx =kWS1 -END PGP SIGNATURE- ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Statistics Project Update #4
On 05/23/2012 10:47 PM, Zlatin Balevsky wrote: On a global scale, the if the rate of new probe requests is higher than the rate at which existing ones expire the number of active probes at any moment will not reach balance. Higher HTL makes a ddos against the probe mechanism easier; in this scenario the internal limit of 5 simultaneous probes ends up assisting the attacker. Good point. I'm not sure what to do to improve that behavior though. I can add some rate limiting if that looks like it'll be necessary. The way we dealt with this problem in Gnutella was to cap the max htl at each hop. Even if an attacker sent a message with very high htl each node on the path would reduce it to a small value before forwarding. Not sure if this will work with Freenet. Would it be possible to simulate a single-digit HTL network? My intuition suggests the graph of effectiveness of probes vs. HTL has a logarithmic shape. Indeed it is possible to simulate, and that was the subject of my second update on this project. [1] My main findings are here, [2] where one can see that it's true that an HTL of 5 or 10 or so could provide pretty good distribution already. can you tell what is the absolutely lowest htl value that will give good enough performance? evanbd, my mentor for this project, suggested the maximum HTL of 50. Here's some of his reasoning from the #freenet logs: 2012-05-09: So it looks to me from the graphs like HTL 20 is plenty for the new probes. Which I take to mean we should set the default HTL as at least 30, possibly 40. Because your nice simulated graphs don't have problematic behaviors like clustering or partitioning or whatever :) Basically, I think we should have a fairly high *maximum* HTL (at least 50), and have the actual HTL be a user-specified parameter. 2012-05-19: And the plan is to send the requests at max HTL, assuming that we don't need the full 50. It looked from graphs like 20 was sufficient, so I want to send at 30. We should discuss this in more detail and have more people involved before releasing these changes. I can see evanbd's point but the side effects of very high htl must be taken into account as well. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Statistics Project Update #4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/24/2012 12:48 PM, Zlatin Balevsky wrote: The way we dealt with this problem in Gnutella was to cap the max htl at each hop. Even if an attacker sent a message with very high htl each node on the path would reduce it to a small value before forwarding. Not sure if this will work with Freenet. Currently at each hop the HTL is capped to the maximum HTL. Is this what you mean? I can see why you'd want to cap to something smaller then. can you tell what is the absolutely lowest htl value that will give good enough performance? That's somewhat of an issue: I don't think these number-of-appearance CDFs are a good way to show effectiveness, but I don't know how else to visualize it. We should discuss this in more detail and have more people involved before releasing these changes. I can see evanbd's point but the side effects of very high htl must be taken into account as well. By all means! We're planning to have another review session in #freenet either Friday May 25th shortly after 3:15 BST or sometime Saturday, depending on when toad_ has time. You and any others are very welcome to join the discussion! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPvmoNAAoJECLJP19KqmFu3i8QAI9zCbqpUZGZ+UzBDqYAMQya PSdB/WOWIiuare1FfC8X/IPLC2NzPwZJNLguZJXiaRphJwDWUrKfdlcaav/F1t8U kIQNGcdvNf1SAPpRm/dyo1U6N60bj7J3cMVN2NXWVJdi/qHZmpHj++2Nm0QrEo1g yUmL09v+eZqCjBfDt+S/+wRuppn6zbuUgcLrTtPnlfvj3/3FKjFaJyti4f7LuN97 BzXYfydw6iQmwP6aMIPZ+f/aT7W6T7PXUclnSdQckJi5wl4eoZJ/C2g6AX4CK6Rv RY2zG1wBpXZdoWIoG6jkHU9YrdYHi+kYsBtpQe2qNxznNEOVXlzjpRH69I2Ld831 gEifMIbVAJlEyH1dtDSTrZwjZJCpfl/C+0agCyXTlpWGLoKkKk2od0MwECY4Hw12 egvqIlTuArMD27gohJxAIOiSsgX7Mux7J1GCXuv4R4voMidPuj1JwvVYzIlSHQsO 8pIwFXjGFQLeKtsNTH045vyUeQ0++Lrq1qBTpOZm7XtBfhpB+vzUqHL2IwOdxlGj RiSDLHXpekrjqq+dJju6Iz2jNTJvDZfD/LkdM8lxE83vqinik5hk4DHzb9qR2JER BlPjIxs3jVvVRIiACFy8CShBUuk0jsSYTEAEuyjErPfDPnj9REqg2fdW8Lqe0hiM zcssQFCqgyCFY9HXq6QL =YNFP -END PGP SIGNATURE- ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
