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