Patrick McHardy writes: > I don't think this is a good example. > Why use SFQ for only SYNs ? Ok, use pfifo instead. > What if the Synflood lasts longer / your connection request happens > during the synflood ? It will expire like the others. I wasn't trying to solve the flooding problem in this example. (As it turns out, I am trying to solve that problem, and this is related to that subject, but I won't go into details here. Anyone who wants to know more should see http://www.cs3-inc.com/ddos.html) > Syncookies provide a much better protection against synfloods, you won't > have to wait at all. Ok, change syn to ping. > I think maybe we misunderstood. > What i want to achieve is that flows respond more quickly to changes in > available bandwidth. In the case of tcp this adjustment happens automatically because the acks slow down (or speed up). It's much better for tcp to adjust the rate without having to drop. > > I don't think I understand what you're proposing. If we enqueue 50 > > packets from one flow all at once, and after sending 10 they all > > expire (since they're all about the same age), then you want to drop > > one? Why is it worth sending the rest? > > I don't want to drop unneccasary much. If i drop the first one, the > sender will receive notification of congestion as soon as possible and > slow down. But i haven't put very much thought in this so it will > probably not work like this. Dropping has a pretty drastic effect on tcp. If the communicating tcp's support various features, dropping one packet might not cause any significant slowdown, whereas in other implementations dropping one could cause a major slowdown with lots of stuff having to be retransmitted. It's not the case that you can expect a small number of drops to cause a small amount of slowdown.
