nanog mailing list archives
Re: mSQL Attack/Peering/OBGP/Optical exchange
From: "Jack Bates" <jbates () brightok net>
Date: Thu, 30 Jan 2003 18:29:11 -0600
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
Current thread:
- Re: mSQL Attack/Peering/OBGP/Optical exchange, (continued)
- Re: mSQL Attack/Peering/OBGP/Optical exchange David Diaz (Jan 30)
- Re: mSQL Attack/Peering/OBGP/Optical exchange Vijay Gill (Jan 30)
- Re: mSQL Attack/Peering/OBGP/Optical exchange David Diaz (Jan 30)
- Re: mSQL Attack/Peering/OBGP/Optical exchange Stephen Stuart (Jan 31)
- Re: mSQL Attack/Peering/OBGP/Optical exchange Vijay Gill (Jan 31)
- Re: mSQL Attack/Peering/OBGP/Optical exchange Randy Bush (Jan 31)
- Re: mSQL Attack/Peering/OBGP/Optical exchange Stephen Stuart (Jan 31)
- Re: mSQL Attack/Peering/OBGP/Optical exchange Jack Bates (Jan 31)
- Re: mSQL Attack/Peering/OBGP/Optical exchange Stephen Stuart (Jan 31)
- Re: mSQL Attack/Peering/OBGP/Optical exchange Iljitsch van Beijnum (Jan 31)
- Re: mSQL Attack/Peering/OBGP/Optical exchange Jack Bates (Jan 31)
- Re: Tracing where it started Stephen Milton (Jan 26)
- Re: Tracing where it started Brian Coyle (Jan 25)
- Re: Tracing where it started Charles Sprickman (Jan 25)
- Re: Tracing where it started Brian Coyle (Jan 25)