mSQL Attack/Peering/OBGP/Optical exchange

Fri Jan 31 00:29:11 UTC 2003

From: "Iljitsch van Beijnum"

> 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.
>
But a ruleset should be allowed for you as a business to make that decision.
Do you allow the worm's traffic increase to increase your circuit and cost
you money, or do you limit it based on suspected illegitimate 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...
>
And what do you do to handle traffic bursts now? Do you immediately jump up
and scream, "I need a bigger pipe now! Step on it!" You plan for what you
maximum capacity needs to be. The proposed system would still allow for
maximum caps, but there are times when that amount of bandwidth is
unnecessary for your particular network while another may need it at that
time. For planned bursts in throughput, you can increase the amount
manually. The automated system, however, should be configurable per peer to
allow for what the business wants to spend. If a business doesn't want 100mb
surprises, then they should be able to avoid them. On the flip side, if the
business does, then they can allot for it.

> > 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.
>
Traffic doesn't have to be inspected more closely than it is. It just needs
to keep historical records and averages. The system knows what the current
utilization is and can quickly calculate the rate of increase. As stated
above, it should be the right of each peer to decide what they consider to
be an acceptable rate of increase before allowing an automatic upgrade which
will cost them money.

> > 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.
>
Automation is rarely a simplistic process when the automation includes
increasing expenditures. The factors involved in the automation process
would also have to be worked into peering agreements, as both sides of a
peering session would have to agree on what they find to be acceptable
between them.

-Jack