Actually, you CAN shape incoming traffic rates with qdisc/tc. The key is to setup a pseudo-device, route incoming traffic first to that pseudo-device then your "real" interface, and attach a queuing discipline to outgoing traffic leaving that pseudo-device.
See: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem#How_can_I_use_netem_on_incoming_traffic.3F And here's another explanation, a little clearer in some parts (but too sparse in others, imho): https://wiki.gentoo.org/wiki/Traffic_shaping -- this approach uses the hierarchical token bucket rather than network emulation - I'm honestly not sure if the HTB approach is better thatn the netem approach. There's documentation out there on other ways to do it, but in a lot of cases those approaches depend on components that never made it into the kernel. -----Original Message----- From: Alfredo Rezinovsky [mailto:[email protected]] Sent: Monday, October 21, 2013 5:56 AM To: [email protected] Subject: EXTERNAL: Re: [squid-users] Bandwith limit El 20/10/13 15:24, Antony Stone escribió: > On Sunday 20 October 2013 at 19:09, Alfredo Rezinovsky wrote: > >> El 20/10/13 13:03, Antony Stone escribió: >>> There's nothing you can do to stop a packet arriving at your router >>> - you can only decide what to do with it afterwards. >> The package arrives to my router but it can be delayed before reaches >> app layer. > Ah, sorry - I had thought that you were asking if it was possible to > limit the bandwidth of traffic coming in over your ISP link. > > Obviously, you can restrict the bandwidth of the connection between > your router and Squid, as you are already doing: > >> I know how to do it with qsdisc in linux. I can queue them and let >> them pass with delay. > If that provides the effect you are seeking, I'd say that is the best > approach. > >> All I want to know is if I can do this with squid. > No, since the receiver can never really control incoming bandwidth. > Only the transmitter can limit the rate data goes over a link (whether > that's your ISP Internet connection, or the hope between your router and > Squid). > > Squid's delay pools can obvious limit the bandwidth from Squid to the > clients, but that's only an indirect way of limiting the bandwidth > from the source into Squid. > > It looks to me like you're doing it the best way possible already. > Delaying the packets arribal to their final destination do limits the incoming bandwith. The packets arribes late, the acks are sent late. TCP flowcontrol takes care of the rest.
