Stephan Balmer wrote at 2010-02-11 12:23 -0600: > > 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. 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! > 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)? > > > 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. Okay. > (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. Oh, okay. > 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? > 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. I basically have this (a Soekris net5501), but it acts as a wireless AP also; four interfaces bridged on the LAN side. Thanks for your help!
Attachment:
signature.asc
Description: Digital signature