Bandwidth 'depredation' revisited

Bandwidth 'depredation' revisited

[DervishD]

    Hi all :))

    I've took a look at the documentation related to Traffic Control
and Class Based Queuing, but all of them seems to deal with upload
bandwidth, so it won't solve my problem, which is that wget eats all
my download bandwidth.

    I know: downlink traffic cannot be shaped and Traffic Control is
for data WE send. So, am I missing something? Will my problem be solved
and download bandwidth shared between apps thru Traffic Control or
will I just get better interactive response?

    I think that I'm missing something here, but I'm clueless...

    Thanks in advance :)

    Raúl

Re: Bandwidth 'depredation' revisited

[Anders Fugmann]

When you start a big download, you actually request a server to send as 
much data as possible to you. Quickly, the packet queues on your ISP's 
side gets filled up. If these queues are big (can hold many packets) you 
will see a rather high latency when trying to retrieve replys, since any 
pakcets (incl. ACK) will need first to enter the queue, and wait for 
their turn to be send to you.

The best solution would be to install some sort of traffic shaping on 
the remove side (you ISP), but that is often(/always) not a possible 
solution.

The second best solution is to simple drop packets comming in too 
quickly from the interface. By this, the sending machine will slow down 
transmission. The idea is to keep the queues at you ISP empty.

To do this you can use ingress scheduler.

Something like:
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev etc0 parent ffff: protocol ip prio 50 u32 \
         match ip src 0.0.0.0/0 police \
         rate 232kbit burst 10k drop flowid :1

The downside is, that this actually decreases the maximum download 
speed, but you can really feel the difference.

IIRC, All this was explained in the Advanced-Routing howto.
There is an example in it, which sets the ingress scheduler up. You can 
also take a look at the "wonder shaper" at http://lartc.org/wondershaper/.

Regards
Anders Fugmann

DervishD wrote:
>     Hi all :))
> 
>     I've took a look at the documentation related to Traffic Control
> and Class Based Queuing, but all of them seems to deal with upload
> bandwidth, so it won't solve my problem, which is that wget eats all
> my download bandwidth.
> 
>     I know: downlink traffic cannot be shaped and Traffic Control is
> for data WE send. So, am I missing something? Will my problem be solved
> and download bandwidth shared between apps thru Traffic Control or
> will I just get better interactive response?
> 
>     I think that I'm missing something here, but I'm clueless...
> 
>     Thanks in advance :)
> 
>     Raúl
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Bandwidth 'depredation' revisited

[DervishD]

    Hi Anders :)

>To do this you can use ingress scheduler.

    That's the point... I'll give it a try, then.

>tc qdisc add dev eth0 handle ffff: ingress
>tc filter add dev etc0 parent ffff: protocol ip prio 50 u32 \
>         match ip src 0.0.0.0/0 police \
>         rate 232kbit burst 10k drop flowid :1

    OK. Maybe a stupid question: will I need to mark the packages
with iptables in order to get them thru de ingress scheduler :?

>The downside is, that this actually decreases the maximum download
>speed, but you can really feel the difference.

    Don't worry about that. I'll give it a try and compare results.

>IIRC, All this was explained in the Advanced-Routing howto.

    I missed this part, then. Well, I didn't read deeply the
different shapers...

    Thanks a lot :)
    Raúl

Re: Bandwidth 'depredation' revisited

[Anders Peter Fugmann]

DervishD wrote:
>     Hi Anders :)
> 
>>tc qdisc add dev eth0 handle ffff: ingress
>>tc filter add dev etc0 parent ffff: protocol ip prio 50 u32 \
>>        match ip src 0.0.0.0/0 police \
>>        rate 232kbit burst 10k drop flowid :1
 >
> OK. Maybe a stupid question: will I need to mark the packages
> with iptables in order to get them thru de ingress scheduler :?
>
No. You can, but dont need to. The above lines match anything comming from eth0, and
shapes it to 232kbit. Tweak the value to suit your needs.

Anders Fugmann

Re: Bandwidth 'depredation' revisited

[Marius Gedminas]

On Tue, Jun 11, 2002 at 04:57:58PM +0200, Anders Fugmann wrote:
> tc qdisc add dev eth0 handle ffff: ingress

Does this work with 2.2 kernels?  I've enabled CONFIG_NET_CLS_POLICE,
but tc just barfs

  RTNETLINK answers: No such file or directory

Shaping with CBQ works fine.  Debian Woody, iproute 20010824-8.

Marius Gedminas
-- 
Q:      Why do mountain climbers rope themselves together?
A:      To prevent the sensible ones from going home.

Re: Bandwidth 'depredation' revisited

[Allan Sandfeld Jensen]

On Tuesday 11 June 2002 16:57, Anders Fugmann wrote:
> When you start a big download, you actually request a server to send as
> much data as possible to you. Quickly, the packet queues on your ISP's
> side gets filled up. If these queues are big (can hold many packets) you
> will see a rather high latency when trying to retrieve replys, since any
> pakcets (incl. ACK) will need first to enter the queue, and wait for
> their turn to be send to you.
>
> The best solution would be to install some sort of traffic shaping on
> the remove side (you ISP), but that is often(/always) not a possible
> solution.
>
> The second best solution is to simple drop packets comming in too 
> quickly from the interface. By this, the sending machine will slow down 
> transmission. The idea is to keep the queues at you ISP empty.

You could also just delay trafic from certain IPs. Or even better, you could 
postpone acknowledgedments until you get the right distribution.

I know routers that do the former to gain fair download on shared internet 
connections, but the second would be a lot nicer.

Re: Bandwidth 'depredation' revisited

[Albert D. Cahalan]

Anders Fugmann writes:

> The best solution would be to install some sort of traffic shaping on 
> the remove side (you ISP), but that is often(/always) not a possible 
> solution.
> 
> The second best solution is to simple drop packets comming in too 
> quickly from the interface. By this, the sending machine will slow down 
> transmission. The idea is to keep the queues at you ISP empty.
>
> To do this you can use ingress scheduler.
>
> Something like:
> tc qdisc add dev eth0 handle ffff: ingress
> tc filter add dev etc0 parent ffff: protocol ip prio 50 u32 \
>          match ip src 0.0.0.0/0 police \
>          rate 232kbit burst 10k drop flowid :1

Rather than dropping packets, causing retransmits that
eat into your bandwidth, you could try the new ECN bits.
If you're downloading from a Linux box, it ought to slow
down a bit when you claim to be suffering congestion.

ftp://ftp.isi.edu/in-notes/rfc3168.txt
http://www.faqs.org/rfcs/rfc3168.html
http://www.aciri.org/floyd/ecn.html
http://gtf.org/garzik/ecn/
http://www.tux.org/lkml/#s14-2

Re: Bandwidth 'depredation' revisited

[Anders Peter Fugmann]

Albert D. Cahalan wrote:
> 
> Rather than dropping packets, causing retransmits that
> eat into your bandwidth, you could try the new ECN bits.
> If you're downloading from a Linux box, it ought to slow
> down a bit when you claim to be suffering congestion.
> 

Yes - That would really be ideal.
Do you know how to enable ECN on the ingress filter,
or which filter to use instead?

Anders

Re: Bandwidth 'depredation' revisited

[lkml]

On Tue, 11 Jun 2002 16:57:58 +0200
"Anders Fugmann" <afu@fugmann.dhs.org> wrote:

> To do this you can use ingress scheduler.
> 
> Something like:
> tc qdisc add dev eth0 handle ffff: ingress
> tc filter add dev etc0 parent ffff: protocol ip prio 50 u32 \
>          match ip src 0.0.0.0/0 police \
>          rate 232kbit burst 10k drop flowid :1

Try http://luxik.cdi.cz/~patrick/imq/index.html. Imq allows to shape incomming traffic with egres qdiscs.