Okay here it goes. I have been fighting this one for a while, and I would like to know if there is anybody else out there who shares my pain. I run medium size LANs (150-450 nodes) for apartment complexes and provide them with internet access. You can bet your hat on what consumes(ed) most of may bandwidth: Napster. I have been very successfull in curbing all of the DOWNLOAD speeds, but I am having a hard time with the UPLOADS. So you say: just block any NEW, INBOUND connections... well, unless you have pleyed with it, you would not know that it isn''t that simple. You see, when an internal user has his Napster shared port set to 6699 (an example). Upon a logon to the Napster servers, any outside user who wants to get songs from my internal user has to stablish a direct connection to my internal user. This scenario I can prevent. However, if the internal user has his Napster port set to 0, the Napster server will broker the song upload so that it actualy initiates in my network. Specificaly, by observing the logged pakets of a file transfer, this is what happens: In-User is logged on to Napster:8888 with shared port 0. Out-User is logged on to Napster:8888 with shared port 6699. Out-User wants a file from In-User. Out-User tells Napster:8888: go tell In-User. Napster:8888 tells In-User: Out-User:6699 wants file x. In-User opens a new socket and contacts Out-User:6699. Out-User now has a TCP connection to In-User and can receive file x. Well... What now? How am I supposed to stop that? Some may say: just slow it down enough so that it is unusable. The problem is that if I am DOWNLOADING a song from an Out-User:6699, I have to send an acknowledgement packet that has to fight traffic with songs being uploaded. The final effect is that I will get slow downloads as well. I don''t claim to know everything about bandwidth control, but I have been having great success with packet Marking (iptables) and tc. It has resolved 99% of all my bandwidth issues. My setup is roughly 4 months old and I feel confortable enough with it to start creating a Web Interface for my purposes. I would greatly appreciate any ideas/comments/suggestions... heck I would even like getting flamed if it led me to some solution. Peter Frischknecht
On Sat, Jan 13, 2001 at 12:05:25PM -0500, Peter Frischknecht wrote:> Okay here it goes. > > I have been fighting this one for a while, and I would like to know if there > is anybody else out there who shares my pain.Yes, many of us do. Napster is all good and well, and I wouldn''t like to prohibit it, but once it starts using sizeable amounts of your bandwidth, the fun goes out of it.> Out-User is logged on to Napster:8888 with shared port 6699. > Out-User wants a file from In-User. > Out-User tells Napster:8888: go tell In-User. > Napster:8888 tells In-User: Out-User:6699 wants file x. > In-User opens a new socket and contacts Out-User:6699. > Out-User now has a TCP connection to In-User and can receive file x.The problem is that you need to recognize, specifically, outbound napster connections. Would any connection *to* port 6699 be an outgoing napster connection?> How am I supposed to stop that? > Some may say: just slow it down enough so that it is unusable. > The problem is that if I am DOWNLOADING a song from an Out-User:6699, I have > to send an acknowledgement packet that has to fight traffic with songs being > uploaded. The final effect is that I will get slow downloads as well.You want to have your cake, and eat it :-) Perhaps you can make it really complicated, and exempt ACK packets from accounting? I expect that the u32 match is up to this. Otherwise, select on large/small packets.> I would greatly appreciate any ideas/comments/suggestions... heck I would > even like getting flamed if it led me to some solution.I would really like to find a way that enables you to throttle napster service, so as to keep it alive, but not kill it. Regards, bert hubert -- PowerDNS Versatile DNS Services Trilab The Technology People ''SYN! .. SYN|ACK! .. ACK!'' - the mating call of the internet
> Yes, many of us do. Napster is all good and well, and I wouldn''t like to > prohibit it, but once it starts using sizeable amounts of your bandwidth, > the fun goes out of it.Well... I believe that I can say that we are still afloat even with Napster enabled. My only loophole is this upload mechanism. The latest beta from Napster has port 0 as the default.>> Out-User is logged on to Napster:8888 with shared port 6699. >> Out-User wants a file from In-User. >> Out-User tells Napster:8888: go tell In-User. >> Napster:8888 tells In-User: Out-User:6699 wants file x. >> In-User opens a new socket and contacts Out-User:6699. >> Out-User now has a TCP connection to In-User and can receive file x.>The problem is that you need to recognize, specifically, outbound napster >connections. Would any connection *to* port 6699 be an outgoing napster >connection?You may be onto something. I just wanted to avoind learning how to read a tcpdump file to figure this out.>> How am I supposed to stop that? >> Some may say: just slow it down enough so that it is unusable. >> The problem is that if I am DOWNLOADING a song from an Out-User:6699, Ihave>> to send an acknowledgement packet that has to fight traffic with songsbeing>> uploaded. The final effect is that I will get slow downloads as well.>You want to have your cake, and eat it :-) Perhaps you can make it really >complicated, and exempt ACK packets from accounting? I expect that the u32 >match is up to this. Otherwise, select on large/small packets.Well, you may have a good idea. I can do that with iptables as well... I had not though about that... I will give it a try. I will post the results later.>> I would greatly appreciate any ideas/comments/suggestions... heck I would >> even like getting flamed if it led me to some solution.>I would really like to find a way that enables you to throttle napster >service, so as to keep it alive, but not kill it.You can. I have gone through several attempts, but this seems to be the winner. I have a single T1. I allocate 1Mbit in to 2 bands: FTP/NEWS , and Napster (and all other Napster Like apps). I give each band 500Kbit but they can borrow from each other. For web browsing, they are force-feed trough a transparent proxy and its throttle is controlled internally (besides, the packet comes IN to Squid gets unwrapped rewrapped and OUT to the user without traversing the forward chain making it difficult to throuttle) with delay pools (another way too cool bandwidth management system). It is working great. I am certain you will find a happy medium for yourself as well. Thank you Peter Frischknecht