> P2P tools receive many small packets from everywhere. Those many packets > clog the connection and need to be throttled BEFORE they cross the > bottleneck of your uplink. (I'm aware that's not really possible on a > standard DSL connection) I did say that he needs to rate-limit SYN segments. Those inbound packets are generated in response to an outbound SYN. Stop the SYN and you stop the inbound traffic. He's NAT'ing, so there are no inbound connections to worry about.
=20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Basically there is no solution to stop these? Is that what you are = saying? Do other p2p programs produce these short SYN packages, or just = KaZaa? I am studying the traffic in my lan with tcpdump and i get lots = of packages like this coming to my inner interface : =09 19:14:50.866190 XXX.XXX.XXX.XXX.1101 > YYY.YYY.YYY.YYY.80: . ack 14594 = win 64240 (DF) Being XXX my internal users and YYY external public addresses What are those? Response to ack packages right? I also have lots of 19:19:26.676651 YYY.YYY.YYY.YYY.80 > XXX.XXX.XXX.XXX.4078: . = 10220:11680(1460) ack 1 win 17121 (DF) Is it posible that kazaa uses ACK packages to send data? Because these = packages are comming to my lan with the MTU=E7 - -----Mensaje original----- De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En = nombre de David Boreham Enviado el: viernes, 16 de mayo de 2003 18:24 Para: lartc@mailman.ds9a.nl Asunto: Re: [LARTC] No way to shape my traffic with p2ps > P2P tools receive many small packets from everywhere. Those many=20 > packets clog the connection and need to be throttled BEFORE they cross = > the bottleneck of your uplink. (I'm aware that's not really possible=20 > on a standard DSL connection) I did say that he needs to rate-limit SYN segments. Those inbound packets are generated in response to an outbound SYN. Stop = the SYN and you stop the inbound traffic. He's NAT'ing, so there are no inbound connections to worry about. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl = http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBPsUQen7diNnrrZKsEQIFYwCgrkfbFNnnPgcnYdjBZq+OF062BOYAoJdG DVPhhHhfynSKz0HuD44GdkPE =3DK0xm -----END PGP SIGNATURE-----
On Friday 16 May 2003 18:23, GoMi wrote: > Basically there is no solution to stop these? Is that what you are saying? > Do other p2p programs produce these short SYN packages, or just KaZaa? I am > studying the traffic in my lan with tcpdump and i get lots of packages like > this coming to my inner interface : > > 19:14:50.866190 XXX.XXX.XXX.XXX.1101 > YYY.YYY.YYY.YYY.80: . ack 14594 win > 64240 (DF) Being XXX my internal users and YYY external public addresses > > What are those? Response to ack packages right? > > I also have lots of > > 19:19:26.676651 YYY.YYY.YYY.YYY.80 > XXX.XXX.XXX.XXX.4078: . > 10220:11680(1460) ack 1 win 17121 (DF) Is it posible that kazaa uses ACK > packages to send data? Because these packages are comming to my lan with > the MTU Erik sended me some shaping tricks : http://www.docum.org/stef.coene/qos/faq/cache/49.html Quote : "ACK packets are usually very small, so putting them into a high-priority class is no problem. However, ACK packets can also cary a payload, and some indeed do so. Especially uploads in Kazaa tend to be all large ACK packets." Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net
Ricardo Jorge da Fonseca Marques Ferreira
2003-May-17 16:23 UTC
No way to shape my traffic with p2ps
On Friday 16 May 2003 18:46, Stef Coene wrote: > > Erik sended me some shaping tricks : > http://www.docum.org/stef.coene/qos/faq/cache/49.html > Quote : > "ACK packets are usually very small, so putting them into a high-priority > class is no problem. However, ACK packets can also cary a payload, and some > indeed do so. Especially uploads in Kazaa tend to be all large ACK > packets." This is also true for emule. When giving priority to ACKs i have to specify the size of the packet or else it'll match all of emule's upload.