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
