[LARTC] Napster Upstream Bandwidth Control

[LARTC] Napster Upstream Bandwidth Control

[Peter]

<PRE>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





</PRE>

[LARTC] Napster Upstream Bandwidth Control

[bert]

<PRE>On Sat, Jan 13, 2001 at 12:05:25PM -0500, Peter Frischknecht wrote:

&gt;<i> Okay here it goes.
</I>&gt;<i> 
</I>&gt;<i> I have been fighting this one for a while, and I would like to know if there
</I>&gt;<i> is anybody else out there who shares my pain.
</I>
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.

&gt;<i> Out-User is logged on to Napster:8888 with shared port 6699.
</I>&gt;<i> Out-User wants a file from In-User.
</I>&gt;<i> Out-User tells Napster:8888: go tell In-User.
</I>&gt;<i> Napster:8888 tells In-User: Out-User:6699 wants file x.
</I>&gt;<i> In-User opens a new socket and contacts Out-User:6699.
</I>&gt;<i> Out-User now has a TCP connection to In-User and can receive file x.
</I>
The problem is that you need to recognize, specifically, outbound napster
connections. Would any connection *to* port 6699 be an outgoing napster
connection?

&gt;<i> How am I supposed to stop that?
</I>&gt;<i> Some may say: just slow it down enough so that it is unusable.
</I>&gt;<i> The problem is that if I am DOWNLOADING a song from an Out-User:6699, I have
</I>&gt;<i> to send an acknowledgement packet that has to fight traffic with songs being
</I>&gt;<i> uploaded.  The final effect is that I will get slow downloads as well.
</I>
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.

&gt;<i> I would greatly appreciate any ideas/comments/suggestions... heck I would
</I>&gt;<i> even like getting flamed if it led me to some solution.
</I>
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


</PRE>

[LARTC] Napster Upstream Bandwidth Control

[Peter]

<PRE>&gt;<i> Yes, many of us do. Napster is all good and well, and I wouldn't like to
</I>&gt;<i> prohibit it, but once it starts using sizeable amounts of your bandwidth,
</I>&gt;<i> the fun goes out of it.
</I>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.

&gt;&gt;<i> Out-User is logged on to Napster:8888 with shared port 6699.
</I>&gt;&gt;<i> Out-User wants a file from In-User.
</I>&gt;&gt;<i> Out-User tells Napster:8888: go tell In-User.
</I>&gt;&gt;<i> Napster:8888 tells In-User: Out-User:6699 wants file x.
</I>&gt;&gt;<i> In-User opens a new socket and contacts Out-User:6699.
</I>&gt;&gt;<i> Out-User now has a TCP connection to In-User and can receive file x.
</I>
&gt;<i>The problem is that you need to recognize, specifically, outbound napster
</I>&gt;<i>connections. Would any connection *to* port 6699 be an outgoing napster
</I>&gt;<i>connection?
</I>
You may be onto something.  I just wanted to avoind learning how to read a
tcpdump file to figure this out.

&gt;&gt;<i> How am I supposed to stop that?
</I>&gt;&gt;<i> Some may say: just slow it down enough so that it is unusable.
</I>&gt;&gt;<i> The problem is that if I am DOWNLOADING a song from an Out-User:6699, I
</I>have
&gt;&gt;<i> to send an acknowledgement packet that has to fight traffic with songs
</I>being
&gt;&gt;<i> uploaded.  The final effect is that I will get slow downloads as well.
</I>
&gt;<i>You want to have your cake, and eat it :-) Perhaps you can make it really
</I>&gt;<i>complicated, and exempt ACK packets from accounting? I expect that the u32
</I>&gt;<i>match is up to this. Otherwise, select on large/small packets.
</I>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.

&gt;&gt;<i> I would greatly appreciate any ideas/comments/suggestions... heck I would
</I>&gt;&gt;<i> even like getting flamed if it led me to some solution.
</I>
&gt;<i>I would really like to find a way that enables you to throttle napster
</I>&gt;<i>service, so as to keep it alive, but not kill it.
</I>
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





</PRE>