Re: altq on inbound traffic
[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 between the different queues in this case. What he said. 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). I think the larger concern is that those methods aren't really applicable beyond TCP, even if it's TCP tunneled over UDP/proto 41/whatever. Everything understands dropped packets. :) -Anthony
Re: altq on inbound traffic
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 the flow of ACKs to assign incoming bandwidths, but can do so with the current software. Right? Kind regards, --Toni++
Re: altq on inbound traffic
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 I've found it's been necessary to do altq in both directions. This should imho be possible to look at what kind of traffic goes out of one interface, then write appropriate altq rules. For a router, which seems to be what you're talking about, (almost) all traffic that enters the router on one side, leaves it on some other side. That way, each packet needs to traverse one interface in the outgoing direction. -Hosts cannot be prevented from sending me packets, so the potential exists for inbound bandwidth to be exausted no matter what I do. Right, but for TCP at least, you could, in theory, employ window scaling, delaying ACKs, and ECN to make the other side send their packets at a slower rate. This should work unless the other side is broken, or simply a rogue site. I don't know how much overhead such a mechanism will introduce, though. Kind regards, --Toni++
Re: altq on inbound traffic
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 directions. This should imho be possible to look at what kind of traffic goes out of one interface, then write appropriate altq rules. For a router, which seems to be what you're talking about, (almost) all traffic that enters the router on one side, leaves it on some other side. That way, each packet needs to traverse one interface in the outgoing direction. 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 between the different queues in this case. -Hosts cannot be prevented from sending me packets, so the potential exists for inbound bandwidth to be exausted no matter what I do. Right, but for TCP at least, you could, in theory, employ window scaling, delaying ACKs, and ECN to make the other side send their packets at a slower rate. This should work unless the other side is broken, or simply a rogue site. I don't know how much overhead such a mechanism will introduce, though. 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).
