From owner-freebsd-hackers Wed Nov 26 17:39:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11666 for hackers-outgoing; Wed, 26 Nov 1997 17:39:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA11661 for ; Wed, 26 Nov 1997 17:39:27 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if2-19.ida.net [208.141.171.76]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id SAA08930 for ; Wed, 26 Nov 1997 18:39:18 -0700 Date: Wed, 26 Nov 1997 18:38:41 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: hackers@freebsd.org Subject: Adaptive scheduling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been thinking about writing an engine which would adaptively shcedule packets over a crowded link. The idea would be to schedule packets based on bandwidth consumption, with both stream and source IP address taken into account. The idea is to give the light users good response, but slow down large transfers a little. There might be other scheduling algorithms also. I see this as a type of state based routing in which all data streams are monitored. The idea would be to have a drop-in module similar to what is already done for natd and ppp -alias. It is not that difficult to schedule outgoing packets, but incoming traffic is difficult to control. In the case of tcp streams, one suggestion has been to rewrite the window value on the tcp packets so that holding back ACKs will slow down the incoming stream after about two packets or so. Additionally, it is possible to send icmp source quench packets to try to slow down external sources. I don't know that these mechanisms will work very well, though. I would be interested to hear other ideas on the subject. Charles Mott