5 ms·

Round trip to a satellite will never rival fiber. Especially the way modern web apps are built inefficiently

by nautilus12 9y ago

vandweller 9y ago
Could you expand on this? Do you think latency is the limiting factor for a LEO network?
- vorotato 9y ago
  A geosynchronous orbit is ~36000km 36000 km / speed of light = .12 seconds So thats a ping of 240, minimum. That's assuming everything else in the system happened instantaneously. If you can however manage to solve the whole aiming at a moving target 360 kilometers away then maybe you could do a LEO network, and yeah the ping would be closer to 1.2 assuming again literally everything was instantaneous.
  - jacques_chester 9y ago
    As you note, LEO is very different from geostationary. Moving target doesn't strike me as impossible. A LEO satellite has a very predictable path, a stationary dish has a predictable movement relative to that path and a mobile phone knows where it is at all times.
  - greglindahl 9y ago
    There are several companies building (and a few shipping) flat-panel phased array antennae that can "point" at a moving target 360 km away. They also can switch to a new satellite instantly.
  - foobarian 9y ago
    One has been online [1] since '98, so it's definitely possible. Question is probably in details around bandwidth and handoff performance. [1] https://en.wikipedia.org/wiki/Iridium_satellite_constellation https://en.wikipedia.org/wiki/Iridium_satellite_constellatio...
nmjohn 9y ago
> SpaceX expects its own latencies to be between 25 and 35ms [0] There is a huge difference in latency between existing satellite internet services and what spacex is looking to launch. [0]: https://arstechnica.com/information-technology/2016/11/spacex-plans-worldwide-satellite-internet-with-low-latency-gigabit-speed/ https://arstechnica.com/information-technology/2016/11/space...
- mirimir 9y ago
  Yes, SpaceX etc will be low Earth orbit, and the satellites will be a mesh network.
- deleted 9y ago
  [deleted]
- nautilus12 9y ago
  It sounda similar to fiber latency. Ive never thought about this before but the amount of time for a round trip to a leo satellite, shouldnt that be in the range of 10 m/s. (1200 km / 300,000 km/ s) = 4 m/s x 2 i wonder whats the complete breakdown, is most of it inter satellite optical communication? Does this offset the additional 8 ms because its a simplified topology?
exabrial 9y ago
I had Google Fiber installed in my apartment a year ago. I was walking through the parking garage and I caught one of the techs doing alignment splicing. I asked him where the nearest Google Fiber Hut was and he said about the quarter mile away near a Taco Bell. I remarked that's pretty good, but he said well it's even further than that because it's not line of sight. He pulled out a tool that could measure the total length of installed fiber via refection... It was over 20,000 feet. And that was just to go from the garage to fiber hut 1/4 mi away. I don't know how the topology of Google's network works, but I thought that was crazy. Granted leo satellites are 1200mi away but it's worth remembering that.
betterunix2 9y ago
It's not just web apps; TCP itself behaves badly under high-latency conditions. If you have no other choice but to use high-latency links, you are better off with a protocol like QUIC that includes forward error correction. If you need to send a lot of data over a high-latency link you need to start looking at less common approaches; for example, this: https://en.wikipedia.org/wiki/Fountain_code https://en.wikipedia.org/wiki/Fountain_code When the link is unreliable -- as it is in most wireless systems -- TCP also tends to behave suboptimally as it assumes lost packets are due to congestion. Again, if you need to deal with unreliable links, forward error correction is your friend.
- stephen_g 9y ago
  Have a look at Google's BBR congestion control algorithm [1]. This is perhaps a solved problem now (although it's still not supported on all platforms, but only the side sending the bulk of the data needs to have it). 1. http://queue.acm.org/detail.cfm?id=3022184 http://queue.acm.org/detail.cfm?id=3022184
  - justicezyx 9y ago
    Bbr is about high bandwidth latency product network with low error rate. Any window based retransmission protocol just breaks under high error rate, that what happens in wireless links.
    - stephen_g 9y ago
      No, BBR does deliver significant performance improvements in high packet loss links. It is designed as a general purpose algorithm (not just for high bandwidth links) - they are using it on the YouTube (and other) content servers as well as between their datacenters. I believe trying to optimise delivery of content to high loss, high latency mobile users was one of the use cases they designed for. See slide 33 here for a comparison to CUBIC under packet loss - https://www.ietf.org/proceedings/98/slides/slides-98-iccrg-an-update-on-bbr-congestion-control-00.pdf https://www.ietf.org/proceedings/98/slides/slides-98-iccrg-a...

Round trip to a satellite will never rival fiber. Especially the way modern web apps are built inefficiently

vandweller 9y ago

Could you expand on this? Do you think latency is the limiting factor for a LEO network?

vorotato 9y ago
A geosynchronous orbit is ~36000km 36000 km / speed of light = .12 seconds So thats a ping of 240, minimum. That's assuming everything else in the system happened instantaneously. If you can however manage to solve the whole aiming at a moving target 360 kilometers away then maybe you could do a LEO network, and yeah the ping would be closer to 1.2 assuming again literally everything was instantaneous.
- jacques_chester 9y ago
  As you note, LEO is very different from geostationary. Moving target doesn't strike me as impossible. A LEO satellite has a very predictable path, a stationary dish has a predictable movement relative to that path and a mobile phone knows where it is at all times.
- greglindahl 9y ago
  There are several companies building (and a few shipping) flat-panel phased array antennae that can "point" at a moving target 360 km away. They also can switch to a new satellite instantly.
- foobarian 9y ago
  One has been online [1] since '98, so it's definitely possible. Question is probably in details around bandwidth and handoff performance. [1] https://en.wikipedia.org/wiki/Iridium_satellite_constellation https://en.wikipedia.org/wiki/Iridium_satellite_constellatio...

nmjohn 9y ago

> SpaceX expects its own latencies to be between 25 and 35ms [0] There is a huge difference in latency between existing satellite internet services and what spacex is looking to launch. [0]: https://arstechnica.com/information-technology/2016/11/spacex-plans-worldwide-satellite-internet-with-low-latency-gigabit-speed/ https://arstechnica.com/information-technology/2016/11/space...

mirimir 9y ago
Yes, SpaceX etc will be low Earth orbit, and the satellites will be a mesh network.
deleted 9y ago
[deleted]
nautilus12 9y ago
It sounda similar to fiber latency. Ive never thought about this before but the amount of time for a round trip to a leo satellite, shouldnt that be in the range of 10 m/s. (1200 km / 300,000 km/ s) = 4 m/s x 2 i wonder whats the complete breakdown, is most of it inter satellite optical communication? Does this offset the additional 8 ms because its a simplified topology?

exabrial 9y ago

I had Google Fiber installed in my apartment a year ago. I was walking through the parking garage and I caught one of the techs doing alignment splicing. I asked him where the nearest Google Fiber Hut was and he said about the quarter mile away near a Taco Bell. I remarked that's pretty good, but he said well it's even further than that because it's not line of sight. He pulled out a tool that could measure the total length of installed fiber via refection... It was over 20,000 feet. And that was just to go from the garage to fiber hut 1/4 mi away. I don't know how the topology of Google's network works, but I thought that was crazy. Granted leo satellites are 1200mi away but it's worth remembering that.

betterunix2 9y ago

It's not just web apps; TCP itself behaves badly under high-latency conditions. If you have no other choice but to use high-latency links, you are better off with a protocol like QUIC that includes forward error correction. If you need to send a lot of data over a high-latency link you need to start looking at less common approaches; for example, this: https://en.wikipedia.org/wiki/Fountain_code https://en.wikipedia.org/wiki/Fountain_code When the link is unreliable -- as it is in most wireless systems -- TCP also tends to behave suboptimally as it assumes lost packets are due to congestion. Again, if you need to deal with unreliable links, forward error correction is your friend.

stephen_g 9y ago
Have a look at Google's BBR congestion control algorithm [1]. This is perhaps a solved problem now (although it's still not supported on all platforms, but only the side sending the bulk of the data needs to have it). 1. http://queue.acm.org/detail.cfm?id=3022184 http://queue.acm.org/detail.cfm?id=3022184
- justicezyx 9y ago
  Bbr is about high bandwidth latency product network with low error rate. Any window based retransmission protocol just breaks under high error rate, that what happens in wireless links.
  - stephen_g 9y ago
    No, BBR does deliver significant performance improvements in high packet loss links. It is designed as a general purpose algorithm (not just for high bandwidth links) - they are using it on the YouTube (and other) content servers as well as between their datacenters. I believe trying to optimise delivery of content to high loss, high latency mobile users was one of the use cases they designed for. See slide 33 here for a comparison to CUBIC under packet loss - https://www.ietf.org/proceedings/98/slides/slides-98-iccrg-an-update-on-bbr-congestion-control-00.pdf https://www.ietf.org/proceedings/98/slides/slides-98-iccrg-a...