[LARTC] 2 Questions on filtering incoming stuff

[LARTC] 2 Questions on filtering incoming stuff

[Ed Wildgoose]

Two easy questions after having read the LARTC HOWTO document (which by 
the way is a *fantastic* document.  Congratulations to all who contributed!)

First is: Can I prioritise my "drops" on incoming traffic when the link 
is overloaded.  ie instead of just tail dropping, can I "prefer" to drop 
certain classes of traffic?  If so, do I do this by setting up, say, a 
HTB tree like on the incoming, but the only action at the leaf is to drop?

Second: Theoretically now....  There appears to be no way to tweak 
"window length" to throttle incoming data... But in theory, would a 
module which delayed the outgoing ACK's have the same effect?  Obviously 
this module would need some sort of packet accounting ffrom the incoming 
interface in order to supply the outgoing filter with the info it needed 
(not even sure if this design makes it hard to implement such a 
thing?).  Fast and selective acks and timeouts, obviously make this very 
hard to implement as well...

However, the main point is that I don't really understand the process by 
which linux (and other OSs) discover the steady state speed of a link?  
Anyone got a good pointer to how "slow start" and "fast start" work, and 
how it adjusts speed through time? 

Thanks

Ed W
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] 2 Questions on filtering incoming stuff

[Andy Furniss]

Ed Wildgoose wrote:
> Two easy questions after having read the LARTC HOWTO document (which by 
> the way is a *fantastic* document.  Congratulations to all who 
> contributed!)
> 
> First is: Can I prioritise my "drops" on incoming traffic when the link 
> is overloaded.  ie instead of just tail dropping, can I "prefer" to drop 
> certain classes of traffic? 

Yes - you would queue before dropping.

  If so, do I do this by setting up, say, a
> HTB tree like on the incoming, but the only action at the leaf is to drop?
> 

You attach a queue to the leaf, which may drop.

> Second: Theoretically now....  There appears to be no way to tweak 
> "window length" to throttle incoming data... But in theory, would a 
> module which delayed the outgoing ACK's have the same effect?

Queueing has much the same effect.

   Obviously
> this module would need some sort of packet accounting ffrom the incoming 
> interface in order to supply the outgoing filter with the info it needed 
> (not even sure if this design makes it hard to implement such a 
> thing?).  Fast and selective acks and timeouts, obviously make this very 
> hard to implement as well...
>

Throttling by rwin manipulation would be nice - but complicated.

> However, the main point is that I don't really understand the process by 
> which linux (and other OSs) discover the steady state speed of a link?  
> Anyone got a good pointer to how "slow start" and "fast start" work, and 
> how it adjusts speed through time?

It's tcp that finds the limits. There are many docs out there like

www.jessingale.dsl.pipex.com/tcp-noureddine02transmission.pdf

Andy.


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] 2 Questions on filtering incoming stuff

[Damion de Soto]

Hi Ed,
> First is: Can I prioritise my "drops" on incoming traffic when the link 
> is overloaded.  ie instead of just tail dropping, can I "prefer" to drop 
> certain classes of traffic?  If so, do I do this by setting up, say, a 
> HTB tree like on the incoming, but the only action at the leaf is to drop?
You can't set up a HTB or any classful qdiscs on incoming traffic, you can only 
create ingress policer filters.  You can setup different filters with different 
priorities, to try and drop one particular type of traffic moreso than others.

If you're using a linux gateway onto your lan, then you can use a HTB qdiscs
on the outgoing (lan) interface which would do a better job.

regards

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer  email:     damion@snapgear.com
SnapGear - A CyberGuard Company ---    ph:         +61 7 3435 2809
  | Custom Embedded Solutions          fax:         +61 7 3891 3630
  | and Security Appliances            web: http://www.snapgear.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] 2 Questions on filtering incoming stuff

[Andreas Klauer]

Am Monday 17 May 2004 23:31 schrieb Ed Wildgoose:
> First is: If so, do I do this by setting up, say, a HTB tree like on the
> incoming, but the only action at the leaf is to drop?

Probably with IMQ. Another way would by modifying your ingress filters, so 
that they don't match packets you don't want to drop in any case. However, 
this introduces new complications (for example, rate limiting works only 
for packets the filter actually matches).

> There appears to be no way to tweak "window length" to throttle incoming
> data...

Dunno. I'd like to hear all about it if there is.

Andreas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] 2 Questions on filtering incoming stuff

[Ed Wildgoose]

Damion de Soto wrote:

> Hi Ed,
>
>> First is: Can I prioritise my "drops" on incoming traffic when the 
>> link is overloaded.  ie instead of just tail dropping, can I "prefer" 
>> to drop certain classes of traffic?  If so, do I do this by setting 
>> up, say, a HTB tree like on the incoming, but the only action at the 
>> leaf is to drop?
>
> You can't set up a HTB or any classful qdiscs on incoming traffic, you 
> can only create ingress policer filters.  You can setup different 
> filters with different priorities, to try and drop one particular type 
> of traffic moreso than others.


Thanks, this is helpful. 

Thinking about it though, the different filters priorities isn't going 
to help too much?  eg if I want to accept ACK's, then incoming SMTP, 
then other bulk downloads, then of course I can setup prioritised 
"bands" by limiting some stuff more than others.  But I don't think that 
a simple priority system will let me accept up to full bandwidth of 
each, but dropping in a preferential order?  (Or do you think simply 
matching each with a 200Kb/s filter in priority order from highest to 
lowest will do the trick?)

> If you're using a linux gateway onto your lan, then you can use a HTB 
> qdiscs
> on the outgoing (lan) interface which would do a better job.


Sure.  Same problem for local traffic on that machine though. 

However, can you apply filters to aliased IP addresses, ie the virtual 
interfaces eth0:1?  Do the filters only apply to the real interfaces 
(which I think is true of iptables for example?)  This might also be 
useful for setting up a bandwidth filter PC using only a single net card 
for example (assuming you don't worry about people bypassing it manually)

Thanks

Ed W

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] 2 Questions on filtering incoming stuff

[Damion de Soto]

Ed,
> Thinking about it though, the different filters priorities isn't going 
> to help too much?  eg if I want to accept ACK's, then incoming SMTP, 
> then other bulk downloads, then of course I can setup prioritised 
> "bands" by limiting some stuff more than others.  But I don't think that 
> a simple priority system will let me accept up to full bandwidth of 
> each, but dropping in a preferential order?  (Or do you think simply 
> matching each with a 200Kb/s filter in priority order from highest to 
> lowest will do the trick?)
No, i don't think this will work very well in practice at all.
it'll be better than nothing though.

> Sure.  Same problem for local traffic on that machine though.
Yes... which leads to using the IMQ device as Andreas said.
> However, can you apply filters to aliased IP addresses, ie the virtual 
> interfaces eth0:1?  Do the filters only apply to the real interfaces 
> (which I think is true of iptables for example?)
There are no 'aliased' IP addresses.  This is just legacy ifconfig notation.
All IP addresses are treated the same on an interface - so yes.

> This might also be useful for setting up a bandwidth filter PC using only a single net card 
> for example (assuming you don't worry about people bypassing it manually)
Yeah, i've wondered if you could do that and get it working.

regards,

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer  email:     damion@snapgear.com
SnapGear - A CyberGuard Company ---    ph:         +61 7 3435 2809
  | Custom Embedded Solutions          fax:         +61 7 3891 3630
  | and Security Appliances            web: http://www.snapgear.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] 2 Questions on filtering incoming stuff

[Ed Wildgoose]

>>> First is: Can I prioritise my "drops" on incoming traffic when the 
>>> link is overloaded.  ie instead of just tail dropping, can I 
>>> "prefer" to drop certain classes of traffic?  If so, do I do this by 
>>> setting up, say, a HTB tree like on the incoming, but the only 
>>> action at the leaf is to drop?
>>
>>
>> You can't set up a HTB or any classful qdiscs on incoming traffic, 
>> you can only create ingress policer filters.  You can setup different 
>> filters with different priorities, to try and drop one particular 
>> type of traffic moreso than others.
>
>
> Thanks, this is helpful.
> Thinking about it though, the different filters priorities isn't going 
> to help too much?  eg if I want to accept ACK's, then incoming SMTP, 
> then other bulk downloads, then of course I can setup prioritised 
> "bands" by limiting some stuff more than others.  But I don't think 
> that a simple priority system will let me accept up to full bandwidth 
> of each, but dropping in a preferential order?  (Or do you think 
> simply matching each with a 200Kb/s filter in priority order from 
> highest to lowest will do the trick?)


Aha, just seen that you can setup HTB filters on incoming if you use the 
IMQ filter.  This looks like it will do the trick.  (See ADSL Bandwidth 
HOWTO for details)

Will play with that first. 

I still think it might be an interesting project for someone to use the 
IMQ filter to record incoming bandwidth, and then delay outgoing 
ACK's...  Presumably one would need to have a queue of incoming packets 
and sizes available from the incoming interface, then watch ack's coming 
back and take them out of the queue (just like a real TCP stack).  
However, you then rate limit the speed at which they are removed.  Of 
course it gets more complicated with respect to non selective ACK's and 
retransmits from the source side...  It would reduce the amount of 
bandwidth due to retransmits anyway...

Thanks all
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] 2 Questions on filtering incoming stuff

[Ed Wildgoose]

>> This might also be useful for setting up a bandwidth filter PC using 
>> only a single net card for example (assuming you don't worry about 
>> people bypassing it manually)
>
> Yeah, i've wondered if you could do that and get it working.


Yeah, I have a very limited implementation of this "working" right now.  
The problem is that there is no concept of direction on a single interface.

I think that it could be bodged by creating a 100mbit queue with a small 
ADSL sized queue underneath, and using iptables to redirect to the 
actual classes based on source and dest ip (ie you keep stuff on the 
network in the 100mbit queue and just limit the stuff with a non local 
source address.  In the same way I guess I could also rate limit 
incoming stuff from the net using the IMQ attached to incoming device, 
and iptables only bringing in external traffic to the queue..

Can't see any reason why it wouldn't work, but hey, I only read the 
HOWTO and haven't tried it yet...

I wonder what can be attached to TAP/TUN devices though?  Sure would be 
useful to have a virtual net card so that you can acquire "direction" 
from a single physical card.

In my case I am interested because I am thinking about misusing this PC 
to do both traffic shaping, and perhaps run a few net services under 
usermode-linux.  The usermode sessions need to be shaped as well.

Thanks

Ed W
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/