Talk:Satellite Internet access

From Wikipedia, the free encyclopedia

The page needs to include defintion / links on latecy and round-trip delays.

Much of the information presented about satellite ground station and antenna architecture is inaccurate.

The structure of this page is horrible, with redundant information and forward references all over the place.

Contents 1 WINDS 2 Picture 3 Is reducing latency section nearly all OR? 4 alternatives to increasing performance without actually reducing latency

[edit] WINDS

There's no mention here of the WINDS satellite. I'm wondering how that satellite works... I noticed it's got a geosynchronous orbit... so it would pass the same spot in the sky every certain time (in this case 24 hours). How are people on the ground supposed to communicate with it?. And will it later on be a web of satellites so that there's always one up?.

[edit] Picture

I put a picture of the Wild Blue dish that we have installed on our home up on the article. One of these days if I remember I'll take a picture of the satellite modem and put it up on this article too.
JesseG 21:26, 2 January 2006 (UTC)

It needs to include information about iPSTAR, listed elsewhere in Wikipedia, the worlds first pure IP satellite, and most efficient —Preceding unsigned comment added by 124.157.228.37 (talk) 06:53, 5 October 2007 (UTC)

[edit] Is reducing latency section nearly all OR?

The reducing latency section appears to be one person's original research. Caching is impractical for a huge range of uses. It all depends on the usage pattern of the users. This section reads to me like "Look everyone, I've solved this huge problem so simply, why haven't the experts realized how simple it is and fixed it? Hmmm, maybe because they just aren't as smart as me! Next on my to do list: the problems of famine, war, and republicans..." Saying adding a robust and well-designed cache to a satellite is practical is rather silly: anything in a satellite had better be robust and well-designed. I assume the editor means well-designed in terms of what it caches: doing that alone would, I assume, be impractical because the algorithm which determined what to cache would have an impossible task due to the range of information required. Of course, I know next to nothing about this topic, so I didn't remove the text, just cleaned it up and flagged it. I suspect, however, that the editor who added it knew no more than I, hence the overreaching claims of practicality. --Fitzhugh 18:00, 4 December 2007 (UTC)

[edit] alternatives to increasing performance without actually reducing latency

With regard to reducing latency, there are a number of mechanisms available for reducing the *effects* of latency on Internet protocols such as TCP. These mechanisms don't reduce the actual physical latency but mitigate the problems caused by the huge latency incurred in satellite links. The most important references I have found on this topic are:

IETF RFC 2488 - Enhancing TCP Over Satellite Channels using Standard Mechanisms
IETF RFC 3135 - Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations

Performance Enhancing Proxies (PEP) seem to be well-supported. Cisco routers support this in their IOS software as of version 12.3T, it is called "Rate Based Satellite Control Protocol". The PEP technique is also referred to as "TCP spoofing" since it involves the injection of TCP ACKs to convince the sender that it should keep sending data. IETF RFC 2488 mostly writes about adding additional features to the TCP -- e.g. additions to the Congestion Control Algorithm to implement Fast Retransmit and Fast Recovery...or the addition of large windows, window scaling, the Selective Acknowledgement (SACK) option, etc. More of the gory details about these extensions can be found in IETF RFC 1323 (TCP Extensions for High Performance) and IETF RFC 2001 (TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms). ChrisTracy (talk) 01:27, 12 December 2007 (UTC)