On 01/11/2011 01:17:02 PM, Kyle Lanclos wrote: > Karl O. Pinc wrote: > > There are may proofs that throttling TCP works, starting > > with the original paper (Van Jacoson) in 1988 through > > to the many products today that _do_ manage to reserve enough > > inbound bandwidth that, e.g., VOIP works reliably.
> It is only effective for our situation if we deliberately sacrifice a > fraction of our inbound bandwidth. Right. And this becomes especially problematic with low bandwidth connections, or multiple priority levels that slice bandwidth too thinly, where single datagrams of MTU size take significant amounts of the available bandwidth. (FYI, I found ECN to be even better than RED.) In any case, yes, it can be made to work. However if you want to throttle both inbound and outbound I found it easiest to use 2 boxes, one as a bridge, and have each box queue in one direction. (I could have just done all the queuing on the bridge too.) Note that this is only necessary if you've more than 2 interfaces. If there are only 2 then each can do outbound queuing. (As noted in the start of this thread, there may be stateful firewalling issues.) But as soon as one interface is "feeding" 2 others this is no longer a sane approach if you want to have any sort of bandwidth sharing/overflow between the two interfaces "fed". (I hope I'm making sense here.) This is a shame; it'd sure be nice if altq let you do both directions. Perhaps this thread will push things in that direction. I never got around to trying to loop an ethernet cable back into another nic, and setting up 2 routing tables, effectively pretending one box is 2 just to get inbound and outbound queuing on a single piece of hardware. Karl <k...@meme.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein