mSQL Attack/Peering/OBGP/Optical exchange

Fri Jan 31 04:01:53 UTC 2003

Actually, I think that was the point of the dynamic provisioning 
ability.  The UNI 1.0 protocol or the previous ODSI, were to allow 
the routers to provision their own capacity.  The tests in the real 
world done actually worked although I still believe they are under 
NDA.

The point was to provision or reprovision capacity as needed. 
Without getting into the arguments of whether this is a good idea, 
the point was to "pay" for what you used when you used it.  The 
biggest technical factor was "how the heck do you bill it."

If a customer goes from their normal OC3 ---> OC12 for 4hrs three 
times in a month... what do you bill them for?  Do you take it down 
to the DS0/min level and just multiple or do you do a flat rate or a 
per upgrade???

The point was you could bump up on the fly as needed, capacity 
willing, then down.  The obvious factor is having enough spare 
capacity in the bucket.  This should not be an issue within the 4 
walls of a colo.  If it's a beyond the 4 walls play then there should 
be spare capacity available that normally serves as redundancy in the 
mesh.

The other interesting factor is that now you have sort of aTDMA 
arrangement going on( very loose analogy here).  In that your day can 
theoretically be divided into 3 time zones.

In the zone:
8am - 4pm  ----- Business users, Financial backbones etc
4pm -12am ----- Home users, DSL, Cable, Peer to Peer
12am - 8am ---- Remote backup services, forgein users etc

Some of the same capacity can be reused based on peer needs.

This sort of addressed the "how do i design my backbone" argument. 
Where engineers ahve to decide whether to built for peak load and 
provide max QoS but also the highest cost backbone; or whether to 
built for avg sustained utilization.  This way you can theoretically 
get the best of both worlds.  As long as the billing goes along with 
that.

You are right this is a future play.  But though it was interesting 
from the perspective of what if all this technology was enabled 
today, what affect would the mSQL worm have had.  Would some of these 
technologies have exacerbated the problems we saw.  Trying to get 
better feedback on the future issues, so far some of the offline 
comments and perspectives have been helpful and inciteful as well as 
yours...

Dave

At 20:12 +0000 1/30/03, Vijay Gill wrote:
>David Diaz <techlist at smoton.net> writes:
>
>>  With the rapid onset of an attack such as the one sat morning. Models
>>  I have show that not only would the spare capacity been utilized
>>  quickly but that in a tiered (colored) customer system. That the lower
>>  service level customers (lead colored, silver etc) would have had
>
>Does your model(s) also take into account that people's capital
>structure may not allow them the luxury of leaving multiple OC-X
>ports wired up and sitting idle waiting for a surge?
>
>One thing I found somewhat interesting among the "dymanic" allocation
>of resources type infrastructure was the fact that my capacity
>planning is on the order of weeks, while the exchanges assume
>something on the order of minutes. I don't have enough capital sitting
>around that I can afford to deploy and hook up a bunch of OC-x ports
>to an exchange and then sit there waiting for them to be used maybe
>sometimes in the future, for sure, etc etc.
>
>So perhaps the thought of an optical exchange running out of resources
>might be a bit of an overkill at this stage?
>
>/vijay

-- 

David Diaz
dave at smoton.net [Email]
pagedave at smoton.net [Pager]
www.smoton.net [Peering Site under development]
Smotons (Smart Photons) trump dumb photons