Re: altq on inbound traffic

2008-09-11 Thread Anthony Roberts
[EMAIL PROTECTED] :-) Bah. It's still relevant. :) for simple cases yes, but you missed quoting this bit: For example, if there is more than one internal network, one can't create a single altq instance that covers them all. You can divide bandwidth between them, but you can't borrow

Re: altq on inbound traffic

2008-09-09 Thread Toni Mueller
Hi Stuart, On Wed, 03.09.2008 at 22:51:15 +, Stuart Henderson [EMAIL PROTECTED] wrote: Queuing on outbound means the destination sees the packet later, so ACKs _are_ delayed, which is the reason this does actually slow down the sending rate (for TCP, anyway). iow, I need to fiddle with

Re: altq on inbound traffic

2008-09-03 Thread Toni Mueller
Hi, although being unable to implement this, I think that it would be nice to have. But I don't agree with all ideas you presented. On Wed, 05.09.2007 at 00:01:09 -0600, Anthony Roberts [EMAIL PROTECTED] wrote: I've been tuning some networks for VoIP recently, and to get really good results

Re: altq on inbound traffic

2008-09-03 Thread Stuart Henderson
On 2008-09-03, Toni Mueller [EMAIL PROTECTED] wrote: On Wed, 05.09.2007 at 00:01:09 -0600, Anthony Roberts [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] :-) I've been tuning some networks for VoIP recently, and to get really good results I've found it's been necessary to do altq in both

altq on inbound traffic

2007-09-05 Thread Anthony Roberts
I've been tuning some networks for VoIP recently, and to get really good results I've found it's been necessary to do altq in both directions. This has familiarized me with the problems associated with not being able to do altq on inbound traffic. I'm aware of several arguments against doing