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 : AUTOHOME, Inc -- Ignore unavailable to you. Want to Upgrade?


To: E. Davies who wrote (19082)1/20/2000 1:24:00 AM
From: Frank A. Coluccio  Respond to of 29970
 
Eric, please grant me a little due here:

"Does it really work to simply hang the users on the internet? No network management?"

No, of course not. Network management comes in many forms, though. A properly architected system is the first step to network management.

Yes, there would be net management platforms. But sometimes management is achieved by avoiding congestion, pro-actively, instead of tracking queues and buffers which are overflowing, reactively. Thus, and at the same time, reducing the need for some of the other bandwidth band-aids you mentioned. To wit,

"No caching?"

If you think about why caching is needed in the first place, you begin to better appreciate the enabling characteristics of higher bandwidth pipes. I'm not saying that ubiquitous bandwidth would eradicate caching, but it would reduce the need for it in many ways.

"What things are lost with "nice & quick"? I'm truly uncertain."

The things that are lost are the things that wont go away, even if you poked a stick at them, otherwise. Not on their own, in any event, for the sense of security that having them engenders in their providers. Like rusty coaxial connectors, which pick up A.M radio stations and 60 Hz hum (ingress), and car ignition noise. And RF head ends. And conditions like 128 kb/s upstream throughput restrictions on pipes that are rated at 37 Mb/s in the opposite direction. You know the script.

Pretty soon I'm going to put these scripts to music. Wait a minute, someone already did that yesterday, didn't they?

Actually, you are correct, in that you do lose something. You lose your normal program grade NTSC TV delivery, for one, since digital TV over IP is not availalbe yet, although that could be changed. Video over ATM "is" available, and this could be supported now if someone really wanted to force the issue using settop boxes that already exist. A fiber going into the home, first hitting a residential controller (or STB) could handle it, I'm sure. What you lose, then, is your "traditional" program TV delivery scheme and its associated form factors which have been around since the early 50s. Big loss.

This is why I suggested yesterday that the fiber for 'net access be pulled separately until the TV/IP model comes into its own down the line. Problem is, it'll never have the impetus to go there unless there is a medium in place to support it, and catch-22 we go again, I know.

"What I'm talking about is duplicate networks where each ISP is required to run its own link between each headend and "the internet" (in whatever form). Instead of one heavy duty link for all the users of that headend there would be 10 smaller ones each attempting to size itself for the capacity based on the number of subscribers they have at the moment. Seems illogical to me."

And that "would" be illogical if that is the way they went about it, especially if hey had options to do otherwise. But "real" ISPs aren't shy about peering with one another, and sharing routes, when it is to the mutual betterment of all.

[[But I must say that that is a part of their culture which I fear is now being threatened, but I promised myself that I wouldn't digress into such matters tonight. It's much too late.]]

One of the ISPs' most effective money saving techniques, as it turns out, and the central theme behind ISPing in general, is to do exactly what your point implies. They would peer with one another at various points on the 'net upstream or combine their traffic flows using the constructs of IP over larger pipes, instead of each one coming in on smaller pipes individually. Hey, but this takes some doing, and creating some understandings with the MSO who might have to administer address spaces and routers of their own, etc., and be a part of this in order for it to work. Otherwise, they could demand to be fed individual feeds from each ISP one by one, as your premise stated. The ILECs stonewalled the CLECs for the longest time in this manner. Sooner or later, though, the regs step in and they change all of that. What's taken place in the ILEC space will take place in the MSOs'. Now, where have I heard that before?

Some may elect to use their own leased lines, too. Or, perhaps they would do commingle at a meet-me point somewhere, or wherever they found an opening upstream, or it could just be a part of their regular IP distribution mesh which they use to reach the world at large.

Let's not forget something here: Just because an ISP has access to a broadband provider doesn't mean that they are going to match the upstream bandwidth of that provider's downstream capabilities for every user who attaches to them, in kind. The smaller ISPs would be very hard pressed to create a bandwidth reserve from the core to the MSO that could satisfy unimpeded flows to a multitude of 37 Mb/s pipes leading to subscriber locations.

Instead, they will supply only that amount of bandwidth which they can economically afford. And this will cause their users to experience slower responses, higher latencies than they would, otherwise. Perhaps these limited pipes will be better than dialups, but they would be considerably slower, especially when the system is loaded, than they'd like them to be if they had ample bandwidth, this time in their own (the ISPs') clouds.

Suffice it to say that the scenario which you painted "could" happen, but in all likelihood the ISPs, at least the smaller ones, would devise route sharing techniques, much in the same way as they already do. And again, if one had sufficient traffic, or if one didn't want to be social (as often is the case the larger they get), then they could elect to do a home run from their own servers directly to the head ends.
----

"@home already provides that. What can other ISP's (excluding AOL) provide that would make consumers choose them over @home?

Brand loyalty, retention of email address. Sometimes they don't have a choice as in corporate discounts for VPNs, and so on.

"Where will the battleground be when MSPG tries to steal away @home customers? I personally don't see any way that they can (except for SOHO type apps unless @work gets it's act together).

I'd have to repeat the answer I just gave above.

"Finally in regards to the question "How hard is it to duplicate @home?" I ask about the management of the network down to the user. My understanding (though I'm still fuzzy) is that though the MSO provides the link, @home controls and manages the network all the way down to the users modem.

All the way down to the user's modem implies two things. One is physical, and the other is logical.

The MSO is responsible for physical link continuity. Home takes over on the IP part. These are two separate sets of considerations, though. When it comes to VoIP which will use the DOCSIS modem too, who will be the custodian of that part? Will it be the MSO? or Home? And how about users who elect to mount their own VoIP clients?

"In essense you might say that @home is leasing the wires similar to how they lease backbone capacity from AT&T.

I'd say that was fair, although the technical arrangement might not be 'called' a lease, but it is effectively the same thing.

"If true- how can you have multiple managers of a single network?

See my reply from last night to Jay, I believe it was, where I talked about the design of the DOCSIS platform being suitable at this time for only a single MSO. I used the one driver per car metaphor, there.