On 08/05/2005 05:07:53 PM, Daniel Hartmeier wrote:
On Fri, Aug 05, 2005 at 03:47:57PM -0600, Chris 'Xenon' Hanson wrote:
If the theory is correct, the graphs will nicely show so, and you can
make a nice little web page which we can refer to the next time
someone
argues about rate-limiting inc
Karl O. Pinc wrote:
Well, one paper that the PF FAQ links to says RED does not work.
Oh. I need to look into that. My PF is configured to use it.
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 h
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
the
peer will converge to send at exactl
On 08/05/2005 03:58:09 PM, Daniel Hartmeier wrote:
On Fri, Aug 05, 2005 at 08:48:19PM +, Karl O. Pinc wrote:
> But all this is already true when you've saturated your WAN
> link so there's no harm in trying to shape the traffic anyway.
The comment above was only regards mis-behaving apps
On 08/05/2005 03:43:07 PM, Daniel Hartmeier wrote:
On Fri, Aug 05, 2005 at 06:04:08PM +, Karl O. Pinc wrote:
If I understand it correctly, you're asking whether you could use
route-to loopback and queueing on loopback to queue incoming packets
(on
their way through the firewall) on one ce
Daniel Hartmeier wrote:
I think it's time someone did this in the proper amateurish fashion.
There's complicated theoretical papers and naive guesses, but no nice
middle ground. :)
Good point.
I'd embark on this if I had a spare firewall box and the free time to do the tests. I'd
be very
On Fri, Aug 05, 2005 at 03:47:57PM -0600, Chris 'Xenon' Hanson wrote:
> >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 :)
>
> Exa
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 the
peer will converge to send at exactly that rate through the feed
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 the
peer will converge to send at exactly that rate through the feedback
effects of TCP. Is th
Daniel Hartmeier wrote:
If I understand it correctly, you're asking whether you could use
route-to loopback and queueing on loopback to queue incoming packets (on
their way through the firewall) on one central interface (lo0).
I'm only vaguely understanding the situation myself, so if my sugg
On Fri, 2005-08-05 at 20:44 +, Karl O. Pinc wrote:
> We've been talking TCP here, one can only hope that the applications
> using UDP have some sort of equivalent throttling mechanism.
> Even if not, most of my traffic is TCP.
It's up to each application using UDP whether or not they have a
th
On Fri, Aug 05, 2005 at 08:48:19PM +, Karl O. Pinc wrote:
> But all this is already true when you've saturated your WAN
> link so there's no harm in trying to shape the traffic anyway.
Yes, there is the effect of your TCP peer "backing off" (pausing,
retransmitting, using smaller windows, gen
On Fri, Aug 05, 2005 at 06:04:08PM +, Karl O. Pinc wrote:
> For details see this thread:
> Proposed idiom for inbound queueing on a multi-homed host
> http://marc.theaimsgroup.com/?t=11213940691&r=1&w=2&n=6
If I understand it correctly, you're asking whether you could use
route-to loopbac
On Fri, 5 Aug 2005, Karl O. Pinc wrote:
Au-contrar (sp), if there's a big fat ftp download filling the
pipe I want to drop some of it's packets to favor, for example,
VOIP traffic. But when there's no VOIP traffic I want ftp to be
able to (almost) fill the pipe. So, I start dropping packets _b
On 08/05/2005 01:58:19 PM, Chris 'Xenon' Hanson wrote:
And further, by configuring an interface's sum total max bandwidth
slightly _lower_ than what it is, you leave yourself enough headroom
to start throttling back the data rate on all inbound streams before
you hit the ceiling
That's
On 08/05/2005 02:31:16 PM, Daniel Hartmeier wrote:
Also, if you rely on well-behaved peers getting their throughput cut
by
you for behaving well, you can expect more aggressive applications to
start misbehaving to achieve higher throughput. You're actually
punishing well-behaved peers vs. aggr
On 08/05/2005 11:43:07 AM, Daniel T. Staal wrote:
On Fri, August 5, 2005 12:30 pm, Karl O. Pinc said:
> Hi,
>
> I want to route all inbound WAN traffic to a loopback
> interface so I can try some queueing on inbound traffic
> (to see if I can trade bandwidth for latency).
> But I'm not sure ther
On Fri, Aug 05, 2005 at 12:58:19PM -0600, Chris 'Xenon' Hanson wrote:
> >Think of it this way: Queueing says 'If you need to drop packets, drop
> >these packets before those packets.' That's all it says. And the simple
> >fact is that by the time the packets have reached your external interface
Daniel T. Staal wrote:
Third: Doing so (or doing this) won't help you. By the time the packets
have reached you it no longer matters what queues you set up for them.
Think of it this way: Queueing says 'If you need to drop packets, drop
these packets before those packets.' That's all it says.
On 08/05/2005 11:54:05 AM, Jon Hart wrote:
If you want to queue inbound traffic (LAN->WAN), why not just queue it
when it is heading out on the WAN interface?
I want to queue the traffic coming _in_ from the WAN,
and I want all that traffic in one queue and have
multiple interfaces on the box
On Fri, August 5, 2005 12:30 pm, Karl O. Pinc said:
> Hi,
>
> I want to route all inbound WAN traffic to a loopback
> interface so I can try some queueing on inbound traffic
> (to see if I can trade bandwidth for latency).
> But I'm not sure there's a way to do this
> in conjunction with stateful f
On Fri, Aug 05, 2005 at 04:30:44PM +, Karl O. Pinc wrote:
> Hi,
>
> I want to route all inbound WAN traffic to a loopback
> interface so I can try some queueing on inbound traffic
> (to see if I can trade bandwidth for latency).
> But I'm not sure there's a way to do this
> in conjunction with
Hi,
I want to route all inbound WAN traffic to a loopback
interface so I can try some queueing on inbound traffic
(to see if I can trade bandwidth for latency).
But I'm not sure there's a way to do this
in conjunction with stateful firewalling.
Seems like:
pass in on $internal_if from any to an
On Fri, Aug 05, 2005 at 03:06:19PM +0400, Boris Polevoy wrote:
> In step 2 ioctl(DIOCADDADDR) do not check pool ticket value, and there is
> possible situation of malicious or failure
> address pool addition whithout geting pool ticket from another process.
>
> Is it bug or not?
Yes, I think it
Hello, All!
I found some possible problem in funcion pf_ioctl.c/pfioctl() in FreeBSD
5.4-RELEASE PF.
To add PF rdr (nat) rule in active ruleset we have to do several steps:
1) get pool ticket with ioctl(DIOCBEGINADDRS);
2) create addresses pool with several ioctl(DIOCADDADDR);
3) get ticket for
Hello,
We have installed a OpenBSD/PF Firewall-Cluster with CARP, PFSync and load
balancing for a VOIP-Provider. Since March, it is installed and is running in
a testing environment. If one machine of the cluster is shut down, the
customer will recognize that with a short interruption of his ph
On Tue, Aug 02, 2005 at 11:34:55PM -0500, Kevin wrote:
>
> You can solve this by using tags:
>
> nat on $ext_if inet from any to any tagged aramith -> 69.13.34.94
> . . .
> pass out from any to any user aramith tag aramith
please remember to specify tcp/udp when doing 'user' or
27 matches
Mail list logo
