Re: [LARTC] Question about how TC enforces bandwidth limiting

[Vadtec <vadtec@vadtec.net>]

Martin A. Brown wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Good morning,
>
>  : I ran "tc filter" on the command line, but received no output in 
>  : return. I read the man page and it leads me to believe that it's 
>  : not meant for viewing the filters.
>
> Depends, but yes, the "tc filter" output is not necessarily 
> attractive.  You can classify with "tc filter" instead of iptables, 
> but if you reach your goal, it doesn't matter which mechanism you 
> use to classify your packets.
>   
Can you provide a simple example of how to filter with tc rather than 
iptables? Just enough of an idea
for me to grasp it on my own. I think it would be better to use tc to do 
the filtering rather than iptables,
as thats what tc is meant to do.
>  : One thing I did notice was, while I did see traffic in class 100 
>  : for the first time, my torrent client still showed outgoing 
>  : bandwidth of more than 20kbit.
>
> Well, a typical torrent client will use a number of connections.  
> Perhaps some of the connections are classified correctly and some 
> are not?
>   
One thing I had failed to take into account was the possibility that bit 
torrent *may* be using some UDP
ports. In an attempt to test this theory, I added the udp filters to 
iptables and watched the data stream.
No change. -_- Bit torrent is still showing outgoing speeds of above 
20k. So, I then limitted the filter
to the LAN IP for my router box and forced my torrent client to use that 
IP. Still above 20k. Long story
short, I tried about 5 different things to get it to work properly. No 
luck. I think part of the problem is that
my torrent client doesn't seem to honor the port ranges I put into 
effect. Which would definitely allow traffic
to get past it.
>  : Is this simply a function of the router actually limiting the 
>  : traffic and the torrent client simply not knowing? Or (and I 
>  : assume this is incorrect thinking) should the torrent client 
>  : visibly indicate to me that it can only send at X rate because 
>  : its limited?
>
> I would expect the torrent client to be reporting the actual 
> speed(s), so I would expect it to be reporting 20kbit rates.
>   
As would I.
>  : To make this much simpler, I will paste my tc rules and iptables 
>  : rules (which classify my traffic) at the bottom of this e-mail. I 
>  : hope you can find something (related specifically to bit torrent) 
>  : that will allow me to limit torrent traffic without the need to 
>  : limit each client by hand.
>
> You are getting there.
>
>  : So I am at a total loss as to why (outgoing) SSH traffic would 
>  : become so slow, because it has access to more bandwidth than 
>  : torrent (at least in my thinking).
>
> Are you sure that it's outgoing SSH traffic that is slow?  Consider 
> the following scenario:
>
>   * your outgoing queues are configured completely correctly
>   * outgoing ssh IP packet gets into correct queue
>   * inbound return IP packet from ssh server is delayed inbound
>     because you are not shaping downstream traffic
>
> So, before you conclude that your shaping isn't working, I think 
> you'll need to apply some sort of mechanisms also on your internal 
> interface.
>   
Bah, I need to figure out outgoing before I mess with incoming. I'm 
liable to cut my self off
from the internet. :P
> Snipped iptables classification.  Nothing looks fishy to me there 
> (though I haven't used the iptables CLASSIFY target).
>
>  : $IFext is of course eth0 (link to the modem), $QUANTUM is 1490 
>  : (due to, if I assume correctly, my MTU being 1492, in the modem), 
>  : $MAX_RATE is 360kbit (360kbps conventional talk)
>
> I wouldn't set quantum unless you need to do so.  HTB will calculate 
> this for you.  If you do need to set the quantum, I'd recommend 
> setting it just a bit larger than the MTU...so 1500 or 1536 in your 
> pppoe situation.
>   
Ok, quantum has always been 1512 for me, so I assume tc is taking care 
of it.
> Good luck,
>
> - -Martin
>
> - -- 
> Martin A. Brown
> http://linux-ip.net/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)
>
> iD8DBQFG3Vd1HEoZD1iZ+YcRAv0pAKDZ0qtpxyOkGJJQ7H5rWtFi3HlM2gCgrugd
> WyARMeCjVI9TD/1CcTTDAsw> =RKrP
> -----END PGP SIGNATURE-----
>
>   
So, I am at a total loss as to why this isn't working. Well, not a total 
loss, but enough of a total loss
as to disable some of the shaping I had been using  that was giving me 
fits. I think it's much better for
me to let the default class handle everything and go from there for now.

As I said above, can you provide a simple example of how to filter with 
tc? I think filtering in tc will be
both more appropriate and less hassling.

I really appreciate you taking the time to help me with this. I am by no 
means a noob to networking,
but when it comes to traffic shaping, I might as well be. Though, on a 
positive note, at least I've been able
to properly shape some traffic, like IRC. :) (I'm also going to contact 
the developers of my torrent client
and ask them about port range limiting. And why it doesn't seem to be 
working.)

Thanks again,


Vadtec
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc