From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Message-Id: <200206140335.g5E3ZhF370974@saturn.cs.uml.edu>
Subject: Re: Bandwidth 'depredation' revisited
To: afu@fugmann.dhs.org (Anders Fugmann)
Date: Thu, 13 Jun 2002 23:35:43 -0400 (EDT)
Cc: raul@pleyades.net (DervishD), linux-kernel@vger.kernel.org (Linux-kernel)
In-Reply-To: <3D060FF6.5000409@fugmann.dhs.org> from "Anders Fugmann" at Jun 11, 2002 04:57:58 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

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

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