To: wonk who wrote (25775 ) 3/11/2008 2:47:08 AM From: Frank A. Coluccio Read Replies (1) | Respond to of 46821 Needless to say I'm enjoying this give and take quite a lot, and learning some, too, to boot. As it happens, I'm in a bit of a crunch mode right now, so please don't mistake my silence for anything but that. Actually, I can't recall the last time my post count has been this low, so fredg's and wonk's stepped up posting is well-timed and appreciated ;) -- I think wonk picked up on my point concerning sunk costs -- although I wasn't as specific as he, down to the level of long term capital expenditures, but I naturally assumed those, too, in my reference to the relative stability of costs that SPs incur during short time windows. The point is, if every PC across the globe were shut down cold for a week, the costs that SPs would incur wouldn't go down or up by any noticeable amount based solely on the elimination of demand. Yet, based on average utilization over some set time frame, demand plays supreme into the amount of capacity that service providers (all three: 1st mile, 2nd mile and BB) must make available as a function of their throughput handling capabilities, respectively. Have we been looking at all of the variables? How about traffic profiles that deviate from http and streaming video, i.e., the two forms we seem to be stuck on? Do the economics change with real time requirements? Peer-to-peer? I won't even touch broadcast and multicast, since I tend to classify their presence as lying elsewhere in the "bundle", although some forms of -casting are not precluded from showing up in the HSI (hi-speed Internet) part, too. I suppose those profiles do matter, 'if' the SP wishes to maintain high performance levels for them. The SPs do, in fact, make an attempt to maintain high performance levels for them when they themselves provide them, and they do this through the use of QoS and "other means". I know... I'm all over the map at this point, and seem to be running afield, but these additional factors are becoming increasing relevant with time to the discussion at hand. As does the matter of hierarchical routing, where all packets, regardless of their source-sink type and ultimate destinations, must first go to Rome before anywhere else, thereby ensuring a minimum of six hops, up and down, whether needed or not. The SPs prefer to have it this way (whether this is by design or by accident, I'm still not sure) because they want to examine every packet at an upstream aggregation point (usually at the SPedge or at a master hub) for "security" and policing purposes -- and a lot more than that, which usually goes unspoken, too -- as opposed to allowing one end user to talk directly with another "on-net" at the end office level. Now, I know that this last statement isn't universally true, although it covers the majority of cases, thus it is prevalent enough to make mention of it here. Enough of my rambling for now, since I'm barely able to keep my lids up at this point, and I've digressed enough, in any event. So please carry on, Good Folk. Keep it coming ... FAC ------