From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 00:51:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F2671065673 for ; Sun, 2 Mar 2008 00:51:42 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id B26398FC19 for ; Sun, 2 Mar 2008 00:51:41 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m21MmpEd028556 for ; Sun, 2 Mar 2008 09:48:51 +1100 Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m21Mmmmp027403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Mar 2008 09:48:48 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m21MmlvL097850; Sun, 2 Mar 2008 09:48:47 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m21MmlgB097849; Sun, 2 Mar 2008 09:48:47 +1100 (EST) (envelope-from peter) Date: Sun, 2 Mar 2008 09:48:47 +1100 From: Peter Jeremy To: Juri Mianovich Message-ID: <20080301224847.GU67687@server.vk2pj.dyndns.org> References: <754299.92112.qm@web45601.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <754299.92112.qm@web45601.mail.sp1.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: simple, adaptive bandwidth throttling with ipfw/dummynet ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 00:51:42 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 29, 2008 at 02:28:04PM -0800, Juri Mianovich wrote: >"after 30 minutes of maxed dummynet rule, add X mbps >to the rule for every active TCP session, with a max >ceiling of Y mbps" > >and: > >"after 30 minutes of less than max usage, subtract X >mbps from the rule every Y minutes, with a minimum >floor of Z" > >Make sense ? It doesn't really make sense to me but it's your firewall and you are free to implement whatever rules you like. >If I wanted to do this myself with a shell script, is >there any way to test a particular dummynet rule for >its current "fill rate" - OR - a simple way to test if >a particular dummynet rule is currently in enforcement >? The system doesn't maintain stats on the instantaneous "fill rate" of pipes/queues. All it will report is total counts of traffic through and in the pipe/queue. Since the format wasn't clear to me from a quick read of the man page, the following is a breakdown of the output, with added notes: fwall# ipfw pipe list 00001: 6.400 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte= Drp 0 tcp 192.168.123.200/56599 150.101.135.3/61455 122097 6353558 0 = 0 397 |----- dummynet accumulation bucket details -----|---- Totals ---|Queued= | 'dummynet accumulation bucket details' is the details of the most recent (I think) packet matching the specific bucket mask 'Totals' is total bytes and packets through that particular bucket 'Queued' refer to bytes and packets for that bucket currently queued 'Drp' is the number of packets dropped. You would need to calculate a rate by periodically sampling the counts. You can get a rough idea of if a particular dummynet rule is restricting traffic flow by looking for non-zero queued counts (though keep in mind that it is normal for a packet to occasionally be queued). Assuming you have the TCP sessions spread across distinct buckets (either with multiple pipes/queues or with masks to split them up), my suggestion would be a perl script that regularly does 'ipfw pipe list' or 'ipfw queue list' and use change_in_total_bytes/time to calculate average throughput per session. Then use a leaky bucket on the average throughput to trigger pipe/queue re-configurations as desired. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHyd1P/opHv/APuIcRAgo/AJ43YU/rwrVKEztwoV8tMpMZWLf+9ACggQ/T hY52Y7GYc+KKqsGQVPW9/LU= =N6xf -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S--