From owner-freebsd-hackers Wed Nov 26 22:07:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA00920 for hackers-outgoing; Wed, 26 Nov 1997 22:07:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from localhost.zilker.net (jump-x2-1096.jumpnet.com [207.8.67.96]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA00904 for ; Wed, 26 Nov 1997 22:06:58 -0800 (PST) (envelope-from marquard@zilker.net) Received: (from marquard@localhost) by localhost.zilker.net (8.8.8/8.8.3) id XAA16737; Wed, 26 Nov 1997 23:14:41 -0600 (CST) To: freebsd-hackers@freebsd.org Subject: Re: Adaptive scheduling References: From: Dave Marquardt Date: 26 Nov 1997 23:14:09 -0600 In-Reply-To: Charles Mott's message of "Wed, 26 Nov 1997 18:38:41 -0700 (MST)" Message-ID: <85g1oisyu6.fsf@localhost.zilker.net> Lines: 30 X-Mailer: Quassia Gnus v0.17/XEmacs 19.16 - "Lille" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Charles Mott writes: > 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. Does FreeBSD do anything with the IP Type of Service bits? That might be a place to start, given that many Telnet implementations already set certain TOS bits that would indicate interactive traffic. Charles, another place you might look is the IETF RSVP work, and the IETF Integrated Services over Specific Links (or something like that) working group. Most of the discussion I've heard regarding RSVP is only looking at the outgoing packet problem so far, though I can't claim to be deeply involved in RSVP work (I do work on TCP/IP for IBM's AIX, so I do have some knowledge about networking and TCP/IP). The problem with incoming traffic is that it's pretty unpredictable. You may be getting new TCP connections coming in, broadcasts, and IP multicasts (though you generally have to ask for those). If you really want to slow down a remote TCP sender, don't just delay his ACKs, drop several of his packets on the floor :-). Your idea of decreasing the advertised window ought to work also. Sort of a congestion window on the receive side rather than the sending side. I like it. -Dave