From owner-freebsd-net@FreeBSD.ORG Fri Jul 29 02:46:01 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DA8216A41F for ; Fri, 29 Jul 2005 02:46:01 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C80743D46 for ; Fri, 29 Jul 2005 02:46:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 13B285E89; Thu, 28 Jul 2005 22:46:00 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61999-01; Thu, 28 Jul 2005 22:45:58 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-54-113.ny325.east.verizon.net [68.161.54.113]) by pi.codefab.com (Postfix) with ESMTP id 212175D64; Thu, 28 Jul 2005 22:45:57 -0400 (EDT) Message-ID: <42E99868.1080306@mac.com> Date: Thu, 28 Jul 2005 22:46:00 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel O'Connor References: <200507290834.10268.doconnor@gsoft.com.au> <200507291035.46770.doconnor@gsoft.com.au> <42E98725.1020600@mac.com> <200507291115.06612.doconnor@gsoft.com.au> In-Reply-To: <200507291115.06612.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-net@freebsd.org, julian@elischer.org Subject: Re: AltQ + ng_iface 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: Fri, 29 Jul 2005 02:46:01 -0000 Daniel O'Connor wrote: > On Friday 29 July 2005 11:02, Chuck Swiger wrote: >> Either the "established" or the "tcpflags !syn,ack" keywords in a rule >> adding matching packets to a high-priority queue ought to do it...? Or >> perhaps you meant something more specific than just "TCP packets with >> TH_ACK" set? :-) > > Hmm, I guess you could make those skip the pipe.. > >> Anyway, I'm not convinced that trying to classify packets within an >> established TCP connection in order to place them on different queues is a >> really good idea, since you're quite likely to reorder the packets by doing >> so. I'd expect both latency and bandwidth of a TCP connection to suffer >> very noticably if more than 10% or so of the packets arrive out of order... > > The theory is that by prioritising outgoing ACKs you don't cause downstream > delays when your upstream is full. eg > http://www.benzedrine.cx/ackpri.html Ah. OK, it makes sense that delaying outgoing ACKs too much would slow things down. So you want to send dataless ACKs at a higher priority than generic big packets full of data, maybe via the "iplen" keyword with "established", look for packets smaller than ~100 bytes? My other thought on this is to wonder about window size and whether that was scaling properly up to a reasonable value, and whether both sides implement a sane network stack, or whether the other side was a windows box looking for quick responses and usage of SACK, rather than BSD (new-reno?) delayed ACKs... >> [ Hmm. I suppose that one could make an exception to the above >> generalization if URG was set, but the TCP stack already makes an effort to >> prioritize and deliver out-of-band urgent stuff as quickly as possible, >> anyway, right? ] > > Maybe, but it doesn't appear to do a particularly good job for a lot of > situations :) I guess. :-) Getting 25% of the hoped-for max performance under a problematic case isn't so horrible, either, but I suspect other factors were involved, too. A tcpdump would've been informative.... -- -Chuck