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. [email protected] ----- Original Message ----- From: "Stephan Balmer" <[email protected]> To: [email protected] 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
