* [Starlink] thinking about the laser links again
@ 2021-10-26 1:26 Dave Taht
2021-10-26 13:49 ` Mike Puchol
0 siblings, 1 reply; 18+ messages in thread
From: Dave Taht @ 2021-10-26 1:26 UTC (permalink / raw)
To: starlink; +Cc: Mark Handley
I haven't really been focused on the starlink stuff for many months,
although I do periodically run a test to see if they've fixed their
bufferbloat anywhere. (nope). The networkQuality test from apple is
now shipping in OSX!! and I can think about something else.
I'd written this, I guess, over 2 years ago:
https://www.reddit.com/r/Starlink/comments/brn6gg/will_starlink_have_bufferbloat/
and had had a nice dialog with mark handley (who has since stopped
writing anything about starlink so I kind of assume he went under NDA)
At the time I first started thinking about this I had had a few
objections to his simulations. One was that he made the assumption in
his earliest simulations that the sats would be routing "up there"
rather than down here. The first sats routed simply to the next hop or
a failover hop and that is easy to think about (and the congestion
problems soluble with the tools already developed by the bufferbloat
project). His later sims did that, but neither set seemed to address
congestion control issues.
Now that the first laser sats are launching, thinking about how that
would work, in the dearth of other information, is hard. One number I
don't have is what the actual capacity is for each laser link
(anyone?), and for how long. I'd also thought at the time I'd written
the above that the value of going new york to tokyo primarily by
satellite was a license to print money. The value of that path seemed
to be in the millions/minute range - so I had generally assumed that
usage of it would be governed by a virtual circuit setup, used
internally, or by major governments, or investment houses. It made the
most sense to me to terminate most links back to the ground as quickly
as possible, otherwise.
But in thinking about 33,000 sats... rather than the paltry (cough)
few they've presently flown, as a giant LAG switch that can cross
oceans, I can certainly see the concept being used for more general
purpose traffic especially to the islands of the world. That gets me
to my second question: of the field of view of the sat links?
And then my humdinger question based on their launch schedule and
satellite distribution... how long before they can get a first transit
from new york (or london) to tokyo, borne entirely on the sat laser
links themselves? It needn't be direct, just taking advantage of the
known satellite laser links to get that far.
--
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
Dave Täht CEO, TekLibre, LLC
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-26 1:26 [Starlink] thinking about the laser links again Dave Taht
@ 2021-10-26 13:49 ` Mike Puchol
2021-10-26 17:51 ` Michael Richardson
0 siblings, 1 reply; 18+ messages in thread
From: Mike Puchol @ 2021-10-26 13:49 UTC (permalink / raw)
To: starlink, Dave Taht; +Cc: Mark Handley
[-- Attachment #1: Type: text/plain, Size: 5678 bytes --]
Heya,
My 2 cents - I have some experience with ground-based FSOC links, so I can take educated guesses at what they may be able to achieve.
The laser links, as far as I know, will be able to do in-plane and cross-plane (e.g. between satellites in front and behind in the orbit, or across to the sides). This gives a great level of flexibility, but also complicates the system as you now need a rotating head or full gimbal.
Ground-based FSOC links have a scan time that can range from a few seconds to a few minutes, depending on how long a link has been lost, and they all must begin with a fairly accurate idea of where you are pointed. Setting up a link to a satellite that is more or less static, in front or behind, is relatively easy. If you link is lost, you can re-establish fairly quickly.
Across planes on the same shell, the positions are almost static too, so the same rules apply. From photos, each satellite carries two optical heads, thus IMHO the first generation will link in-plane only, to keep things simple. To do both in-plane and cross-plane, you need at least three optical heads.
Once you add more shells, the problems begin. Optical links work in microradians (0.0000572º, your brain needs to adapt to these new scales…), so when satellites across planes could have relative velocities in the degrees per second, a laser link will have a real hard time to scan for the other site.
I could bore you to death but here’s a quick test you can do: grab a laser pointer and try to keep it on a target the size of the laser dot on a wall 10-15 meters away. You’ll quickly see why doing that at hundreds of kilometers, and between moving vehicles, is a real challenge.
The logical thing to start with would be to keep every shell interconnected, but not to try to cross-link shells. For this, ground-to-satellite links come into play.
How do you make capacities in the petabits per second around your space segment useful? You need to deliver to the ground eventually. IMHO the only way this will hapen is ground-to-satellite links, with the ground stations either in a few, as cloudless as possible locations, or many stations in as geographically diverse configuration as possible, so that at least some will not have cloud cover.
Once you have the ground links to each shell, they can be used to offload to internet backbones, or you can relay data between shells, without complicating your pointing & tracking on the satellites.
I think Dave has a point in that a very obvious use is HFT and the like, as the latencies will be way way lower than what you could achieve with ground fiber.
Mark Handley makes a very good job at explaining in this video (and others he has posted): https://www.youtube.com/watch?v=QEIUdMiColU
Best,
Mike
On Oct 26, 2021, 04:26 +0300, Dave Taht <dave.taht@gmail.com>, wrote:
> I haven't really been focused on the starlink stuff for many months,
> although I do periodically run a test to see if they've fixed their
> bufferbloat anywhere. (nope). The networkQuality test from apple is
> now shipping in OSX!! and I can think about something else.
>
> I'd written this, I guess, over 2 years ago:
> https://www.reddit.com/r/Starlink/comments/brn6gg/will_starlink_have_bufferbloat/
>
> and had had a nice dialog with mark handley (who has since stopped
> writing anything about starlink so I kind of assume he went under NDA)
>
> At the time I first started thinking about this I had had a few
> objections to his simulations. One was that he made the assumption in
> his earliest simulations that the sats would be routing "up there"
> rather than down here. The first sats routed simply to the next hop or
> a failover hop and that is easy to think about (and the congestion
> problems soluble with the tools already developed by the bufferbloat
> project). His later sims did that, but neither set seemed to address
> congestion control issues.
>
> Now that the first laser sats are launching, thinking about how that
> would work, in the dearth of other information, is hard. One number I
> don't have is what the actual capacity is for each laser link
> (anyone?), and for how long. I'd also thought at the time I'd written
> the above that the value of going new york to tokyo primarily by
> satellite was a license to print money. The value of that path seemed
> to be in the millions/minute range - so I had generally assumed that
> usage of it would be governed by a virtual circuit setup, used
> internally, or by major governments, or investment houses. It made the
> most sense to me to terminate most links back to the ground as quickly
> as possible, otherwise.
>
> But in thinking about 33,000 sats... rather than the paltry (cough)
> few they've presently flown, as a giant LAG switch that can cross
> oceans, I can certainly see the concept being used for more general
> purpose traffic especially to the islands of the world. That gets me
> to my second question: of the field of view of the sat links?
>
> And then my humdinger question based on their launch schedule and
> satellite distribution... how long before they can get a first transit
> from new york (or london) to tokyo, borne entirely on the sat laser
> links themselves? It needn't be direct, just taking advantage of the
> known satellite laser links to get that far.
>
>
> --
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
>
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
[-- Attachment #2: Type: text/html, Size: 6587 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-26 13:49 ` Mike Puchol
@ 2021-10-26 17:51 ` Michael Richardson
2021-10-27 6:20 ` Ulrich Speidel
0 siblings, 1 reply; 18+ messages in thread
From: Michael Richardson @ 2021-10-26 17:51 UTC (permalink / raw)
To: Mike Puchol, starlink, Dave Taht, Mark Handley
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
Mike Puchol <mike@starlink.sx> wrote:
> I could bore you to death but here’s a quick test you can do: grab a
> laser pointer and try to keep it on a target the size of the laser dot
> on a wall 10-15 meters away. You’ll quickly see why doing that at
I fail, because the cat attacks me :-)
(our cats somehow know when we get the laser pointers out, even if the
batteries are dead...)
> The logical thing to start with would be to keep every shell
> interconnected, but not to try to cross-link shells. For this,
> ground-to-satellite links come into play.
Or they could interconnect using microwaves, couldn't they?
It's all just different parts of the EM spectrum after all :-)
> How do you make capacities in the petabits per second around your space
> segment useful? You need to deliver to the ground eventually. IMHO the
> only way this will hapen is ground-to-satellite links, with the ground
> stations either in a few, as cloudless as possible locations, or many
> stations in as geographically diverse configuration as possible, so
> that at least some will not have cloud cover.
> Once you have the ground links to each shell, they can be used to
> offload to internet backbones, or you can relay data between shells,
> without complicating your pointing & tracking on the satellites.
What about going the other way? Interconnect via GEO?
Or something resonant to the earth that is not quite so far?
> Mark Handley makes a very good job at explaining in this video (and
> others he has posted): https://www.youtube.com/watch?v=QEIUdMiColU
Thnk you for the link.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-26 17:51 ` Michael Richardson
@ 2021-10-27 6:20 ` Ulrich Speidel
2021-10-27 7:03 ` David Lang
2021-10-27 18:29 ` Michael Richardson
0 siblings, 2 replies; 18+ messages in thread
From: Ulrich Speidel @ 2021-10-27 6:20 UTC (permalink / raw)
To: starlink
[-- Attachment #1: Type: text/plain, Size: 8173 bytes --]
Interesting discussion and one I hoped would pop up! Here's my 5 cents
worth:
Lasers vs. RF (microwave): The problem with RF is that it's
comparatively difficult to produce a sharp beam as you can do with
lasers - mostly due to the fact that the wavelength involved is so much
larger (centimeter scale vs micro-/nanometer scale). On a spacecraft,
this is further compounded by not being able to fly with RF antenna
structures whose size is many orders of magnitude greater than the
wavelength involved. In RF terms, this means transmit power flux going
off into directions where the power isn't needed and in most cases also
not wanted. Not only is this a drain on your bird's power budget, but
also a recipe for interference elsewhere. Plus you have the issue of RF
spectrum being a vastly more constrained resource.
In terms of laser ISLs, space is a pretty benign environment: If you're
linking to another sat at the same orbital altitude or higher, any light
that doesn't hit the satellite goes to places where it's not going to
interfere with anyone else. There's no attenuation or dispersion due to
atmospheric effects, either, and while both vehicles move, the only
significant "noise" that the movement injects would probably come from
the gimbal mechanics I'd guess.
Both lasers and RF suffer from one common problem, though: If the
transmitter is in front of the sun from the receiver's perspective, then
sun's wideband signal is all the receiver will see. This is an issue
even for GEO sats which face foreseeable "outages" twice a year as the
satellite comes to sit in front of the sun for a few minutes. LEOs also
suffer from this problem, e.g., intra-plane links are affected when the
twilight zone is perpendicular to the orbital plane: Any bird flying
into the sunrise will lose signal from the bird in front, and any bird
flying away from sunset will lose signal from the bird behind. Note that
in the high inclination orbits that Starlink currently uses, this is
only an issue for birds near the northern and southern turning points of
the orbit.
Beyond that, laser beams can be optically widened to make pointing
easier. At the end of the day it's a trade off between the amount of
laser power that arrives at the receiver, which determines the feasible
modulation schemes and hence the link's achievable bit rate, and the
ease and robustness of pointing.
Given that satellites are on limited power budgets, any satellite that
needs to carry transit traffic that could be carried on a ground segment
provides premium service. It constrains the satellite's available
bandwidth for traffic that does not have a terrestrial path option, as
well as its capacity for communication with ground stations (in
principle, since it could dedicate the power used to convey the transit
traffic towards a stronger signal in ground direction). This makes
in-plane forwarding a bit of a strange game: the first satellite from
uplink carries all traffic, the second all traffic minus whatever the
first satellite was able to downlink, and so on. Obviously, the
definition of "first satellite" changes over time as the satellite
proceeds in its orbit and as the uplinking ground station on Earth
rotates away from the orbital plane. So you'd have to hand over orbital
planes between different ground stations.
Presuming next-gen Starlink can communicate cross-plane in the same
shell, what are the options? Starlink currently uses cells, which I read
as: "A cell is a geographical area. A satellite assigned to a cell at a
given time can downlink to any Dishy in the cell." So it's probably
reasonable to assume that they'll try to route between cells first and
foremost. So they could:
- Tell satellites where to send packets (in something along the lines of
a long header, as in AX.25 for example). Then a sending ground station
would need a complete almanach of the constellation and an idea as to
where the receiving ground station is, and which satellite it would use
for the downlink. Pros: The sending ground station can do all the number
crunching on ground rather than space power. Cons: Header size costs
bandwidth. How do we ensure the almanach is always complete and correct?
How do we know what the receiver's view of the sky is? One sub-option
here is to treat the space segment merely as an access network. For each
cell, work out a ground station that will always service that cell and,
for any given point in time a combination of satellites needed to
service that route. Have the ground station set up a VC to the satellite
serving the cell. For most areas of the planet, that wouldn't require
more than a couple of satellites to be involved (if Starlink had ground
stations around the globe where there is fibre).
- Get the satellites to work out where stuff needs to be sent. If they
were to use something like Bellman-Ford here, that would require an
enormous amount of update traffic. Dijkstra would require complete
topology information, which should in principle be computable from an
almanach on the satellites. But it's still a lot of number crunching on
a bird. Another option would be for each satellite to compute a great
circle direction to the target cell and then forward to whichever
neighbour satellite comes closest to being along that route.
So yeah, will be interesting to see what they'll actually do, whether
that'll change over time, and whether they'll ever tell anyone.
On 27/10/2021 6:51 am, Michael Richardson wrote:
> Mike Puchol<mike@starlink.sx> wrote:
> > I could bore you to death but here’s a quick test you can do: grab a
> > laser pointer and try to keep it on a target the size of the laser dot
> > on a wall 10-15 meters away. You’ll quickly see why doing that at
>
> I fail, because the cat attacks me :-)
> (our cats somehow know when we get the laser pointers out, even if the
> batteries are dead...)
>
> > The logical thing to start with would be to keep every shell
> > interconnected, but not to try to cross-link shells. For this,
> > ground-to-satellite links come into play.
>
> Or they could interconnect using microwaves, couldn't they?
> It's all just different parts of the EM spectrum after all :-)
>
> > How do you make capacities in the petabits per second around your space
> > segment useful? You need to deliver to the ground eventually. IMHO the
> > only way this will hapen is ground-to-satellite links, with the ground
> > stations either in a few, as cloudless as possible locations, or many
> > stations in as geographically diverse configuration as possible, so
> > that at least some will not have cloud cover.
>
> > Once you have the ground links to each shell, they can be used to
> > offload to internet backbones, or you can relay data between shells,
> > without complicating your pointing & tracking on the satellites.
>
> What about going the other way? Interconnect via GEO?
> Or something resonant to the earth that is not quite so far?
>
> > Mark Handley makes a very good job at explaining in this video (and
> > others he has posted):https://www.youtube.com/watch?v=QEIUdMiColU
>
> Thnk you for the link.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
> ]mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
Ph: (+64-9)-373-7599 ext. 85282
The University of Auckland
ulrich@cs.auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
[-- Attachment #2: Type: text/html, Size: 9929 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-27 6:20 ` Ulrich Speidel
@ 2021-10-27 7:03 ` David Lang
2021-10-27 9:34 ` Ulrich Speidel
2021-10-27 18:29 ` Michael Richardson
1 sibling, 1 reply; 18+ messages in thread
From: David Lang @ 2021-10-27 7:03 UTC (permalink / raw)
To: Ulrich Speidel; +Cc: starlink
[-- Attachment #1: Type: text/plain, Size: 2939 bytes --]
On Wed, 27 Oct 2021, Ulrich Speidel wrote:
> - Get the satellites to work out where stuff needs to be sent. If they were
> to use something like Bellman-Ford here, that would require an enormous
> amount of update traffic. Dijkstra would require complete topology
> information, which should in principle be computable from an almanach on the
> satellites. But it's still a lot of number crunching on a bird. Another
> option would be for each satellite to compute a great circle direction to the
> target cell and then forward to whichever neighbour satellite comes closest
> to being along that route.
Remember, IP routing doesn't require anybody have a global view of the network,
just knowlege of nearby nodes.
So the satellite needs to know what are good next hops to send traffic to that's
headed in different directions, not global knowledge of the entire
constellation.
This doesn't require that all satellites be able to send in all directions. with
lots of satellites in range, they could cycle between the first sending north,
the second east, the third south, the fourth west...
A key question to me is how many lasers, how fast they can be redirected to
different satellites, and how many different satellites the detectors can
receive from at one time.
I'd hope that there are at least two lasers, so that they can transmit to the
next hop and ack to the receiver without having to spin a laser 180.
It also doesn't require that the satellite send to the nearst node in that
direction (if longer distance traffic can be detected, you would want to send to
a further away next hop to reduce the number of hops)
They could even have a satellite varient that has more lasers/detectors and
fewer RF antennas to connect to the ground to be dedicated to routing
(especially as they launch satellites to different altitudes, nodes at higher
altitudes could be optimized for long-distance hops)
With only 'nearby' node knowledge needed, I could see low-power omnidirectional
RF beacons being used for nodes to advertise their existance and routing config
to the network. I expect that if they were doing this, that it would show up in
their FCC filings and everyone would be talking about it, but it's a thought for
future versions.
All of this requies some way to tell from the packet where on earth (or in
space) the destination is. If you tunnel over IPv6, you can have enough IPs to
allocate them based on lat/long/ground/orbit so that the routing nodes (which
know where they are) can know what direction to send things. Given the existance
of mobile endpoints (vehicles, aircraft, spacecraft) this starts sounding like
the mobile IP problem (how can you continue a persistant connection when moving
from netowrk to network), but since all the entry/exit points are under their
control, you can tunnel around and have a protocol to reconfigure the tunnels as
endpoints move.
David Lang
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-27 7:03 ` David Lang
@ 2021-10-27 9:34 ` Ulrich Speidel
2021-10-27 10:49 ` David Lang
2021-10-27 18:37 ` Michael Richardson
0 siblings, 2 replies; 18+ messages in thread
From: Ulrich Speidel @ 2021-10-27 9:34 UTC (permalink / raw)
To: David Lang; +Cc: starlink
On 27/10/2021 8:03 pm, David Lang wrote:
> On Wed, 27 Oct 2021, Ulrich Speidel wrote:
>
>> - Get the satellites to work out where stuff needs to be sent. If
>> they were to use something like Bellman-Ford here, that would require
>> an enormous amount of update traffic. Dijkstra would require complete
>> topology information, which should in principle be computable from an
>> almanach on the satellites. But it's still a lot of number crunching
>> on a bird. Another option would be for each satellite to compute a
>> great circle direction to the target cell and then forward to
>> whichever neighbour satellite comes closest to being along that route.
>
> Remember, IP routing doesn't require anybody have a global view of the
> network, just knowlege of nearby nodes.
Reality check.
IP forwarding (as opposed to routing) checks the destination IP address
against a set of routes in your routing table, which are essentially
destination networks identified by network IP address and netmask. That
decides which interface the routers forwards out through (i.e., to which
neighbour). At a local level, one can often supply these routes manually
as static routes, but at a global level, it still takes the likes of BGP
to help with routing, chiefly because the Internet doesn't have a tree
structure at the global level.
This update with BGP works nicely in a network whose structure never
changes, or changes very slowly, so that set of routes can be updated
manually or automatically in a cyclic fashion. But in the case of
Starlink, much of the network changes continuously.
Things that change for you if you are a Starlink satellite:
- Cells you can service (and therefore hosts attached to Dishys you can
reach). You may be over Brazil now, the Atlantic next, then over the UK,
and then over Germany, and so on... So your on-board routing table would
need to reflect that. You never spend more than a minutes or so over the
same cell.
- Ground station gateways you can attach to - similar timing here.
- Satellites on neighbouring orbital planes in the same shell that are
in the northbound part of their orbit while you're heading south (and
vice versa) come within range and disappear again.
- Neighbouring satellites in different shells.
Things that don't change:
- The satellite in front and behind you in the same orbit.
- Neighbouring satellites orbiting in the same direction in adjacent
orbital planes. These require tracking but are always in range.
So, if we're a satellite, part of our routing table changes every few
seconds because some node that was a neighbour no longer is, and a node
that wasn't now becomes a neighbour. And because nothing in our
constellation-spawned network resembles a tree structure, we'd need
something like BGP to propagate that routing information through the
network. Because we may be the only satellite that can currently serve a
particular destination host, that information needs to propagate through
the network, so other nodes in the network need to know that they need
to send traffic to that destination to us. I say "something like BGP"
here as the network is proprietary, so doesn't have to stick to any open
standards.
Now our neighbours are the first that need to know that we're the new
kid on the block to talk directly to Dave's Dishy, and sending them an
update every few seconds wouldn't be too onerous. But the problem is
that our neighbours, too, are on the move, so we're basically forced to
propagate our update (and everyone else's) throughout the entire network
of thousands of satellites. Moreover, if we consider the fact that along
a forwarding path of a dozen satellites or more between, say Tokyo and
New York, all satellites are on the move, then losing only one link on
that path can render a route completely infeasible. And while our
individual satellite's neighbourhood changes every few seconds, a path
like this might change on a sub-second scale.
So suppose we ignore anything we know about the constellation geometry
and we have N satellites. Say we want to use IP routing still with BGP.
Then each satellite needs to be its own Autonomous System. That boils
down to telling each satellite in the constellation about the
connectivity state of essentially every other satellite (or plane).
That's an O(N^2) problem, so not very scaleable, especially if we need
to do this every few milliseconds (with the required intervals also
decreasing with N). So conventional IP routing doesn't work here, basically.
>
> So the satellite needs to know what are good next hops to send traffic
> to that's headed in different directions, not global knowledge of the
> entire constellation.
True, but that requires a knowledge of direction and a (tunnel) comms
layer below the Internet-wide IP routing. And the question is how that's
best designed.
>
> This doesn't require that all satellites be able to send in all
> directions. with lots of satellites in range, they could cycle between
> the first sending north, the second east, the third south, the fourth
> west...
>
Yes. That's what I was hinting at with the "great circle" option.
> A key question to me is how many lasers, how fast they can be
> redirected to different satellites, and how many different satellites
> the detectors can receive from at one time.
>
> I'd hope that there are at least two lasers, so that they can transmit
> to the next hop and ack to the receiver without having to spin a laser
> 180.
That's an interesting question indeed. What I would add in here is also
the possibility of using optical switching, where one laser beam may be
able to be switched rapidly between different targets.
>
> It also doesn't require that the satellite send to the nearst node in
> that direction (if longer distance traffic can be detected, you would
> want to send to a further away next hop to reduce the number of hops)
In principle, yes, which would be good for both latency and satellite
power budget, but satellites further away will be harder to target with
the same data rate, so there's a trade-off here.
> They could even have a satellite varient that has more
> lasers/detectors and fewer RF antennas to connect to the ground to be
> dedicated to routing (especially as they launch satellites to
> different altitudes, nodes at higher altitudes could be optimized for
> long-distance hops)
I'd consider this not so likely - the system is complex enough as it is,
and I doubt they'll want to add that complexity.
>
> With only 'nearby' node knowledge needed, I could see low-power
> omnidirectional RF beacons being used for nodes to advertise their
> existance and routing config to the network. I expect that if they
> were doing this, that it would show up in their FCC filings and
> everyone would be talking about it, but it's a thought for future
> versions.
I'm speculating here, but from an engineering point of view it makes
most sense to go with an almanach approach to constellation
configuration, i.e., let each bird know where all other birds are at any
one time by providing their orbital parameters to every satellite (slow
rate of change and easy O(N) computation on the satellite). Dishys have
a built-in GPS receiver, so can basically figure out which cell they're
in (once movement between cells is allowed). Currently, I suspect that
Starlink run a protocol where each bird knows which cell it's
responsible for at any one time, and where the bird beacons to Dishys
"Cell X, it's me, bird Y" and where the Dishys then get orbital
parameters either from the bird or an almanach to align their phased
arrays to the bird.
>
> All of this requies some way to tell from the packet where on earth
> (or in space) the destination is. If you tunnel over IPv6, you can
> have enough IPs to allocate them based on lat/long/ground/orbit so
> that the routing nodes (which know where they are) can know what
> direction to send things.
That's indeed an option, although you'd still need a way of reverse
mapping: If I have an IPv6 address I know to be in cell X in Ontario,
which of my peers has a route to there?
> Given the existance of mobile endpoints (vehicles, aircraft,
> spacecraft) this starts sounding like the mobile IP problem (how can
> you continue a persistant connection when moving from network to
> network), but since all the entry/exit points are under their control,
> you can tunnel around and have a protocol to reconfigure the tunnels
> as endpoints move.
Indeed, and that tunnel configuration protocol is where the challenge
lies ;-)
For mobile networks, this task is a little easier as the network between
the entry & exit points is more or less static. Plus, mobile nodes move
at most at hundreds of miles per hour, not tens of thousands.
BTW: Starlink will probably want to avoid ground relays like the plague.
The bulk of their customers won't be stock brokers, and their need will
be for bandwidth rather than minimal latency. The bottlenecks here are
between ground and birds, and between birds. Basically, the nominal
capacity of each Starlink bird is purportedly somewhere around the 20
Gb/s mark in the currently deployed generation. Now, as a rule of thumb,
the average Internet user in the world last year used a continuous
average of 1 Mb/s of data. If we ignore for a moment that connections
are bi-directional and that there is such a thing as peak time, then
that means that under the current bent pipe model, each Starlink
satellite is restricted to at most 20k users. If they want to beat
existing providers on the ground that already offer a few Mb/s, they
need to slash that by at least a factor of 5, again being really
conservative here.
Now those ground providers do have one competitive advantage, and that
is that while their lines are long and low bandwidth, they're not
shared, at least not to the closest CDN server farms, where 70% or so of
today's traffic originates. If two Starlink customers want to watch the
same cat video on FB, the video has to traverse the satellite medium
twice, whereas if two farmers in the Midwest want to do the same on
Verizon, they get two copies off their local CDN and you don't get as
much as a blip on regional or international fibre cables (which
generally run at rates > 20 Gb/s these days).
So if Starlink want to keep customers happy with dozens of Mb/s on
demand, each bird will at most be able to handle a few hundred active
customers at a time. Any use of multiple ground relays along a path
would cut that number substantially.
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
Ph: (+64-9)-373-7599 ext. 85282
The University of Auckland
ulrich@cs.auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-27 9:34 ` Ulrich Speidel
@ 2021-10-27 10:49 ` David Lang
2021-10-27 18:37 ` Michael Richardson
1 sibling, 0 replies; 18+ messages in thread
From: David Lang @ 2021-10-27 10:49 UTC (permalink / raw)
To: Ulrich Speidel; +Cc: David Lang, starlink
On Wed, 27 Oct 2021, Ulrich Speidel wrote:
> Things that change for you if you are a Starlink satellite:
>
> - Cells you can service (and therefore hosts attached to Dishys you can
> reach). You may be over Brazil now, the Atlantic next, then over the UK, and
> then over Germany, and so on... So your on-board routing table would need to
> reflect that. You never spend more than a minutes or so over the same cell.
> - Ground station gateways you can attach to - similar timing here.
however, you know where you are, so the territory you cover is predictable, it
doesn't have to be discovered.
> - Satellites on neighbouring orbital planes in the same shell that are in the
> northbound part of their orbit while you're heading south (and vice versa)
> come within range and disappear again.
> - Neighbouring satellites in different shells.
either by altitude or inclination
> Things that don't change:
>
> - The satellite in front and behind you in the same orbit.
> - Neighbouring satellites orbiting in the same direction in adjacent orbital
> planes. These require tracking but are always in range.
>
> So, if we're a satellite, part of our routing table changes every few seconds
> because some node that was a neighbour no longer is, and a node that wasn't
> now becomes a neighbour. And because nothing in our constellation-spawned
> network resembles a tree structure, we'd need something like BGP to propagate
> that routing information through the network. Because we may be the only
> satellite that can currently serve a particular destination host, that
> information needs to propagate through the network, so other nodes in the
> network need to know that they need to send traffic to that destination to
> us. I say "something like BGP" here as the network is proprietary, so doesn't
> have to stick to any open standards.
this is where I lean into something like allocating ipv6 blocks based on
lat/long and you route based on your location to satellites 'in the right
direction' to reduce this problem from needing global knowledge to only needing
nearby knowledge.
> Now our neighbours are the first that need to know that we're the new kid on
> the block to talk directly to Dave's Dishy, and sending them an update every
> few seconds wouldn't be too onerous. But the problem is that our neighbours,
> too, are on the move, so we're basically forced to propagate our update (and
> everyone else's) throughout the entire network of thousands of satellites.
> Moreover, if we consider the fact that along a forwarding path of a dozen
> satellites or more between, say Tokyo and New York, all satellites are on the
> move, then losing only one link on that path can render a route completely
> infeasible. And while our individual satellite's neighbourhood changes every
> few seconds, a path like this might change on a sub-second scale.
this is why I don't think trying to craft routes to specific nodes is a good
idea. head in the right direction until you reach a satellite that can service
the endpoint.
endpoints need to register themselves with a satellite, that location determines
their IPv6 block, when they move, they register the change (thus my comment
about the mobile IP problem)
> So suppose we ignore anything we know about the constellation geometry and we
> have N satellites. Say we want to use IP routing still with BGP. Then each
> satellite needs to be its own Autonomous System. That boils down to telling
> each satellite in the constellation about the connectivity state of
> essentially every other satellite (or plane). That's an O(N^2) problem, so
> not very scaleable, especially if we need to do this every few milliseconds
> (with the required intervals also decreasing with N). So conventional IP
> routing doesn't work here, basically.
route consolodation (or in this case, lat/long direction) changes this from a
O(N^2) problem to a 'head in the right direction' problem. you (as the
satellite) know where you are, know where nearby satellites are and how they are
moving (you have to know this to aim your laser at them anyway), this should be
enough to head the traffic in the right direction. There may need to be
something more between satellites able to seve the same area to handle the last
couple of hops, but as a general case 'that-a-way' could be 'good enough'
routing.
>> So the satellite needs to know what are good next hops to send traffic to
>> that's headed in different directions, not global knowledge of the entire
>> constellation.
>
> True, but that requires a knowledge of direction and a (tunnel) comms layer
> below the Internet-wide IP routing. And the question is how that's best
> designed.
this the 'IP block tied to geo area' to identify this
>> With only 'nearby' node knowledge needed, I could see low-power
>> omnidirectional RF beacons being used for nodes to advertise their
>> existance and routing config to the network. I expect that if they were
>> doing this, that it would show up in their FCC filings and everyone would
>> be talking about it, but it's a thought for future versions.
> I'm speculating here, but from an engineering point of view it makes most
> sense to go with an almanach approach to constellation configuration, i.e.,
> let each bird know where all other birds are at any one time by providing
> their orbital parameters to every satellite (slow rate of change and easy
> O(N) computation on the satellite). Dishys have a built-in GPS receiver, so
> can basically figure out which cell they're in (once movement between cells
> is allowed). Currently, I suspect that Starlink run a protocol where each
> bird knows which cell it's responsible for at any one time, and where the
> bird beacons to Dishys "Cell X, it's me, bird Y" and where the Dishys then
> get orbital parameters either from the bird or an almanach to align their
> phased arrays to the bird.
I agree, but I'll add that it's more likely that the dishy knows where it is and
looks on the air to see what birds it can hear at what signal strength and then
picks one, rather than it being a purely static assignment (ground clutter
interfering with the signal in some directions, and things I hear about people
'tricking' the system to get coverage outside the supported areas)
>> All of this requies some way to tell from the packet where on earth (or in
>> space) the destination is. If you tunnel over IPv6, you can have enough IPs
>> to allocate them based on lat/long/ground/orbit so that the routing nodes
>> (which know where they are) can know what direction to send things.
> That's indeed an option, although you'd still need a way of reverse mapping:
> If I have an IPv6 address I know to be in cell X in Ontario, which of my
> peers has a route to there?
using the mobile-ip approach, when you connect to the network your dishy
registers it's location and establishes a tunnel endpoint (the cell you are in).
when sending to another dishy, there would need to be a lookup to find it's cell
location, and therefor it's tunnel endpoint. once you have these endpoints, the
satellites can route the traffic betwen them.
>> Given the existance of mobile endpoints (vehicles, aircraft, spacecraft)
>> this starts sounding like the mobile IP problem (how can you continue a
>> persistant connection when moving from network to network), but since all
>> the entry/exit points are under their control, you can tunnel around and
>> have a protocol to reconfigure the tunnels as endpoints move.
>
> Indeed, and that tunnel configuration protocol is where the challenge lies
> ;-)
>
> For mobile networks, this task is a little easier as the network between the
> entry & exit points is more or less static. Plus, mobile nodes move at most
> at hundreds of miles per hour, not tens of thousands.
still the case here. the tunnels end on the dishy, which don't move that much
either (except for spacecraft, which can participate more directly). As I said
above there is more complexity for the last hop handoff as the dishy is
switchign from satellite to satellite, but they are aleady doing something
there.
> BTW: Starlink will probably want to avoid ground relays like the plague. The
> bulk of their customers won't be stock brokers, and their need will be for
> bandwidth rather than minimal latency. The bottlenecks here are between
> ground and birds, and between birds. Basically, the nominal capacity of each
> Starlink bird is purportedly somewhere around the 20 Gb/s mark in the
> currently deployed generation. Now, as a rule of thumb, the average Internet
> user in the world last year used a continuous average of 1 Mb/s of data. If
> we ignore for a moment that connections are bi-directional and that there is
> such a thing as peak time, then that means that under the current bent pipe
> model, each Starlink satellite is restricted to at most 20k users. If they
> want to beat existing providers on the ground that already offer a few Mb/s,
> they need to slash that by at least a factor of 5, again being really
> conservative here.
20k users in a geo area. but the 20k users in the LA area won't affect the 20k
users in the London area as they are on completely different satellites/ground
stations.
My sister is a prime starlink customer, the best she can get is 2Mb (Rural Mi),
she loves the starlink beta. I am in the LA suburbs, but the best I can get
other than cable is bonded DSL to give me 8/2 (I finally was able to get cable,
but would get starlink to be my redundant link, and for special events when I'm
not home).
There are large areas where you are competing against dialup, cell service (with
it's caps) hughs geo service (with it's caps), or wireless ISPs.
> Now those ground providers do have one competitive advantage, and that is
> that while their lines are long and low bandwidth, they're not shared, at
> least not to the closest CDN server farms, where 70% or so of today's traffic
> originates.
'not shared'?? cable is shared, uplinks are underprovisioned. some places it's
not bad, others it's horrid (when I first got Internet back around 2002, I was
on shared cable and switching to 128k SDSL was an improvement in real
performance, if not advertised rates)
> If two Starlink customers want to watch the same cat video on FB,
> the video has to traverse the satellite medium twice, whereas if two farmers
> in the Midwest want to do the same on Verizon, they get two copies off their
> local CDN and you don't get as much as a blip on regional or international
> fibre cables (which generally run at rates > 20 Gb/s these days).
that last mile to the farmers may be a lot harder than you think
> So if Starlink want to keep customers happy with dozens of Mb/s on demand,
> each bird will at most be able to handle a few hundred active customers at a
> time. Any use of multiple ground relays along a path would cut that number
> substantially.
if you give each customer 10M (which, if low latency isn't _that_ bad, not
good for streaming 4k video, but will allow multiple people to stream at lower
res), a satellite by your numbers will handle 1k users.
I am missing something on your talk about ground relays. a given connection
would be at most one ground station per endpoint, they aren't going to go to a
ground station, back to the satellites, to another ground station, just endpoint
-> satellite network -> ground station -> Internet (and if the far end is also
on starlink, possibly the same thing at the other end)
Yes, when you have starlink <-> starlink communication, they will want to keep
it in space, but (unfortunantly), that's not the common usage pattern right now.
David Lang
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-27 6:20 ` Ulrich Speidel
2021-10-27 7:03 ` David Lang
@ 2021-10-27 18:29 ` Michael Richardson
2021-10-28 8:00 ` Ulrich Speidel
1 sibling, 1 reply; 18+ messages in thread
From: Michael Richardson @ 2021-10-27 18:29 UTC (permalink / raw)
To: Ulrich Speidel; +Cc: starlink
[-- Attachment #1: Type: text/plain, Size: 2686 bytes --]
Ulrich Speidel <ulrich@cs.auckland.ac.nz> wrote:
> Lasers vs. RF (microwave): The problem with RF is that it's comparatively
> difficult to produce a sharp beam as you can do with lasers - mostly due to
> the fact that the wavelength involved is so much larger (centimeter
> scale vs
Yeah, I knew that, but I was thinking that the shaper beam is a negative due
to effort pointing it so precisely. Maybe some layer/RF hybrid.
> Both lasers and RF suffer from one common problem, though: If the transmitter
> is in front of the sun from the receiver's perspective, then sun's wideband
> signal is all the receiver will see.
I guess the real question is: have you written the Hollywood Security Theatre
script based upon this issues, and can I play the geek that explains this? :-)
> - Tell satellites where to send packets (in something along the lines of a
> long header, as in AX.25 for example). Then a sending ground station would
> need a complete almanach of the constellation and an idea as to where the
> receiving ground station is, and which satellite it would use for the
> downlink. Pros: The sending ground station can do all the number crunching on
> ground rather than space power. Cons: Header size costs bandwidth.
From what I understood, Starlink shipped some kind of comodity SDN capable
chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes
interpreted in hardware, and a path computation element on the ground should
be able to deal with the calculation.
It's a challenging situation perhaps because the network effectively gets
rewired every few minutes, but ground based computation should be able to
deal with the problem.
> - Get the satellites to work out where stuff needs to be sent. If they were
> to use something like Bellman-Ford here, that would require an enormous
> amount of update traffic. Dijkstra would require complete topology
> information, which should in principle be computable from an almanach on the
> satellites.
I think, but I might be wrong, that there is a pattern which repeats over and
over again. Just need to update the mapping of which satellite is in which
position in the precomputed mesh. No need to send the entire mesh.
One might be able to use RPL(RFC6550) for this, which avoids sending update traffic
if there is no real traffic.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-27 9:34 ` Ulrich Speidel
2021-10-27 10:49 ` David Lang
@ 2021-10-27 18:37 ` Michael Richardson
1 sibling, 0 replies; 18+ messages in thread
From: Michael Richardson @ 2021-10-27 18:37 UTC (permalink / raw)
To: Ulrich Speidel; +Cc: David Lang, starlink
[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]
Ulrich Speidel <ulrich@cs.auckland.ac.nz> wrote:
> IP forwarding (as opposed to routing) checks the destination IP address
> against a set of routes in your routing table, which are essentially
> destination networks identified by network IP address and netmask. That
> decides which interface the routers forwards out through (i.e., to which
> neighbour). At a local level, one can often supply these routes manually as
> static routes, but at a global level, it still takes the likes of BGP to help
> with routing, chiefly because the Internet doesn't have a tree structure at
> the global level.
This is not an accurate view.
You have mixed interior gateways with external gateways.
For external traffic Starlink just needs to pick the right exit node, it
doesn't need to know about the global BGP infrastructure. IPv6 makes this
much simpler (order fewer of networks), so I'd put all my v4 traffic as a
service and/or NAT64.
> Things that change for you if you are a Starlink satellite:
> - Cells you can service (and therefore hosts attached to Dishys you can
> reach). You may be over Brazil now, the Atlantic next, then over the UK, and
> then over Germany, and so on... So your on-board routing table would need to
> reflect that. You never spend more than a minutes or so over the same
> cell.
Yes, you need a complete internal routing view.
This is probably more complex and dealing with the exterior view.
> network need to know that they need to send traffic to that destination to
> us. I say "something like BGP" here as the network is proprietary, so doesn't
> have to stick to any open standards.
The problem is akin to routing in a large DC, with VMs that migrate from
cabinet to cabinet on a regular basis. Only faster. And way more
predicatable.
If I had old silicon, I'd do it with two stacks of MPLS.
If I had newer silicon, then SRv6.
Both cases, with a bunch of PCEs spread around the planet.
I'd love to make the satellites independant of earth support, but that could
be version 3.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-27 18:29 ` Michael Richardson
@ 2021-10-28 8:00 ` Ulrich Speidel
2021-10-28 10:52 ` Mike Puchol
0 siblings, 1 reply; 18+ messages in thread
From: Ulrich Speidel @ 2021-10-28 8:00 UTC (permalink / raw)
To: Michael Richardson; +Cc: starlink
On 28/10/2021 7:29 am, Michael Richardson wrote:
> I guess the real question is: have you written the Hollywood Security
> Theatre
> script based upon this issues, and can I play the geek that explains
> this? :-)
Sure!
>
> > - Tell satellites where to send packets (in something along the
> lines of a
> > long header, as in AX.25 for example). Then a sending ground station
> would
> > need a complete almanach of the constellation and an idea as to
> where the
> > receiving ground station is, and which satellite it would use for the
> > downlink. Pros: The sending ground station can do all the number
> crunching on
> > ground rather than space power. Cons: Header size costs bandwidth.
>
> From what I understood, Starlink shipped some kind of comodity SDN capable
> chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes
> interpreted in hardware, and a path computation element on the ground
> should
> be able to deal with the calculation.
>
> It's a challenging situation perhaps because the network effectively gets
> rewired every few minutes, but ground based computation should be able to
> deal with the problem.
That presumes that the ground station has complete topology information
for the constellation, though. That includes knowing about defective
satellites and lasers etc., birds deviating from assigned orbit.
But in principle, I can see how that could work, yes.
>
> > - Get the satellites to work out where stuff needs to be sent. If
> they were
> > to use something like Bellman-Ford here, that would require an enormous
> > amount of update traffic. Dijkstra would require complete topology
> > information, which should in principle be computable from an
> almanach on the
> > satellites.
>
> I think, but I might be wrong, that there is a pattern which repeats
> over and
> over again. Just need to update the mapping of which satellite is in which
> position in the precomputed mesh. No need to send the entire mesh.
Of course. Bellman-Ford & Co. all assume a network without such
regularities. But you need to make use of those patterns in order to
make things possible - whether you do source or hop-to-hop routing. And
while the configuration of the network is indeed predictable at least
for the near future, it's not simply repeating over and over again. The
current constellation (if viewed in isolation) more or less runs in 95
minute cycles. Earth rotates under the constellation, so the teleports
only return to the same position with respect to the constellation when
multiples of the length of a sidereal day coincide with multiples of 95
minutes. Plus you may find that the Starlink constellation isn't
perfectly regular either in its pattern.
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
Ph: (+64-9)-373-7599 ext. 85282
The University of Auckland
ulrich@cs.auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-28 8:00 ` Ulrich Speidel
@ 2021-10-28 10:52 ` Mike Puchol
2021-10-29 1:12 ` Dave Taht
0 siblings, 1 reply; 18+ messages in thread
From: Mike Puchol @ 2021-10-28 10:52 UTC (permalink / raw)
To: Michael Richardson, Ulrich Speidel; +Cc: starlink
[-- Attachment #1: Type: text/plain, Size: 4498 bytes --]
I cannot add more than the real experts on the networking / topology side, but on the lasers themselves, a question was raised about multiple links. The only way to do it economically is to use a single optical train per link (includes laser TX and photon detector, mirrors, power control, attenuators, etc.).
I raised the idea of an FSOC “flashlight” to what could be counted as people in the top 10 worldwide list of experts in the field. Here, a beam would be made wide enough to have multiple “clients”, as for radio sector antennas. The idea was quickly discarded for a number of reasons, the principal being that you are spreading the photons so much that not enough would reach the other side, at least at any meaningful distance.
Photon detectors that could work are in the scientific instrument category, thus really expensive.
From photos, we know that each satellite has at least two lasers, so we can assume at least in-plane communications.
Best,
Mike
On Oct 28, 2021, 11:01 +0300, Ulrich Speidel <ulrich@cs.auckland.ac.nz>, wrote:
> On 28/10/2021 7:29 am, Michael Richardson wrote:
>
> > I guess the real question is: have you written the Hollywood Security
> > Theatre
> > script based upon this issues, and can I play the geek that explains
> > this? :-)
> Sure!
> >
> > > - Tell satellites where to send packets (in something along the
> > lines of a
> > > long header, as in AX.25 for example). Then a sending ground station
> > would
> > > need a complete almanach of the constellation and an idea as to
> > where the
> > > receiving ground station is, and which satellite it would use for the
> > > downlink. Pros: The sending ground station can do all the number
> > crunching on
> > > ground rather than space power. Cons: Header size costs bandwidth.
> >
> > From what I understood, Starlink shipped some kind of comodity SDN capable
> > chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes
> > interpreted in hardware, and a path computation element on the ground
> > should
> > be able to deal with the calculation.
> >
> > It's a challenging situation perhaps because the network effectively gets
> > rewired every few minutes, but ground based computation should be able to
> > deal with the problem.
>
> That presumes that the ground station has complete topology information
> for the constellation, though. That includes knowing about defective
> satellites and lasers etc., birds deviating from assigned orbit.
>
> But in principle, I can see how that could work, yes.
>
> >
> > > - Get the satellites to work out where stuff needs to be sent. If
> > they were
> > > to use something like Bellman-Ford here, that would require an enormous
> > > amount of update traffic. Dijkstra would require complete topology
> > > information, which should in principle be computable from an
> > almanach on the
> > > satellites.
> >
> > I think, but I might be wrong, that there is a pattern which repeats
> > over and
> > over again. Just need to update the mapping of which satellite is in which
> > position in the precomputed mesh. No need to send the entire mesh.
>
> Of course. Bellman-Ford & Co. all assume a network without such
> regularities. But you need to make use of those patterns in order to
> make things possible - whether you do source or hop-to-hop routing. And
> while the configuration of the network is indeed predictable at least
> for the near future, it's not simply repeating over and over again. The
> current constellation (if viewed in isolation) more or less runs in 95
> minute cycles. Earth rotates under the constellation, so the teleports
> only return to the same position with respect to the constellation when
> multiples of the length of a sidereal day coincide with multiples of 95
> minutes. Plus you may find that the Starlink constellation isn't
> perfectly regular either in its pattern.
>
>
>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
> Ph: (+64-9)-373-7599 ext. 85282
>
> The University of Auckland
> ulrich@cs.auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
[-- Attachment #2: Type: text/html, Size: 5676 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-28 10:52 ` Mike Puchol
@ 2021-10-29 1:12 ` Dave Taht
2021-10-29 1:50 ` David Lang
2021-10-29 2:38 ` Steve Crocker
0 siblings, 2 replies; 18+ messages in thread
From: Dave Taht @ 2021-10-29 1:12 UTC (permalink / raw)
To: Mike Puchol; +Cc: Michael Richardson, Ulrich Speidel, starlink
I spent some time today looking over the job listings for clues (
https://www.spacex.com/careers/index.html?search=linux ) BGP/ISIS
keeps cropping up. It really also looks like they are inventing their
own SDN along the way. And: their public BGP table has gained a bunch
of ipv4/21s lately with a few users reporting a routable IP for a few
days or weeks. I do hope they find a ipv4/12 somewhere or better, as I
think they've discovered CGNs are not particularly fun, and their
projected growth for the next year or two would be within that, (and
one fantasy I harbor is they peer with a bunch of outback BGP AS
holders with a "pro" service)
I've been trying for a few years to get some industry interested in
leveraging 240/4 (at least within their CGN for dishy to dishy comms),
there's a preso on it at the upcoming ietf intarea:
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
I know that's kind of a blue sky thing, but all the code has been
working for years in both bsd and linux, as well as in multiple big
iron routers, amazon, and in openwrt (where we tested it first). Just
someone with balls and $s needs to step up to become a space RIR and
try to make those addrs more routable than we already have....
Anyway, good discussion on this thread!!! but all of you failed to
answer my humdinger question - *when* will they be able to route a
packet from new york to tokyo over the laser links? That kind of event
would be a world network latency record - right up there in
significance with the first inter-imp comms oct 29 1969:
https://en.wikipedia.org/wiki/ARPANET#/media/File:First-arpanet-imp-log.jpg
On Thu, Oct 28, 2021 at 3:53 AM Mike Puchol <mike@starlink.sx> wrote:
>
> I cannot add more than the real experts on the networking / topology side, but on the lasers themselves, a question was raised about multiple links. The only way to do it economically is to use a single optical train per link (includes laser TX and photon detector, mirrors, power control, attenuators, etc.).
>
> I raised the idea of an FSOC “flashlight” to what could be counted as people in the top 10 worldwide list of experts in the field. Here, a beam would be made wide enough to have multiple “clients”, as for radio sector antennas. The idea was quickly discarded for a number of reasons, the principal being that you are spreading the photons so much that not enough would reach the other side, at least at any meaningful distance.
>
> Photon detectors that could work are in the scientific instrument category, thus really expensive.
>
> From photos, we know that each satellite has at least two lasers, so we can assume at least in-plane communications.
>
> Best,
>
> Mike
> On Oct 28, 2021, 11:01 +0300, Ulrich Speidel <ulrich@cs.auckland.ac.nz>, wrote:
>
> On 28/10/2021 7:29 am, Michael Richardson wrote:
>
> I guess the real question is: have you written the Hollywood Security
> Theatre
> script based upon this issues, and can I play the geek that explains
> this? :-)
>
> Sure!
>
>
> - Tell satellites where to send packets (in something along the
>
> lines of a
>
> long header, as in AX.25 for example). Then a sending ground station
>
> would
>
> need a complete almanach of the constellation and an idea as to
>
> where the
>
> receiving ground station is, and which satellite it would use for the
> downlink. Pros: The sending ground station can do all the number
>
> crunching on
>
> ground rather than space power. Cons: Header size costs bandwidth.
>
>
> From what I understood, Starlink shipped some kind of comodity SDN capable
> chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes
> interpreted in hardware, and a path computation element on the ground
> should
> be able to deal with the calculation.
>
> It's a challenging situation perhaps because the network effectively gets
> rewired every few minutes, but ground based computation should be able to
> deal with the problem.
>
>
> That presumes that the ground station has complete topology information
> for the constellation, though. That includes knowing about defective
> satellites and lasers etc., birds deviating from assigned orbit.
>
> But in principle, I can see how that could work, yes.
>
>
> - Get the satellites to work out where stuff needs to be sent. If
>
> they were
>
> to use something like Bellman-Ford here, that would require an enormous
> amount of update traffic. Dijkstra would require complete topology
> information, which should in principle be computable from an
>
> almanach on the
>
> satellites.
>
>
> I think, but I might be wrong, that there is a pattern which repeats
> over and
> over again. Just need to update the mapping of which satellite is in which
> position in the precomputed mesh. No need to send the entire mesh.
>
>
> Of course. Bellman-Ford & Co. all assume a network without such
> regularities. But you need to make use of those patterns in order to
> make things possible - whether you do source or hop-to-hop routing. And
> while the configuration of the network is indeed predictable at least
> for the near future, it's not simply repeating over and over again. The
> current constellation (if viewed in isolation) more or less runs in 95
> minute cycles. Earth rotates under the constellation, so the teleports
> only return to the same position with respect to the constellation when
> multiples of the length of a sidereal day coincide with multiples of 95
> minutes. Plus you may find that the Starlink constellation isn't
> perfectly regular either in its pattern.
>
>
>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
> Ph: (+64-9)-373-7599 ext. 85282
>
> The University of Auckland
> ulrich@cs.auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
--
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
Dave Täht CEO, TekLibre, LLC
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-29 1:12 ` Dave Taht
@ 2021-10-29 1:50 ` David Lang
2021-10-29 2:01 ` Dave Taht
2021-10-29 2:38 ` Steve Crocker
1 sibling, 1 reply; 18+ messages in thread
From: David Lang @ 2021-10-29 1:50 UTC (permalink / raw)
To: Dave Taht; +Cc: Mike Puchol, starlink
As a stunt, I think they will be able to do it fairly soon, using the satellites
that they have launched for polar coverage, they just need to time it so that
they have birds in the right place for a few seconds (and it may not be the
lowest latency possible, but as a stunt, who knows how far they could go)
As a practical thing, a year or two, they need to launch a lot of new birds, and
we don't know what is holding up the starlink launches the last several months.
David Lang
On Thu, 28 Oct 2021, Dave Taht wrote:
> Anyway, good discussion on this thread!!! but all of you failed to
> answer my humdinger question - *when* will they be able to route a
> packet from new york to tokyo over the laser links? That kind of event
> would be a world network latency record - right up there in
> significance with the first inter-imp comms oct 29 1969:
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-29 1:50 ` David Lang
@ 2021-10-29 2:01 ` Dave Taht
2021-10-29 3:06 ` David Lang
0 siblings, 1 reply; 18+ messages in thread
From: Dave Taht @ 2021-10-29 2:01 UTC (permalink / raw)
To: David Lang; +Cc: Mike Puchol, starlink
On Thu, Oct 28, 2021 at 6:51 PM David Lang <david@lang.hm> wrote:
>
> As a stunt, I think they will be able to do it fairly soon, using the satellites
It would be a great stunt. Even with a few ground hops along the way,
they should still be able to establish a speed record.
> that they have launched for polar coverage, they just need to time it so that
> they have birds in the right place for a few seconds (and it may not be the
> lowest latency possible, but as a stunt, who knows how far they could go)
>
> As a practical thing, a year or two, they need to launch a lot of new birds, and
> we don't kno what is holding up the starlink launches the last several months.
Bufferbloat fixes I hope!!! :)
> David Lang
>
> On Thu, 28 Oct 2021, Dave Taht wrote:
>
> > Anyway, good discussion on this thread!!! but all of you failed to
> > answer my humdinger question - *when* will they be able to route a
> > packet from new york to tokyo over the laser links? That kind of event
> > would be a world network latency record - right up there in
> > significance with the first inter-imp comms oct 29 1969:
--
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
Dave Täht CEO, TekLibre, LLC
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-29 1:12 ` Dave Taht
2021-10-29 1:50 ` David Lang
@ 2021-10-29 2:38 ` Steve Crocker
2021-10-29 3:08 ` David Lang
1 sibling, 1 reply; 18+ messages in thread
From: Steve Crocker @ 2021-10-29 2:38 UTC (permalink / raw)
To: Dave Taht; +Cc: Mike Puchol, starlink
[-- Attachment #1: Type: text/plain, Size: 7147 bytes --]
Why wouldn't they make it completely IPv6???
Steve
On Thu, Oct 28, 2021 at 9:12 PM Dave Taht <dave.taht@gmail.com> wrote:
> I spent some time today looking over the job listings for clues (
> https://www.spacex.com/careers/index.html?search=linux ) BGP/ISIS
> keeps cropping up. It really also looks like they are inventing their
> own SDN along the way. And: their public BGP table has gained a bunch
> of ipv4/21s lately with a few users reporting a routable IP for a few
> days or weeks. I do hope they find a ipv4/12 somewhere or better, as I
> think they've discovered CGNs are not particularly fun, and their
> projected growth for the next year or two would be within that, (and
> one fantasy I harbor is they peer with a bunch of outback BGP AS
> holders with a "pro" service)
>
> I've been trying for a few years to get some industry interested in
> leveraging 240/4 (at least within their CGN for dishy to dishy comms),
> there's a preso on it at the upcoming ietf intarea:
> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
>
> I know that's kind of a blue sky thing, but all the code has been
> working for years in both bsd and linux, as well as in multiple big
> iron routers, amazon, and in openwrt (where we tested it first). Just
> someone with balls and $s needs to step up to become a space RIR and
> try to make those addrs more routable than we already have....
>
> Anyway, good discussion on this thread!!! but all of you failed to
> answer my humdinger question - *when* will they be able to route a
> packet from new york to tokyo over the laser links? That kind of event
> would be a world network latency record - right up there in
> significance with the first inter-imp comms oct 29 1969:
>
>
> https://en.wikipedia.org/wiki/ARPANET#/media/File:First-arpanet-imp-log.jpg
>
> On Thu, Oct 28, 2021 at 3:53 AM Mike Puchol <mike@starlink.sx> wrote:
> >
> > I cannot add more than the real experts on the networking / topology
> side, but on the lasers themselves, a question was raised about multiple
> links. The only way to do it economically is to use a single optical train
> per link (includes laser TX and photon detector, mirrors, power control,
> attenuators, etc.).
> >
> > I raised the idea of an FSOC “flashlight” to what could be counted as
> people in the top 10 worldwide list of experts in the field. Here, a beam
> would be made wide enough to have multiple “clients”, as for radio sector
> antennas. The idea was quickly discarded for a number of reasons, the
> principal being that you are spreading the photons so much that not enough
> would reach the other side, at least at any meaningful distance.
> >
> > Photon detectors that could work are in the scientific instrument
> category, thus really expensive.
> >
> > From photos, we know that each satellite has at least two lasers, so we
> can assume at least in-plane communications.
> >
> > Best,
> >
> > Mike
> > On Oct 28, 2021, 11:01 +0300, Ulrich Speidel <ulrich@cs.auckland.ac.nz>,
> wrote:
> >
> > On 28/10/2021 7:29 am, Michael Richardson wrote:
> >
> > I guess the real question is: have you written the Hollywood Security
> > Theatre
> > script based upon this issues, and can I play the geek that explains
> > this? :-)
> >
> > Sure!
> >
> >
> > - Tell satellites where to send packets (in something along the
> >
> > lines of a
> >
> > long header, as in AX.25 for example). Then a sending ground station
> >
> > would
> >
> > need a complete almanach of the constellation and an idea as to
> >
> > where the
> >
> > receiving ground station is, and which satellite it would use for the
> > downlink. Pros: The sending ground station can do all the number
> >
> > crunching on
> >
> > ground rather than space power. Cons: Header size costs bandwidth.
> >
> >
> > From what I understood, Starlink shipped some kind of comodity SDN
> capable
> > chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes
> > interpreted in hardware, and a path computation element on the ground
> > should
> > be able to deal with the calculation.
> >
> > It's a challenging situation perhaps because the network effectively gets
> > rewired every few minutes, but ground based computation should be able to
> > deal with the problem.
> >
> >
> > That presumes that the ground station has complete topology information
> > for the constellation, though. That includes knowing about defective
> > satellites and lasers etc., birds deviating from assigned orbit.
> >
> > But in principle, I can see how that could work, yes.
> >
> >
> > - Get the satellites to work out where stuff needs to be sent. If
> >
> > they were
> >
> > to use something like Bellman-Ford here, that would require an enormous
> > amount of update traffic. Dijkstra would require complete topology
> > information, which should in principle be computable from an
> >
> > almanach on the
> >
> > satellites.
> >
> >
> > I think, but I might be wrong, that there is a pattern which repeats
> > over and
> > over again. Just need to update the mapping of which satellite is in
> which
> > position in the precomputed mesh. No need to send the entire mesh.
> >
> >
> > Of course. Bellman-Ford & Co. all assume a network without such
> > regularities. But you need to make use of those patterns in order to
> > make things possible - whether you do source or hop-to-hop routing. And
> > while the configuration of the network is indeed predictable at least
> > for the near future, it's not simply repeating over and over again. The
> > current constellation (if viewed in isolation) more or less runs in 95
> > minute cycles. Earth rotates under the constellation, so the teleports
> > only return to the same position with respect to the constellation when
> > multiples of the length of a sidereal day coincide with multiples of 95
> > minutes. Plus you may find that the Starlink constellation isn't
> > perfectly regular either in its pattern.
> >
> >
> >
> > --
> > ****************************************************************
> > Dr. Ulrich Speidel
> >
> > School of Computer Science
> >
> > Room 303S.594 (City Campus)
> > Ph: (+64-9)-373-7599 ext. 85282
> >
> > The University of Auckland
> > ulrich@cs.auckland.ac.nz
> > http://www.cs.auckland.ac.nz/~ulrich/
> > ****************************************************************
> >
> >
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>
>
>
> --
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
>
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
[-- Attachment #2: Type: text/html, Size: 9616 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-29 2:01 ` Dave Taht
@ 2021-10-29 3:06 ` David Lang
0 siblings, 0 replies; 18+ messages in thread
From: David Lang @ 2021-10-29 3:06 UTC (permalink / raw)
To: Dave Taht; +Cc: David Lang, Mike Puchol, starlink
On Thu, 28 Oct 2021, Dave Taht wrote:
> On Thu, Oct 28, 2021 at 6:51 PM David Lang <david@lang.hm> wrote:
>>
>> As a stunt, I think they will be able to do it fairly soon, using the satellites
>
> It would be a great stunt. Even with a few ground hops along the way,
> they should still be able to establish a speed record.
I wasn't thinking about this approach, I was talking about the possibility of
using satellites launched for polar coverage, go from New York north along one
string of satellites, and then back south along another string. That only takes
a couple strings in orbit, just wiht the right timing (which is why I called it
a stunt version)
David Lang
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-29 2:38 ` Steve Crocker
@ 2021-10-29 3:08 ` David Lang
2021-10-29 13:13 ` Michael Richardson
0 siblings, 1 reply; 18+ messages in thread
From: David Lang @ 2021-10-29 3:08 UTC (permalink / raw)
To: Steve Crocker; +Cc: Dave Taht, starlink
[-- Attachment #1: Type: text/plain, Size: 7316 bytes --]
On Thu, 28 Oct 2021, Steve Crocker wrote:
> Why wouldn't they make it completely IPv6???
Because IPv4 only services still exist.
For example, try to find a payment service that does IPv6 (for the Scale
conference, that is the only part of our infrastructure that must be IPv4, so
we've been looking for a few years)
David Lang
> Steve
>
> On Thu, Oct 28, 2021 at 9:12 PM Dave Taht <dave.taht@gmail.com> wrote:
>
>> I spent some time today looking over the job listings for clues (
>> https://www.spacex.com/careers/index.html?search=linux ) BGP/ISIS
>> keeps cropping up. It really also looks like they are inventing their
>> own SDN along the way. And: their public BGP table has gained a bunch
>> of ipv4/21s lately with a few users reporting a routable IP for a few
>> days or weeks. I do hope they find a ipv4/12 somewhere or better, as I
>> think they've discovered CGNs are not particularly fun, and their
>> projected growth for the next year or two would be within that, (and
>> one fantasy I harbor is they peer with a bunch of outback BGP AS
>> holders with a "pro" service)
>>
>> I've been trying for a few years to get some industry interested in
>> leveraging 240/4 (at least within their CGN for dishy to dishy comms),
>> there's a preso on it at the upcoming ietf intarea:
>> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
>>
>> I know that's kind of a blue sky thing, but all the code has been
>> working for years in both bsd and linux, as well as in multiple big
>> iron routers, amazon, and in openwrt (where we tested it first). Just
>> someone with balls and $s needs to step up to become a space RIR and
>> try to make those addrs more routable than we already have....
>>
>> Anyway, good discussion on this thread!!! but all of you failed to
>> answer my humdinger question - *when* will they be able to route a
>> packet from new york to tokyo over the laser links? That kind of event
>> would be a world network latency record - right up there in
>> significance with the first inter-imp comms oct 29 1969:
>>
>>
>> https://en.wikipedia.org/wiki/ARPANET#/media/File:First-arpanet-imp-log.jpg
>>
>> On Thu, Oct 28, 2021 at 3:53 AM Mike Puchol <mike@starlink.sx> wrote:
>>>
>>> I cannot add more than the real experts on the networking / topology
>> side, but on the lasers themselves, a question was raised about multiple
>> links. The only way to do it economically is to use a single optical train
>> per link (includes laser TX and photon detector, mirrors, power control,
>> attenuators, etc.).
>>>
>>> I raised the idea of an FSOC “flashlight” to what could be counted as
>> people in the top 10 worldwide list of experts in the field. Here, a beam
>> would be made wide enough to have multiple “clients”, as for radio sector
>> antennas. The idea was quickly discarded for a number of reasons, the
>> principal being that you are spreading the photons so much that not enough
>> would reach the other side, at least at any meaningful distance.
>>>
>>> Photon detectors that could work are in the scientific instrument
>> category, thus really expensive.
>>>
>>> From photos, we know that each satellite has at least two lasers, so we
>> can assume at least in-plane communications.
>>>
>>> Best,
>>>
>>> Mike
>>> On Oct 28, 2021, 11:01 +0300, Ulrich Speidel <ulrich@cs.auckland.ac.nz>,
>> wrote:
>>>
>>> On 28/10/2021 7:29 am, Michael Richardson wrote:
>>>
>>> I guess the real question is: have you written the Hollywood Security
>>> Theatre
>>> script based upon this issues, and can I play the geek that explains
>>> this? :-)
>>>
>>> Sure!
>>>
>>>
>>> - Tell satellites where to send packets (in something along the
>>>
>>> lines of a
>>>
>>> long header, as in AX.25 for example). Then a sending ground station
>>>
>>> would
>>>
>>> need a complete almanach of the constellation and an idea as to
>>>
>>> where the
>>>
>>> receiving ground station is, and which satellite it would use for the
>>> downlink. Pros: The sending ground station can do all the number
>>>
>>> crunching on
>>>
>>> ground rather than space power. Cons: Header size costs bandwidth.
>>>
>>>
>>> From what I understood, Starlink shipped some kind of comodity SDN
>> capable
>>> chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes
>>> interpreted in hardware, and a path computation element on the ground
>>> should
>>> be able to deal with the calculation.
>>>
>>> It's a challenging situation perhaps because the network effectively gets
>>> rewired every few minutes, but ground based computation should be able to
>>> deal with the problem.
>>>
>>>
>>> That presumes that the ground station has complete topology information
>>> for the constellation, though. That includes knowing about defective
>>> satellites and lasers etc., birds deviating from assigned orbit.
>>>
>>> But in principle, I can see how that could work, yes.
>>>
>>>
>>> - Get the satellites to work out where stuff needs to be sent. If
>>>
>>> they were
>>>
>>> to use something like Bellman-Ford here, that would require an enormous
>>> amount of update traffic. Dijkstra would require complete topology
>>> information, which should in principle be computable from an
>>>
>>> almanach on the
>>>
>>> satellites.
>>>
>>>
>>> I think, but I might be wrong, that there is a pattern which repeats
>>> over and
>>> over again. Just need to update the mapping of which satellite is in
>> which
>>> position in the precomputed mesh. No need to send the entire mesh.
>>>
>>>
>>> Of course. Bellman-Ford & Co. all assume a network without such
>>> regularities. But you need to make use of those patterns in order to
>>> make things possible - whether you do source or hop-to-hop routing. And
>>> while the configuration of the network is indeed predictable at least
>>> for the near future, it's not simply repeating over and over again. The
>>> current constellation (if viewed in isolation) more or less runs in 95
>>> minute cycles. Earth rotates under the constellation, so the teleports
>>> only return to the same position with respect to the constellation when
>>> multiples of the length of a sidereal day coincide with multiples of 95
>>> minutes. Plus you may find that the Starlink constellation isn't
>>> perfectly regular either in its pattern.
>>>
>>>
>>>
>>> --
>>> ****************************************************************
>>> Dr. Ulrich Speidel
>>>
>>> School of Computer Science
>>>
>>> Room 303S.594 (City Campus)
>>> Ph: (+64-9)-373-7599 ext. 85282
>>>
>>> The University of Auckland
>>> ulrich@cs.auckland.ac.nz
>>> http://www.cs.auckland.ac.nz/~ulrich/
>>> ****************************************************************
>>>
>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>
>>
>>
>> --
>> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
>>
>> Dave Täht CEO, TekLibre, LLC
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Starlink] thinking about the laser links again
2021-10-29 3:08 ` David Lang
@ 2021-10-29 13:13 ` Michael Richardson
0 siblings, 0 replies; 18+ messages in thread
From: Michael Richardson @ 2021-10-29 13:13 UTC (permalink / raw)
To: David Lang; +Cc: Steve Crocker, starlink
David Lang <david@lang.hm> wrote:
> On Thu, 28 Oct 2021, Steve Crocker wrote:
>> Why wouldn't they make it completely IPv6???
> Because IPv4 only services still exist.
because IPv4 as service works over IPv6-only infrastructure very well.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-10-29 13:13 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-26 1:26 [Starlink] thinking about the laser links again Dave Taht
2021-10-26 13:49 ` Mike Puchol
2021-10-26 17:51 ` Michael Richardson
2021-10-27 6:20 ` Ulrich Speidel
2021-10-27 7:03 ` David Lang
2021-10-27 9:34 ` Ulrich Speidel
2021-10-27 10:49 ` David Lang
2021-10-27 18:37 ` Michael Richardson
2021-10-27 18:29 ` Michael Richardson
2021-10-28 8:00 ` Ulrich Speidel
2021-10-28 10:52 ` Mike Puchol
2021-10-29 1:12 ` Dave Taht
2021-10-29 1:50 ` David Lang
2021-10-29 2:01 ` Dave Taht
2021-10-29 3:06 ` David Lang
2021-10-29 2:38 ` Steve Crocker
2021-10-29 3:08 ` David Lang
2021-10-29 13:13 ` Michael Richardson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox