Re: shaping: dividing bandwidth between router & NAT hosts

Again, I have to stress that ACK packets are only associated with TCP traffic. Many bulk protocols use UDP including many filesharing apps. Prioritizing small outgoing ACK packets keeps upstream saturation from making a impact to download speeds and minimizes retransmissions. Some protocols actually carry a payload with the ACK packets so its important to differentiate between the two. IMQ to my knowledge is the only way to do ingress shaping under linux effectively. If you want examples download dd-wrt and flash a cheapo linksys router. dd-wrt comes with a kernel prepatched with the IMQ support as well as the layer7 patchset. Fire up the ssh service on the unit and take a look at the approach used. I found it very similar to the approach I use with a few small differences. If you want I can supply a few scripts that replicate the HTB class hierarchy.

--
Cory Oldford
PeaceWorks Computer Consulting.
cory@peaceworks.ca

----- Original Message -----
From: "Stephan Balmer" <sb@lia.ch>
To: debian-firewall@lists.debian.org
Sent: Thursday, February 11, 2010 12:23:16 PM GMT -06:00 US/Canada Central
Subject: Re: shaping: dividing bandwidth between router & NAT hosts

Sorry all, I forgot to reply to the list.

> Well, sorry but it could be anything. I may at times have to move the router
> and my only requirements of the connection is that it be reliable, at least say
> 20kilobytes/s, and have a public IP address.

So you'll have low bandwidth and heavy use? Congestion will be a serious
problem? That's enough to know for the moment.

> I would rather not use something controversial, or preferably anything else not
> included in standard Debian squeeze.

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.

If you want ingress shaping to multiple interfaces, there's no way around
controversial solutions, I'm afraid. IMQ is a patchset that allows you to
do shaping over multiple interfaces. This requires patches to the kernel
and the iproute package. I don't know whether there are ready-made solutions
for ACK delaying, I suppose not.

> > Personally I wouldn't delay ACK packets, but prioritise them over other
> > packets. They don't hurt your throughput.
>
> I understand that ACKs won't hurt throughput, but have supposed that delaying
> them would help control downloads. If the sender does not receive an ACK until
> later hopefully they will see a low-bandwidth link and slow down.

It's not the ACK packets that cause the congestion. It is the big packets.
Yes, by delaying ACK packets you can control TCP flow rates, but this is
tricky. It is also specific to TCP.

(Terminology: when I talk about ACK packets I mean empty IP packets with
the ACK flag set.)

> If I prioritize ACKs over other packets, won't that make it even harder to
> control downloads? That is, ACKs go out first so the sender sends faster?

Let's forget about ACK packets for the moment. When I recommended to prioritize
ACK packets I really meant to prioritize small outbound packets like TCP
SYN&ACK packets as well as UDP DNS requests. But that primarly helps when
upstream is congested.

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.)

My recommendation to you:
Get a small dedicated gateway box (I can recommend an ALIX for that) and do
the shaping on the interface to the local network. You can use separate IP
subnets to get groups for shaping. Use IMQ if you have to have
more than one physical interface on the gateway.

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org