AltQ + ng_iface
julian at elischer.org
Fri Jul 29 03:05:35 GMT 2005
Chuck Swiger wrote:
> 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
>>> very noticably if more than 10% or so of the packets arrive out of
>> The theory is that by prioritising outgoing ACKs you don't cause
>> downstream delays when your upstream is full. eg
> 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?
I do this to great effect..
two sites connected by links in which teh bottleneck is 200KB/sec (1 E1?)
when a lot of data is flowing from 1 to 2 then data from 2 to 1 is also
down because the acks have to go through the queues on ingress side of the
I add a dummynet entry on 1, limiting output to 190KB/sec, so that the queue
is in dummynet and not the intermediate router, and then allow small ack
to bypass that queue. As a result the data from 2 to 1 also flows at
and with a much lower latency. SInce data flows tend to be large packets,
I sometimes actually prioitise ALL small packets allowing interactive
bypass ftps etc. and sometimes I do it on both ends.
> 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....
More information about the freebsd-net