Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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 : The *NEW* Frank Coluccio Technology Forum -- Ignore unavailable to you. Want to Upgrade?

To: Gord Wilson who wrote (7042)	4/7/2004 4:30:04 PM
From: Frank A. Coluccio	Respond to of 46821

Hi Gord, Thanks for putting me back in time w.r.t. upstream/downstream terminology used by the carrier world. My experience with several of them recalls several other terms (not upstream or downstream), but terms such as "looking in" and "looing out." "In", referring to the subscriber side of a given reference point, and "Out", referring to the WAN side or larger universe of the customer's network. Of course, all of this depends on where in the network you called your point of reference. An incumbent local exchange carrier (LEC) testboard technician would call "in" anything that faced the local loop from the central office, meaning the conditions on the line facing the subscriber. A Long Lines private line testboard technician, in contrast, usually found himself in a "mid-point" space, and he would refrain from using In/Out terminology, prefering, instead, to use a different set of jargon, such as east-to-west, A side, Z side, and, most popularly, using originating/terminating terminology as defined by who pays for the service as being the controlling/non-controlling sides of a circuit, respectively. Forgive the use of apparent errors in pc here, by the use of the term "he", but during my referenced time frames there were no "shes" in the business who were working testboards. Regarding: "Don't they have the same bandwidth problems with all those Fttx projects. Also I thought that one of the ideas behind "convergence" was that the content, server farms, pipes etc would all be delivered by one player." Absolutely, and I hope I didn't imply anywhere in my upstream posts that FTTx operators were in any way immune to these conditions. Actually, they will face even greater burdens in supporting high-volume content, since they are capable of supporting much greater amounts of traffic in the local loop to the subscriber. One of the tenets of the foregoing discussion, however, was that caching and other schemes used to optimize local control of content, as opposed to downloading everything from the WAN by end users, was a topic of another discussion. When one begins to offer all of the services you've mentioned, they begin to resemble the makings of a "walled garden," such as was the case with @home a while back. AOL/TW and some of the other MSOs are other cases in point. However, they too are finding that end users want more contractual freedoms and freedom of content choice than what a single source will support, especially as more options make themselves available by others (who would aggressively attack the incumbents' offerings to the point of the incumbents cannibalizing their own offerings in order to prevent the entry of the startup). A lot of this has to do with a sustainable business model and the term contracts required to ensure that the subscriber will still be around, long enough, to cover the costs of capital and operating expenses over the longer term, which would be required to put all of these supposedly profit-making amenities in place. FAC frank@fttx.org