mSQL Attack/Peering/OBGP/Optical exchange

Sat Feb 1 00:08:15 UTC 2003

On Fri, 31 Jan 2003, Jack Bates wrote:

> If a proper rulebased system were implemented, wouldn't this account for the
> issues? For example, implementation of an increase is only allowed by peer E
> if the traffic has been a gradual increase and X throughput has been met for
> T amount of time. Peer E would also have specific caps allotted for peer S
> and T along with priority in granting the increases. In the case of the
> worm, it is important to have a good traffic analyzer to recognize that the
> increase in bandwith has been too drastic to constitute a valid need.

If my regular saturday morning traffic is 50 Mbps and a worm generates
another 100, then 150 Mbps is a valid need as being limited to my usual
50 Mbps would mean 67% packet loss, TCP sessions go into hibernation and
I end up with 49.9% Mbps of worm traffic.

> Of course, traffic patterns to vary abit in short periods of time, but the
> average sustained throughput and the average peak do not increase rapidly.

Sometimes they do: star report, mars probe, that kind of thing...

> What was seen with Saphire should never be confused with normal traffic and
> requests for bandwidth increments should be ignored by any automated system.

So you're proposing the traffic is inspected very closely, and then
either its rate limited/priority queued or more bandwidth is provisioned
automatically? That sure adds a lot of complexity but I guess this is
the only way to do it right.

> Of course, I realize that to implement the necessary rules would add a
> complexity that could cost largs sums of money due to mistakes.

Right.