Date: Fri, 29 Jul 2005 11:14:59 +0930 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Chuck Swiger <cswiger@mac.com> Cc: freebsd-net@freebsd.org, julian@elischer.org Subject: Re: AltQ + ng_iface Message-ID: <200507291115.06612.doconnor@gsoft.com.au> In-Reply-To: <42E98725.1020600@mac.com> References: <200507290834.10268.doconnor@gsoft.com.au> <200507291035.46770.doconnor@gsoft.com.au> <42E98725.1020600@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart6343440.L6ijl0lr0J Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 doi= ng > 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.= =2E. The theory is that by prioritising outgoing ACKs you don't cause downstream= =20 delays when your upstream is full. eg http://www.benzedrine.cx/ackpri.html > [ 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=20 situations :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart6343440.L6ijl0lr0J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC6Yoi5ZPcIHs/zowRAlYcAJ4hQ51+2W0P/0+/6Z38/7s52jXsEwCfWi2I DPe9oZG+gok+zlCRHX2oryA= =WUsS -----END PGP SIGNATURE----- --nextPart6343440.L6ijl0lr0J--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507291115.06612.doconnor>