[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using state and routing inbound traffic

On 08/05/2005 04:33:32 PM, Daniel Hartmeier wrote:
Ah, I think I get what you mean. You don't want to rate-limit your
outgoing replies to achieve this effect on incoming traffic. Instead,
you simply rate-limit the incoming traffic to some rate X, assuming
peer will converge to send at exactly that rate through the feedback
effects of TCP. Is that it?

Yup, you got it.

I'm not sure how well this works in practice. The TCP mechanisms are
designed to achieve this, but the convergence of the rate is not
immediate and perfect. The sender will regularly try to increase its
rate (think of a perfectly normal case where you start a download
slowly, because of other concurrent downloads, and the download gets
faster as the other downloads are complete), and it reacts rather
drastically to any lost packets. So there are bursts in the stream the
server sends, and there's feedback effects. TCP window sizes, window
scaling and SACK all affect this.

Right. Which is why I keep wondering if somebody's tried it.

Recall, there's two goals which the above TCP rate limiting
is supposed to aid acheiving.  The first is to allow traffic
prioritizaton.  The second is to allow for more rapid convergence
of multiple streams of equal priority to equal bandwidth
utilization.  By allowing a little "slop" bandwidth in the
low bandwidth link side you get more packets in the pipe
sooner, so long as the firewall can un-borrow some bandwidth
from traffic of lower priority.  While you may not be able
to get 'true' prioritization all the time, you should at
least be able to meet the goal of rapid convergence most
of the time, because you're bound to have some "slop"
bandwidth in your low bandwidth link side.

We're certainly not the first ones discussing this, there must be
volumes of papers about dynamics of TCP like these, maybe someone can
comment on whether this simple strategy is supposed to work like that

Well, one paper that the PF FAQ links to says RED does not work. I get the feeling that these sort of network dynamics are going to be quite variable and the best thing to do is just try something out and see how it works, or model your specific situation if you know enough about it to be able to do so.

Karl <[email protected]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein