Re: shaping: dividing bandwidth between router & NAT hosts
> Frankly, use could be anything, available bandwidth could be anything. So I'm
> not seeking a perfect shaping solution but just something to, at least
> somewhat, control usage. And limit usage on the unsecured wireless interface
> too!
The solutions most people use, including me, require you to know the
downstream and upstream bandwidth. If you don't, you can't very well move
the bottleneck to your router, so your shaping won't do anything.
Also, I assume your link is going to be asymmetrical, having much less
upstream bandwidth. So upstream shaping is much more important, and easier
done too. Do that first.
> > If the box that does the shaping is not generating traffic on its own, you
> > can easily do the ingress shaping on the interface to the local network. A
> > requirement for this is that there is only one interface to shape on,
> > if you want borrowing to work.
>
> The router does generate traffic. But assuming that it can be controlled some
> other way: can I then do egress shaping on br0, the LAN interface (eth1, eth2,
> eth3, wlan0)?
Then you need IMQ for ingress shaping.
By the way, it's still ingress shaping even when it's leaving your router to
the internal network. Ingress means "traffic from every other network",
egress means "traffic to every other network". See this awesome diagram:
Network boundary
(
<-- INTERNET ) LAN -->
(
------------
| Router |
| |
------------->------------>----------> ingress traffic to your LAN
| |
<------------<------------<----------- egress traffic from your LAN
| |
------------
)
<-- INTERNET ( LAN -->
)
Yes, some people use the terms 'ingress interface' and 'egress interface'.
Please don't do this, it's confusing when we talk about traffic shaping.
> > If you do ingress shaping, you delay the payload packets from arriving.
> > An ACK packet will be sent only after the packet has made it through to
> > the destination host. This way you can shape UDP too, which does not
> > have easily identifiable ACK packets.
> >
> > The people criticizing ingress shaping point out (correctly) that when
> > you do ingress shaping you are actually delaying packets after they cleared
> > the bottleneck. Indeed, you create an artificial bottleneck, and your
> > overall throughput will be around 10% lower. This sounds wrong, and it is
> > wrong. All that wrongness stems from the fact that you do not have control
> > over the queueing policy at the other end of the bottleneck, where the
> > packets pile up. That side usually has a huge fifo buffer, which delays
> > all packets equally. This is good for throughput and bad for everything else.
> > If that buffer fills up, it can take seconds to establish TCP connections,
> > surfing becomes frustrating. Interactive uses like SSH or VoIP will be nearly
> > impossible. (Sorry, I guess you know that already.)
>
> It seems peculiar that egress delaying on the local interface (of forwarded
> packets) is encouraged but ingress delaying in the WAN interface is 'wrong'.
> Are they not essentially the same thing?
(I'm assuming you mean ingress shaping on either the incoming or the
outgoing interface of the router.)
Yes, they are the same thing. Both are discouraged because your router is
behind the bottleneck and you have only indirect control over what other
people send you. Another diagram:
----\ /---------
THE INTERNET > YOUR ISP === your thin pipe === YOUR LAN
----/ \---------
^ ^
| |
ingress bottleneck your gateway
You see, where the thin pipe starts, ingress packets will pile up. And that
spot is not under your control but under the control of your ISP. If
somebody decides to flood your pipe with packets, there's nothing you can do
about it, because you do not have control over that side of the pipe.
Now most ISP couldn't give a shit about interactivity. They advertise a
certain bitrate, and they will deliver that bitrate. This is best done
by maintaining a huge packet queue. If you want to beat that you have to
move the bottleneck to your gateway, which means lowering throughput by
around 10% compared to the pipe. This way, most implementations figure out
the link is congested before the huge buffer on the remote side starts
filling up. If the remote buffer ever starts filling up, you will get poor
interactivity, period.
Ideally you would fix the remote side. People discouraging you from
doing ingress shaping live in that ideal world where the other side of the
bottleneck is not a huge fifo buffer. If you live in that world you are
living a happier and more productive life.
> I basically have this (a Soekris net5501), but it acts as a wireless AP also;
> four interfaces bridged on the LAN side.
Good. Now if you don't want to patch IMQ into your system, find a
distribution where it's included and use that. I used OpenWRT in the past,
but these days I only do egress shaping which is easily done with stock
Debian.
Reply to: