Although I respect the theoretical argument that "you can't shape/
limit inbound packets", my observations agree with those of with Karl
that it's simply not true in the real world. If you read my original
posting, I am effectively limiting inbound traffic as far as the user
is concerned (inbound =3D=3D the higher-bandwidth download direction from
the external Internet). Again, that's working quite well already -
whatever mechanism is being used by altq seems completely effective in
doing that, at least in my setup. Bumblebees can actually fly, folks.

In fact what I'm trying to do now is limit the outbound traffic from
the router ( =3D=3D the lower-bandwidth upload direction, TO the external
Internet) which I would think would be easier - as I control the
router and can in theory ( there's that word again...)  shape/limit
either at the point of (a) accepting those packets from the internal,
NATted network interface or (b) sending those same packets out of the
router over the exernal, ADSL-connected interface. That seems very
doable; the question is how to manage it simultaneously with the
download direction when those packets already part of an established,
stateful TCP connection that bypasses the firewall rules.

So while the discussion is interesting, it's not in the least germane
to the original question (a working bi-directional PF ruleset...) I'm
still hoping an example of that is out there

thanks /BP/

On Jan 11, 11:41=A0am, (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. =A0I once
> > promised on this list to setup a test environment and
> > re-prove it but have never gotten around to it and it
> > hardly seems worth bothering.
> We have an observatory that sits on the other side of four bonded T1
> links, and for political reasons, use pf to shape the traffic *only*
> on the observatory end of the link. We shape both inbound and outbound
> traffic; while the outbound traffic is shaped much, much more
> effectively, the shaping we perform on the inbound traffic is an
> improvement over no shaping at all.
> It is only effective for our situation if we deliberately sacrifice a
> fraction of our inbound bandwidth. In our case, the maximum bandwidth
> of the bonded T1 link is 6 megabits/second. Our pf configuration uses
> a maximum bandwidth of 5.5 megabits/second (limit determined empirically)=
> and random early detection to drop packets.
> The other key factor is that the inbound streams we care about tend to
> use much lower bandwidth than whatever it is that's clogging up our
> inbound pipe. If all we cared about was raw throughput, the loss of 10%
> of our total bandwidth may be more of a problem than ungraceful network
> congestion.
> --Kyle

Reply via email to