FBO's and WiFi

On Tue, 19 Aug 2003 21:13:35 -0700, Peter Duniho wrote:

500ms ping time minimum... So count on lots of lag...

Unless you are playing online computer games, you would never notice the
lag. Most Internet access is of the form "brief request for data,
followed by large amount of data returned". It'll take an extra
half-second for the data to show up, but that will generally be swamped by
the time it takes to actually generate and send the data, even at
broadband speeds.

This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

None will work when it rains hard or the sun is in transit
(summer / winter soltice)...

Why would you say that? The satellite data systems I've seen are based on
similar technology to that used for my digital broadcast satellite system.
At worst, data throughput drops *some*, and that's in the very worst
downpours.

I have no idea why the solstices would have any effect on data
transmission. Perhaps you could explain that one.

Your transmitter is nowhere as powerful as the one of the base station
or the one on the satellite.

The good news is that DirecWay's dish is about as big as the
old PrimeStar dish. I have one of those, modified to support
DirecTV's LNB with a bunch of duct tape and some pieces of wood.
My TV never goes off even in "worst downpours". So, your downlink
is virtually rain proof. The bad news is that the same cannot
be said about your uplink.

Solstices only knock communication off for several minutes a day,
when the Sun is directly behind the satellite. It is a well known
effect. I used to depend on an old Soviet satellite Raduga-7
for connectivity, and it was true back then.

-- Pete

"Pete Zaitcev" wrote in message
news
This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

Regardless, that still only affects the initial delay in response. Even if
the delay were 10 seconds (which it's almost never going to be), that's in
the same ballpark as the delay some servers have just getting around to
servicing a client. It's just not a big deal.

[...] So, your downlink
is virtually rain proof. The bad news is that the same cannot
be said about your uplink.

Hmmm...okay, I see. I wasn't aware that they didn't provide a high enough
power transmitter to deal with weather.

Solstices only knock communication off for several minutes a day,
when the Sun is directly behind the satellite. It is a well known
effect. I used to depend on an old Soviet satellite Raduga-7
for connectivity, and it was true back then.

Several minutes? I guess I'd call that insignificant. That's what, 10
minutes of downtime per year? Big deal. I have to deal with that kind of
downtime with my wired DSL access.

Pete

"Peter Duniho" wrote in message
...
"Pete Zaitcev" wrote in message
news
This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

Regardless, that still only affects the initial delay in response.

The number of DNS queries to render any particular page can drive this time
up quite high. Have a couple packets lost in between? ouch.

$1000 a year is a bit steep for the class of service.

"Robert Henry" wrote in message
news:hpK0b.11202$uh6.8355@lakeread05...
The number of DNS queries to render any particular page can drive this
time
up quite high. Have a couple packets lost in between? ouch.

That's just silly. Especially for the typical use in an FBO, the number of
DNS queries to render any particular page is going to be quite small.
Furthermore, there's no need for DNS queries to be serviced sequentially,
and I doubt any browser would do it that way. I know that IE doesn't.

Once they get the initial page HTML, any additional Internet addresses that
need a DNS query to be resolved can and will be handled asynchronously. In
other words, a dozen DNS queries required by a single page isn't going to
take much more time than one additional DNS query would take.

$1000 a year is a bit steep for the class of service.

Only if you can have DSL or a cable modem installed. If you are in the
boonies and satellite is the fastest, most reliable Internet connection you
can get, $1000/year isn't that bad at all.

Pete

"Peter Duniho" wrote...
"Pete Zaitcev" wrote...
This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

Regardless, that still only affects the initial delay in response. Even
if
the delay were 10 seconds (which it's almost never going to be), that's in
the same ballpark as the delay some servers have just getting around to
servicing a client. It's just not a big deal.

Ever tried VOIP over satellite? Painful, is a good one word discription,
same for remote access applications, network gaming as mentioned is
impossible...

[...] So, your downlink
is virtually rain proof. The bad news is that the same cannot
be said about your uplink.

Hmmm...okay, I see. I wasn't aware that they didn't provide a high enough
power transmitter to deal with weather.

Someone who lives in the desert might not experience as much rainfall that
occurs in other parts of the USofA or other countries in the beam... Hmmm
Las Vegas just got flooded, so better wording might be, "on a regular
basis"...

Solstices only knock communication off for several minutes a day,
when the Sun is directly behind the satellite. It is a well known
effect. I used to depend on an old Soviet satellite Raduga-7
for connectivity, and it was true back then.

Several minutes? I guess I'd call that insignificant. That's what, 10
minutes of downtime per year? Big deal. I have to deal with that kind of
downtime with my wired DSL access.

Nearly 10 minutes per day spread over several days, twice a year...
Guaranteed to screw up something important that needed to be done,
everytime...

Satellite data delivery has faults, just making you aware of it... I've been
there done that (our lawyers got the money from the class action lawsuit
against Hughes) and won't geaux back (2 cards still sits in the deactivated
computers since '98, dishes are still pointed at the satellites) to anything
with a ping time over 90 ms to the world... I actually endured the loss of
the satellite itself once, and the repointing a few times due to bird
migration (moving from one satellite to another, as the provider sees
fit)...

Pete Zaitcev wrote in message ...
On Tue, 19 Aug 2003 21:13:35 -0700, Peter Duniho wrote:

500ms ping time minimum... So count on lots of lag...

Unless you are playing online computer games, you would never notice the
lag. Most Internet access is of the form "brief request for data,
followed by large amount of data returned". It'll take an extra
half-second for the data to show up, but that will generally be swamped by
the time it takes to actually generate and send the data, even at
broadband speeds.

This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

Sorry for continuing an off-topic conversation and splitting hairs,
but....

"Lag" in the original poster's case, is actually referred to as
"latency" in the world of computer networking. Latency is defined as
the time it takes to set up and send a message, whereas bandwidth is
the rate at which data moves from point to point. Sat connections,
therefore, have a latency of 500ms (for example) plus the latency of
the system doing the send/receive.

Since all data is transported in TCP packets (in the case of Web
traffic), there is continual send AND receive on BOTH sides since TCP
requires acknowledgement of every packet on the part the of the
receiver (remember, TCP is a *reliable* protocol). Granted, the ACK
packets are much smaller than the data packets and most of the traffic
to a web browswer is downstream, but a high-latency network like
satellite will exhibit performance degradation during *all* phases of
a connection, not just startup.

Did I just restate what was already said? Sorry!

-Scott

"Scott Lowrey" wrote in message
om...
Since all data is transported in TCP packets (in the case of Web
traffic), there is continual send AND receive on BOTH sides since TCP
requires acknowledgement of every packet on the part the of the
receiver (remember, TCP is a *reliable* protocol). Granted, the ACK
packets are much smaller than the data packets and most of the traffic
to a web browswer is downstream, but a high-latency network like
satellite will exhibit performance degradation during *all* phases of
a connection, not just startup.

Wrong. Only if the server requires a protocol-defined acknowledgement
(where protocol is the high-level protocol, like FTP, HTTP, etc., *not* TCP)
would that happen. And that's uncommon with TCP-based protocols (since it
would totally break one of the main advantages of using TCP). Certainly
it's not the case with any of the commonly used protocols.

TCP uses sliding windows to allow constant streaming of data to occur as
long as the latency in the connection is "reasonable". That is, it will
send many packets before needing to receive any acknowledgement even for the
first packet. As long as the acknowledgements start coming in time, the
latency of the connection will NOT affect throughput AT ALL. A latency of
500ms is MORE than reasonable in this context.

Pete

"Peter Duniho" writes:

TCP uses sliding windows to allow constant streaming of data to occur as
long as the latency in the connection is "reasonable". That is, it will
send many packets before needing to receive any acknowledgement even for the
first packet. As long as the acknowledgements start coming in time, the
latency of the connection will NOT affect throughput AT ALL. A latency of
500ms is MORE than reasonable in this context.

Everything you're saying makes sense to me, but you might want to hang
around on news:comp.protocols.tcp-ip for awhile. I regularly notice
people trying to debug satellite TCP issues there.

It's quite possible that it's just a matter of getting all of the
settings tweaked everywhere, but it seems to cause a lot of grief.

--kyler

"Scott Lowrey" wrote in message om...
Pete Zaitcev wrote in message ...
"Lag" in the original poster's case, is actually referred to as
"latency" in the world of computer networking. Latency is defined as
the time it takes to set up and send a message,

Well, it's the overall transmission time from source to destination. The
overhead to set up and send a satellite packet isn't really any worse
than anything else, it just takes a long time to deliever.

Since all data is transported in TCP packets (in the case of Web
traffic), there is continual send AND receive on BOTH sides since TCP
requires acknowledgement of every packet on the part the of the
receiver (remember, TCP is a *reliable* protocol).

Actually, it's acknowledgement of the position in the byte stream.

Granted, the ACK
packets are much smaller than the data packets

There's no such thing as an ACK packet. A TCP packet can have
data as well as the ack for data received.

"Ron Natalie" wrote:

There's no such thing as an ACK packet. A TCP packet can have
data as well as the ack for data received.

I wouldn't say there's "no such thing". The people I work with
generally call a packet with the ACK bit set an "ACK". :-). And
if you examine the packets flying in and out during a web surfing
session, they usually don't contain any data.

The latency in the network is going to affect the retransmission
timer on the sending end. Delay is delay. It's not constant, but
it is cumulative.

I'll concede, though, that as long as the acknowledgement timing is
not highly variable, the window will stabilize and you'll get your
nominal throughput *for that particular HTTP request*. Another click
or a redirect and, presto, another delay. It all adds up.

Sorry to flog the dead horse... I'll shut up.

-Scott