[OpenWrt-Devel] Evenly distribute bandwidth for users?

[Nguyễn Hồng Quân]

Hello,

I'm looking for how to make the OpenWrt router automatically distribute
bandwidth for users. For example, one user is downloading a big file and
slow down Internet speed for others. I want to limit that downloading.

I looked into QoS, but it seems that I have to specify a user (IP) to
apply rule on. What I want is that the system can do this automatically.

Is there any package available for this need?

Thank you.

[David Goodenough]

Post by Nguyễn Hồng Quân
Hello,
I'm looking for how to make the OpenWrt router automatically distribute
bandwidth for users. For example, one user is downloading a big file and
slow down Internet speed for others. I want to limit that downloading.
I looked into QoS, but it seems that I have to specify a user (IP) to
apply rule on. What I want is that the system can do this automatically.
Is there any package available for this need?
Thank you.

Look at the tc command, it can be used to enforce fair-share distribution
of resources. Remember you need it at both ends of the link that you are
sharing (each end only regulates what it sends, not what it receives).

David

[e***@free.fr]

Hi

http://wiki.openwrt.org/doc/howto/packet.scheduler/packet.scheduler

----- Mail original -----
De: "Nguyễn Hồng Quân" <***@mbm.vn>
À: "OpenWrt Development List" <openwrt-***@lists.openwrt.org>
Envoyé: Vendredi 11 Janvier 2013 10:43:24
Objet: [OpenWrt-Devel] Evenly distribute bandwidth for users?

Hello,

I'm looking for how to make the OpenWrt router automatically distribute
bandwidth for users. For example, one user is downloading a big file and
slow down Internet speed for others. I want to limit that downloading.

I looked into QoS, but it seems that I have to specify a user (IP) to
apply rule on. What I want is that the system can do this automatically.

Is there any package available for this need?

Thank you.

[Brian J. Murrell]

Post by e***@free.fr
Hi
http://wiki.openwrt.org/doc/howto/packet.scheduler/packet.scheduler

Note that OP described wanting to distribute "download" bandwidth for
users. The document you posted above is about shaping "upload" bandwidth.

As the above document states, one cannot really "shape" download
bandwidth but can only "police" it by dropping packets as they come in,
and then, that only works for TCP and not UDP.

b.

[Sebastian Moeller]

Hi there,

Post by Brian J. Murrell

Post by e***@free.fr
Hi
http://wiki.openwrt.org/doc/howto/packet.scheduler/packet.scheduler

Note that OP described wanting to distribute "download" bandwidth for
users. The document you posted above is about shaping "upload" bandwidth.
As the above document states, one cannot really "shape" download
bandwidth but can only "police" it by dropping packets as they come in,
and then, that only works for TCP and not UDP.

I wonder about whether that is actually right. Looking at the definitions of shaping and policing it is quite clear that in the real world any shaper will also police (and if only by virtue of limited buffers at one point packets will be dropped, turning a shaper into a policer). Adding a shaper to san ingress policer offers the following advantage: the developing queue, especially if the queueing is per flow or close to per flow (as in a number of different queueing disciplines available) will give the policing component more information to pick which packets to fro or mark. Thus in the real world shaping can be considered, as a fancy way of policing, so any shaper will fall back being a policer (worst case scenario all buffers are filled and a new packet arrives).
Neither shapeing nor only policeing will be able to help against an inelastic UDP flood on the downstream. Especially if said flood consumes all link's bandwidth so even if the receiver drops all UDP packages no real traffic will make it through the bottleneck. This can only be solved on the head-end of the downstream; but inelastic UDP traffic is quite uncommon outside of DOS attacks, so this has nothing to do with the question of to shape or not to shape.
Where shaping will help is if several (longer-running) TCP flows compete the downlink, then shaping can help to distribute the speeds of these individual flows to "fairly" share the downstream bandwidth (depending on your shaper setup and definition of fair).
All of these facts (if actually) true seem to make the argument for using a shaper not a policer even on the remote end of a "bottle-neck" link like a typical cable/dsl/lte connection. Now, I could be just full of it, so please show me where my reasoning is off, and why policing is better than shaping.

best
Sebastian

Post by Brian J. Murrell
b.
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[Nguyễn Hồng Quân]

Thank you all,
I'm reading carefully, because I don't understand at first :)

Regards

Post by Sebastian Moeller
Hi there,

Post by Brian J. Murrell

Post by e***@free.fr
Hi
http://wiki.openwrt.org/doc/howto/packet.scheduler/packet.scheduler

Note that OP described wanting to distribute "download" bandwidth for
users. The document you posted above is about shaping "upload" bandwidth.
As the above document states, one cannot really "shape" download
bandwidth but can only "police" it by dropping packets as they come in,
and then, that only works for TCP and not UDP.

I wonder about whether that is actually right. Looking at the definitions of shaping and policing it is quite clear that in the real world any shaper will also police (and if only by virtue of limited buffers at one point packets will be dropped, turning a shaper into a policer). Adding a shaper to san ingress policer offers the following advantage: the developing queue, especially if the queueing is per flow or close to per flow (as in a number of different queueing disciplines available) will give the policing component more information to pick which packets to fro or mark. Thus in the real world shaping can be considered, as a fancy way of policing, so any shaper will fall back being a policer (worst case scenario all buffers are filled and a new packet arrives).
Neither shapeing nor only policeing will be able to help against an inelastic UDP flood on the downstream. Especially if said flood consumes all link's bandwidth so even if the receiver drops all UDP packages no real traffic will make it through the bottleneck. This can only be solved on the head-end of the downstream; but inelastic UDP traffic is quite uncommon outside of DOS attacks, so this has nothing to do with the question of to shape or not to shape.
Where shaping will help is if several (longer-running) TCP flows compete the downlink, then shaping can help to distribute the speeds of these individual flows to "fairly" share the downstream bandwidth (depending on your shaper setup and definition of fair).
All of these facts (if actually) true seem to make the argument for using a shaper not a policer even on the remote end of a "bottle-neck" link like a typical cable/dsl/lte connection. Now, I could be just full of it, so please show me where my reasoning is off, and why policing is better than shaping.
best
Sebastian

Post by Brian J. Murrell
b.
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

--
Regards,
Quân

Y!IM: ng_hquan_vn
GTalk: ng.hong.quan

[Ben West]

You may also want to look at tools like Coovachilli, wifidog, and
nodogsplash if you want to constrain upload/download bandwidth for
individual DHCP clients. These are the tools commonly used to manage
bandwidth on public wifi hotspots.

http://wiki.openwrt.org/doc/howto/wireless.hotspot
http://wiki.openwrt.org/doc/howto/wireless.hotspot.wifidog
http://wiki.openwrt.org/doc/howto/wireless.hotspot.nodogsplash
http://www.coova.org/CoovaChilli

Note that Coovachilli would require a RADIUS server running somewhere else
in the cloud. However, do please note that RADIUS configuration is rarely
'plug-n-play,' and well outside the scope of this listserv. By comparison,
wifidog and nodogsplash are stand-alone.

QoS is more typically used to set device-wide bandwidth policies, less so
per-user policies.

Post by Nguyễn Hồng Quân
Hello,
I'm looking for how to make the OpenWrt router automatically distribute
bandwidth for users. For example, one user is downloading a big file and
slow down Internet speed for others. I want to limit that downloading.
I looked into QoS, but it seems that I have to specify a user (IP) to
apply rule on. What I want is that the system can do this automatically.
Is there any package available for this need?
Thank you.
--
Regards,
Quân
Y!IM: ng_hquan_vn
GTalk: ng.hong.quan
______________________________**_________________
openwrt-devel mailing list
https://lists.openwrt.org/**mailman/listinfo/openwrt-devel<https://lists.openwrt.org/mailman/listinfo/openwrt-devel>