SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : LAST MILE TECHNOLOGIES - Let's Discuss Them Here

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: MikeM54321 who wrote (7647)7/17/2000 10:28:46 PM
From: Frank A. Coluccio  Read Replies (2) of 12823
 
"The trials and tribulations with what I believe is WAP enabled phones. What a failure that seems to be in the real world."

Yes, this is a growing sentiment. To put it into perspective, WAP is, at best, and IMO, a current proposed solution that solves a problem that may, itself, vanish with higher bandwidth availability, and as appliances that are capable of supporting higher bandwidths begin to proliferate. In other words, with higher bandwidth carrying capabilities, the need for WAP formating goes away.

Why would someone want to optimize a circuit-switched or packet data mode using a 19.2 kb/s channel or even one rated at 56 kb/s, in an arena that is availing itself of 384k and 2024 kb/s in another one and two years, respectively?

It wouldn't make any sense, except that many SPs will do what it takes to preserve their embedded investments, which no one is going to blame them for in the end from a shareholder view. Or, will they? Hmm...

Notwithstanding, we might look at this need to preserve previous and still-undepreciated investments as yet another motivation to keep bandwidth availability low, until the market has been sufficiently bled at the lower thruput rates, or, until the costs for WAP R&D and its initial deployments have been adequately recovered.

But not to confuse what I'm saying about the higher data speed angle... user expectations, once those higher thruputs arrive, and once they prove in, will likely result in many service providers being swamped, overwhelmed, rendering them unable to deliver a true value proposition in many instances. Unless they pull back on availability, but that would be antithetical to the precepts of networking. [Although, has that ever stopped them?]

When availability ripens in high teledensity areas that are served by emerging wireless (and probably more so than dsl and cable modem for its added feature attractiveness, especially in those situations that support mobility) it will likely result in at least some serving areas (many, over time) acting out the classical tragedy of the commons.

This will be especially so if pricing is anywhere near reasonable (did someone say that bandwidth would at some point be free?), and if the SPs engage in their usual levels of oversubscription on statistically sized networks. And they probably will, because base stations and upstream bandwidth towards the core are not cheap.

(Going off topic for a moment, Sprint PCS is now notorious for oversubscribing its PCS service, i.e., undersizing their ability to complete incoming calls due to too few outgoing air links. I'm finding that many of my calls -- I've done this under controlled conditions when I've suspected that it was happening -- are now going directly to voicemail instead of being cut through to my handset. This happened last year too, but was better for a spell. But I'm finding that it's happening again. Another variation of bandwidth chicken, as the carrier tests the limits of user tolerances. Now, if we're having these problems today with "voice" channels rated at 13 kb/s, what are we to find when we go to "multimedia" channels rated at 2 Mb/s?)

[Back on topic..]

Hence, another motivation (aside from the obvious one to maximize profits) to keep prices high in order to control, or ration, supply. In other words, unafordability is a potent regulator that can be used to control congestion.

FAC
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext