mSQL Attack/Peering/OBGP/Optical exchange

Tue Feb 4 08:11:00 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...
>

Well the problem with optical bandwidth on demand is that you will have 
to pay for the network even when it isn't being used. Basically you 
have three billing principles, pay per usage, pay for the service, a 
mix of the two. With all the models you still need to distribute the 
cost over bandwidth and in worst case this will end up being higher per 
transfered data.

- kurtis -