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: Valueman who wrote (1053)	10/17/2000 10:02:07 AM
From: justone	Read Replies (1) \| Respond to of 46821

Valueman: I'm a rank amateur and poor "back of the envelope "guy when it comes to Satellites. I have been peripherally involved in some satellite attempts, but only on the network side, not the fun side. Satellite guys have birds, spot beams, dishes, transponders, and astronauts repairing them; in telecom, we just have acronyms. Thank you for the real data. Now let me try to understand the bottom line. Each 36 MHz transponder has about a 45 Mbps capacity. A service like Gilat's Starband is starting off with 14 transponders on Loral's Telstar 7 satellite. A typical sat today has approximately 24 Ku-band, and 24 C-band transponders. FYI, in Starband's S-1 filing, they have been getting 7,500 subs per transponder while maintaining their 150 Kbps minimum. To wrap up this summary, a sat costs ~$250 million to build, launch, and insure. Other fun facts--a typical modern sat has about 1.2 Gbps throughput capacity. Birds being built now, with frequency reusing spot beams, will up that to 6-7 Gbps. Technology of ViaSat can be used to boost that capacity to 20-40 Gbps on a Ka-band spot beam satellite. I'm not clear on the potential for increase in capacity, so hold that off for now. Just taking 'todays' new satellite numbers, let me try a crude business case. Assume 150Kbps minimum with 7,500 subs per transponder and 24 transponders = 180,000 subs per satellite, well over my raw guess. The satellite cost $250 million to build and launch- I'm sorry, the bird costs $250 to fly (I must get the verbiage right!). This is about $1,400 per subscriber. Say another $200 for the modem. Assume the subscriber has all ready shelled out $500 for the dish to get TV, so don't factor that in. This is about $1,600 per subscriber. A rough rule of thumb says that the capital expense should be no more than 20 times the monthly fee. Reverse engineering this means they have to charge $80 per month, even before add network access equipment to make a business case. Not too bad, at first glance; I'd probably pay $80 for 150 kbps over a 56 kpbs link with a second phone at $40 per month. Now of course, in satellite traffic disucssion, the fundamental problem of utilization is often overlooked. You must put up a $250 satellite to handle even one subscriber. The only way the above numbers work is if the satellite is fully utilized. If it is %50 utilized, you would have to spend $160 per month per subscriber. I'm not sure I'd pay that. In fact, it would be cheaper to get three phone lines and three modems and somehow glue them together (I think I've seen boxes that do this). This was one of the many problems with 2b+d ISDN- one reason it failed was because it was more expensive than getting two phone lines. I don't see how to make a business case here, until the satellites can handle double the capacity you noted. On the other hand, in the bit I didn't understand, you seem to imply you can go from 1.2 G per satellite to 20-40. Does that mean you can increase the number of subscribers per satellite by a factor of 30? That would do it.

To: Valueman who wrote (1053)	10/17/2000 3:38:17 PM
From: Ilaine	Respond to of 46821

I posted this on the Globalstar thread because they've got a discussion on satellite internet going on there, but decided to post it here as well, and I guess on my own thread, too. I think it's relevant to the discussion because it mentions multiple narrow pipes, which Frank mentioned this weekend. Anyone who is interested should actually go to the website, a lot of the words and phrases are actually links. >>TCP/IP over satellite There has been a fair amount of press recently about TCP/IP, the networking protocol that the internet and the web rely on, not working properly over satellite. Quite a lot of this furore appears to be the result of a Teledesic press release masquerading as a paper (Wireless multimedia and internet via satellite, by Mark Sturza and Farzad Ghazvinian). These claims are that the TCP/IP reference implementation's 4K buffer size limits the size of the pipe and the data throughput to only 64kbps. It is then used to argue that the maximum buffer size of 64K limits maximum throughput to 1Gbps, and uses this to argue that its geostationary Ka-band competitors are unsuitable for high-bandwidth applications, as the increased latency of a GEO connection decreases the available bandwidth. (TCP buffers are dimensioned as bandwidth * delay = buffer size With a limited buffer size, a longer end-to-end delay decreases the space available to hold spare copies of unacknowledged data for retransmission. This limits the throughput on a lossless TCP connection.) However, this completely ignores the work done on larger buffer sizes for TCP in RFC 1323, the "large windows" effort. (mirror) This work to expand TCP beyond its original 16-bit buffer space has been going on for several years, and is already supported by a number of versions of unix. The TCP buffer limit isn't the problem it's made out to be; TCP copes with GEO delays quite nicely right now, and individual high-bandwidth GEO TCP links are possible with the right equipment and software - you wouldn't buy the wrong equipment and expect it to work, would you? GEO links are suitable for seamless intermediate connections in a TCP circuit and are already being used for this. There is nothing stopping you from having many "small" TCP connections over a broadband link, GEO, fibre or otherwise, and most broadband internet connections contain a vast number of separate small pipes. The real issue with GEO vs LEO is not the alleged inapplicability of TCP, but the acceptability of the physical delay for two-way realtime applications where humans are involved, such as telephony or videoconferencing. And even then, the physical delay of GEO is balanced somewhat by the increased switching times through a packet-based LEO network. If you want decent two-way videoconferencing, you'll do the sensible thing and go to fibre. Ignore this furore. Anything that talks about TCP/IP but doesn't refer to Internet Engineering Task Force (IETF) work or to relevant RFCs should be questioned. Have the authors done their research? These papers describe the situation in greater technical detail, and show that having multiple narrow TCP pipes across satellite works well. Wide pipes with large buffer sizes can suffer from the higher bit error rate (BER) of satellites - but that's something that really needs to be addressed by better symbol coding down at the satellite's data-link layer for better BER, and not up at the application layer. For TCP, implementing Selective Acknowledgements (RFC2018) and fast recovery (RFC2581) also improves performance in the face of errors. Take a look at work undertaken by the Internet Protocols over Satellite and the TCP over satellite working groups. IP-Over-Satellite: A Global Solution Now, Peter J. Brown, Via Online.<< ee.surrey.ac.uk