All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] even bandwith for users on 2 newtworks
@ 2006-01-15 20:59 Hariett Jones
  2006-01-15 21:42 ` Flemming Frandsen
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: Hariett Jones @ 2006-01-15 20:59 UTC (permalink / raw)
  To: lartc

Server :
eth0 - internet DSL
eth1 - LAN
wlan0 - wireles LAN

I want server to share bandwith from eth0 evenly for users on eth1 and wlan0. How can i make it ? Is it possible ? As far as i know htb splits outgoing bandwith on one device only.

----------------------------------------------------
Grypa? Damy radê! Sprawd¼ jak jej zapowbiegaæ, a je¶li ju¿ za pó¼no
...jak leczyæ - grypa.wp.pl
http://klik.wp.pl/?adr=www.grypa.wp.pl&sidc6


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [LARTC] even bandwith for users on 2 newtworks
  2006-01-15 20:59 [LARTC] even bandwith for users on 2 newtworks Hariett Jones
@ 2006-01-15 21:42 ` Flemming Frandsen
  2006-01-15 23:25 ` Carl-Daniel Hailfinger
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Flemming Frandsen @ 2006-01-15 21:42 UTC (permalink / raw)
  To: lartc

Hariett Jones wrote:
> I want server to share bandwith from eth0 evenly for users on eth1
> and wlan0. How can i make it ? Is it possible ? As far as i know htb
> splits outgoing bandwith on one device only.

This is the most braindead defect of Linux (IMHO): You can't, because
you can only shape outgoing traffic on an interface.

However, some people have found that it works just fine if only Linux 
would allow it, but due to the rule that "You can only shape outgoing 
traffic on an interface" you have to make an intermediate fake device 
where the traffic shaping can take place.

The Intermediate Message Queue (IMQ) is a patch for 2.4 and 2.6 and will 
allow you to take all the traffic coming in from eth0 and pipe it via 
imq0 before routing so you can traffic shape IMQ0.

For kernel 2.6.16 there is a new feature called IFB which does the same 
thing (in this context anyway) as IMQ, so if you can upgrade your 
kernel, then this might be the best choice.




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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [LARTC] even bandwith for users on 2 newtworks
  2006-01-15 20:59 [LARTC] even bandwith for users on 2 newtworks Hariett Jones
  2006-01-15 21:42 ` Flemming Frandsen
@ 2006-01-15 23:25 ` Carl-Daniel Hailfinger
  2006-01-16 11:45 ` Flemming Frandsen
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Carl-Daniel Hailfinger @ 2006-01-15 23:25 UTC (permalink / raw)
  To: lartc

Flemming Frandsen schrieb:
> Hariett Jones wrote:
> 
>> I want server to share bandwith from eth0 evenly for users on eth1
>> and wlan0. How can i make it ? Is it possible ? As far as i know htb
>> splits outgoing bandwith on one device only.
> 
> This is the most braindead defect of Linux (IMHO): You can't, because
> you can only shape outgoing traffic on an interface.

Yes, you can. Easily. And you don't need IMQ/IFB.

eth1->eth0 and wlan0->eth0 are easy. Classical outgoing shaping.
eth0->eth1 and eth0->wlan0 are similar. Outgoing shaping on eth1 and
wlan0 each with a limit of half the incoming bandwidth of eth0.

I had to learn that Linux can perform most of the tasks people claim
are impossible. Some involve a lot of iproute2 trickery and even the
standard Howtos may tell you the problems can't be solved.

However, there are some cases where IMQ/IFB is useful. I don't want
to bash these intermediary devices, they're just abused too many
times.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [LARTC] even bandwith for users on 2 newtworks
  2006-01-15 20:59 [LARTC] even bandwith for users on 2 newtworks Hariett Jones
  2006-01-15 21:42 ` Flemming Frandsen
  2006-01-15 23:25 ` Carl-Daniel Hailfinger
@ 2006-01-16 11:45 ` Flemming Frandsen
  2006-01-16 13:01 ` Alexey Toptygin
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Flemming Frandsen @ 2006-01-16 11:45 UTC (permalink / raw)
  To: lartc

>> This is the most braindead defect of Linux (IMHO): You can't, because
>> you can only shape outgoing traffic on an interface.
>
> Yes, you can. Easily. And you don't need IMQ/IFB.
>
> eth1->eth0 and wlan0->eth0 are easy. Classical outgoing shaping.
> eth0->eth1 and eth0->wlan0 are similar. Outgoing shaping on eth1 and
> wlan0 each with a limit of half the incoming bandwidth of eth0.

This is exactly what I'm doing now, and it's not an optimal solution.

It's a rather stupid hack that gets worse each time you add an interface.

My gatway has 3 internal interfaces and I absolutely detest that I can't
use more than 1/3 of the lines download capacity on each of these three
networks because of the poor design of Linux traffic shaping.

Currently (pre-2.6.16) you can only attach a real traffic shaper to the
the output of a device, but why not allow a traffic shaper to be attached
to the input of a device, without any of the IMQ/IFB nonsense?

I think the problem is that attaching the trafficshaper to the output
queue is easy whereas attaching it to the input is hard as there is no
queue there to build from, so noone bothered to write it.

Luckily we can just upgrade to 2.6.16 at some point and this problem will
mostly be solved.


> However, there are some cases where IMQ/IFB is useful. I don't want
> to bash these intermediary devices, they're just abused too many
> times.

Well, shaping incoming traffic correctly is exactly what IMQ/IFB was
written for, so it's hardly abuse.

-- 
Flemming Frandsen, NrVissing.Net administrator.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [LARTC] even bandwith for users on 2 newtworks
  2006-01-15 20:59 [LARTC] even bandwith for users on 2 newtworks Hariett Jones
                   ` (2 preceding siblings ...)
  2006-01-16 11:45 ` Flemming Frandsen
@ 2006-01-16 13:01 ` Alexey Toptygin
  2006-01-16 21:25 ` Flemming Frandsen
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Alexey Toptygin @ 2006-01-16 13:01 UTC (permalink / raw)
  To: lartc

On Mon, 16 Jan 2006, Flemming Frandsen wrote:

> Currently (pre-2.6.16) you can only attach a real traffic shaper to the
> the output of a device, but why not allow a traffic shaper to be attached
> to the input of a device, without any of the IMQ/IFB nonsense?
>
> I think the problem is that attaching the trafficshaper to the output
> queue is easy whereas attaching it to the input is hard as there is no
> queue there to build from, so noone bothered to write it.

No, attaching to the input is just as easy as to the output. The reason 
that isn't implemented is that it wouldn't really be useful. Say you're 
sharing bandwidth between 2 users, A and B. Suppose A is sending more 
agressively than B; then, you can throw away A's overage packets, giving A 
and B equal shares of your upstream bandwidth. Some LAN bandwidth is 
wasted by A, but this isn't much if A is running a good TCP. No uplink 
bandwidth is wasted.

On the other hand, say A and B are downloading large files, and A's server 
is sending more than B's server. The router at your ISP is going to send 
you whatever gets there first, so that'll mostly be A's traffic. If you 
now shape this on input, you'll be throwing away packets that have already 
gotten to you, and took up downlink bandwidth. By throwing out packets 
going to A, you can make A and B have "fair" shares of the bandwidth; but 
B's share won't actually increase (and A's share will get smaller) unless 
A's server starts sending slower. (This is why A's server should be 
running ECN.)

The only way to do downlink shaping without wasting your bandwidth would 
be at the ISP - the other end of your weakest link to the net. 
Unfortunately, I don't know of any ISP that will do shaping for you.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [LARTC] even bandwith for users on 2 newtworks
  2006-01-15 20:59 [LARTC] even bandwith for users on 2 newtworks Hariett Jones
                   ` (3 preceding siblings ...)
  2006-01-16 13:01 ` Alexey Toptygin
@ 2006-01-16 21:25 ` Flemming Frandsen
  2006-01-16 21:41 ` Peter Surda
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Flemming Frandsen @ 2006-01-16 21:25 UTC (permalink / raw)
  To: lartc

Alexey Toptygin wrote:
> No, attaching to the input is just as easy as to the output. The reason 
> that isn't implemented is that it wouldn't really be useful.

You are full of it.

What everybody who asks for shaping want is mainly ingress shaping and 
it works just fine.

When TCP starts to notice that packets are getting lost it will throttle 
down and transmit slower, just like any non-idiotic protocol, because 
that's the way the Internet works.

You are right that the packets that have already traversed the DSL line 
have consumed bandwidth that can never be reclaimed, but the point is 
that once you start dropping packets then fewer will follow and the 
situation will stabilize.


The fact remains that ingress shaping is immensely useful and that it works.

Linux traffic shaping doesn't support it out of the box (pre 2.6.16) and 
that's because it was hard(er) to implement, not because it's not useful 
it is in the real world.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [LARTC] even bandwith for users on 2 newtworks
  2006-01-15 20:59 [LARTC] even bandwith for users on 2 newtworks Hariett Jones
                   ` (4 preceding siblings ...)
  2006-01-16 21:25 ` Flemming Frandsen
@ 2006-01-16 21:41 ` Peter Surda
  2006-01-17  0:06 ` Carl-Daniel Hailfinger
  2006-01-17 13:27 ` Flemming Frandsen
  7 siblings, 0 replies; 9+ messages in thread
From: Peter Surda @ 2006-01-16 21:41 UTC (permalink / raw)
  To: lartc

Flemming Frandsen schrieb:

> The fact remains that ingress shaping is immensely useful and that it 
> works.

I agree. Ingress shaping, when done properly, is very useful.

According to my experience, one of the main characteristics of traffic 
control (both ingress and egress) is that its effects are often 
counter-intuitive and you only realize it after seeing it in action. The 
"obvious things" turn out to be plainly wrong.

Yours sincerely,
Peter

-- 
http://www.shurdix.org - Linux distribution for routers and firewalls

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [LARTC] even bandwith for users on 2 newtworks
  2006-01-15 20:59 [LARTC] even bandwith for users on 2 newtworks Hariett Jones
                   ` (5 preceding siblings ...)
  2006-01-16 21:41 ` Peter Surda
@ 2006-01-17  0:06 ` Carl-Daniel Hailfinger
  2006-01-17 13:27 ` Flemming Frandsen
  7 siblings, 0 replies; 9+ messages in thread
From: Carl-Daniel Hailfinger @ 2006-01-17  0:06 UTC (permalink / raw)
  To: lartc

Flemming Frandsen schrieb:
> Alexey Toptygin wrote:
> 
>> No, attaching to the input is just as easy as to the output. The
>> reason that isn't implemented is that it wouldn't really be useful.
> 
> 
> You are full of it.

If "it"="knowledge", then you're probably right.

> What everybody who asks for shaping want is mainly ingress shaping and
> it works just fine.
> 
> When TCP starts to notice that packets are getting lost it will throttle
> down and transmit slower, just like any non-idiotic protocol, because
> that's the way the Internet works.
> 
> You are right that the packets that have already traversed the DSL line
> have consumed bandwidth that can never be reclaimed, but the point is
> that once you start dropping packets then fewer will follow and the
> situation will stabilize.
> 
> The fact remains that ingress shaping is immensely useful and that it
> works.
> 
> Linux traffic shaping doesn't support it out of the box (pre 2.6.16) and
> that's because it was hard(er) to implement, not because it's not useful
> it is in the real world.

Please check your facts.
Since you only talk about dropping packets and never about queues, the
following has been available for years in mainline kernels:
http://lartc.org/howto/lartc.adv-filter.policing.html


Regards,
Carl-Daniel
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [LARTC] even bandwith for users on 2 newtworks
  2006-01-15 20:59 [LARTC] even bandwith for users on 2 newtworks Hariett Jones
                   ` (6 preceding siblings ...)
  2006-01-17  0:06 ` Carl-Daniel Hailfinger
@ 2006-01-17 13:27 ` Flemming Frandsen
  7 siblings, 0 replies; 9+ messages in thread
From: Flemming Frandsen @ 2006-01-17 13:27 UTC (permalink / raw)
  To: lartc

>>> No, attaching to the input is just as easy as to the output. The
>>> reason that isn't implemented is that it wouldn't really be useful.
>> You are full of it.
>
> If "it"="knowledge", then you're probably right.

No, I was aiming more for BS.


> Since you only talk about dropping packets and never about queues,

Well, naturally the way to decide what packets to drop is to have it go
though various queues, but in the end it's all about dropping packets.


> the following has been available for years in mainline kernels:
> http://lartc.org/howto/lartc.adv-filter.policing.html

Yes, but that doesn't change the fact that it's useless, there is no way
to set up a HTB tree and assign SFQ's to each leaf like you can on the
outbound traffic.


On my network I have 41 subnets, each a /24 and each subnet needs to get a
fair share of both inboud and outbound bandwidth.

The 41 subnets are accessed from the gateway via 3 different network
interfaces.

Outbound shaping is easy and correct, there is just one HTB tree with an
SFQ for each subnet.

Inbound shaping is ugly and incorrect, because I have to have 3 different
HTB trees (one for each internal interface) that each has to get 1/3
(actually weighted by number of subnets behind each interface) of the
total bandwidth.

That means that max downstream is 800kb/s for the users where it ought to
be 1600kb/s, which sucks because most traffic to the users is very bursty.

It would have been a much nicer design to be able to put the 3 inbound HTB
trees into one inbound tree on the external interface, just like the
outbound tree.


Ingress shaping *is* very useful and it's a pity that Linux has taken this
long to gain support for it.



-- 
Flemming Frandsen, NrVissing.Net administrator.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2006-01-17 13:27 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-15 20:59 [LARTC] even bandwith for users on 2 newtworks Hariett Jones
2006-01-15 21:42 ` Flemming Frandsen
2006-01-15 23:25 ` Carl-Daniel Hailfinger
2006-01-16 11:45 ` Flemming Frandsen
2006-01-16 13:01 ` Alexey Toptygin
2006-01-16 21:25 ` Flemming Frandsen
2006-01-16 21:41 ` Peter Surda
2006-01-17  0:06 ` Carl-Daniel Hailfinger
2006-01-17 13:27 ` Flemming Frandsen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.