AltQ + ng_iface

[Chuck Swiger]

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