On Wed, 15 Aug 2007, Fred Baker wrote:
On Aug 15, 2007, at 8:39 PM, Sean Donelan wrote:
On Wed, 15 Aug 2007, Fred Baker wrote:
So I would suggest that a third thing that can be done, after the other two avenues have been exhausted, is to decide to not start new sessions unless there is some reasonable chance that they will be able to accomplish their work.
I view this as part of the flash crowd family of congestion problems, a combination of a rapid increase in demand and a rapid decrease in capacity.
In many cases, yes. I know of a certain network that ran with 30% loss for a matter of years because the option didn't exist to increase the bandwidth. When it became reality, guess what they did. That's when I got to thinking about this.
Yeah, necessity is always the mother of invention. I first tried rate limiting the TCP SYNs with the Starr/Clinton report. It worked great for a while, but then the SYN-flood started backing up not only on the "congested" link, but also started congesting in other the peering networks (those were the days of OC3 backbones and head-of-line blocking NAP switches). And then the server choked.... So that's why I keep returning to the need to pushback traffic a couple of ASNs back. If its going to get dropped anyway, drop it sooner. Its also why I would really like to try to do something about the woodpecker hosts that think congestion means try more. If the back off slows down the host re-trying, its even further pushback.