Author Topic: Starlink : Networking Protocols Discussion  (Read 68466 times)

Online launchwatcher

  • Full Member
  • ****
  • Posts: 756
  • Liked: 726
  • Likes Given: 988
Re: Starlink : Networking Protocols Discussion
« Reply #40 on: 10/03/2020 04:23 am »
a.- never touch the ground except at our two homes, i.e. go home1 -> sat -> home2
b.- always go through a Starlink ground gateway i.e. go home1 -> sat -> gateway -> sat -> home2
c.- some mix of a and b?

In my opinion will be d.
d.   User Terminal1 - sat - Gateway - StarLink POP (point of present with billing system and trafic management) - Gateway - Sat - User Terminal 2
You don't understand how either billing or traffic management works.

maybe not... But considering that I founded a satellite provider in 2003 and by 2018 it had 15,000 terminals on the network, maybe I still understand something in this business
 ;)
We're not going to get the low latency Elon promises unless rx antennas, gateway & what you call "POP" are colocated:

"Average latency will improve as more satellites launch (directly above you more frequently) & more ground stations are deployed. As we’re able to put more ground stations on roofs of server centers, legacy Internet latency will be zero."

https://twitter.com/elonmusk/status/1311923618679607298

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #41 on: 10/03/2020 05:59 am »
a.- never touch the ground except at our two homes, i.e. go home1 -> sat -> home2
b.- always go through a Starlink ground gateway i.e. go home1 -> sat -> gateway -> sat -> home2
c.- some mix of a and b?

In my opinion will be d.
d.   User Terminal1 - sat - Gateway - StarLink POP (point of present with billing system and trafic management) - Gateway - Sat - User Terminal 2
You don't understand how either billing or traffic management works.

maybe not... But considering that I founded a satellite provider in 2003 and by 2018 it had 15,000 terminals on the network, maybe I still understand something in this business
 ;)

Tell me more.  GEO, MEO, or LEO satellites?  How many POPs (i.e., non-subscriber ground stations)?  What kind of traffic?

What you're describing makes absolutely no sense--unless there's only one POP.
« Last Edit: 10/03/2020 07:52 am by TheRadicalModerate »

Offline vsatman

Re: Starlink : Networking Protocols Discussion
« Reply #42 on: 10/03/2020 08:06 pm »

Tell me more.  GEO, MEO, or LEO satellites?  How many POPs (i.e., non-subscriber ground stations)?  What kind of traffic?

What you're describing makes absolutely no sense--unless there's only one POP.

1) GEO
2)  We in our industry not use words  "non-subscriber ground stations"
There are teleports  (place for antennas) and HUB or NOC (network operatiomal center) . We have 2 teleports in Russia (and some years ago we rent Uplink and had our NOC in teleport Brewster. WA) 
Mostly we use DirecWay, HughesNet, HX, last is Jupiter  as NOC. Another what we  have or support are Evolution from iDirect, LinkStar from ViaSat,   and some HW from Gilat anf Newtec
3) Here under POP  I understand place  where provider (Space X)  change user`s   trafic with other US internet providers .. 

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #43 on: 10/03/2020 10:06 pm »

Tell me more.  GEO, MEO, or LEO satellites?  How many POPs (i.e., non-subscriber ground stations)?  What kind of traffic?

What you're describing makes absolutely no sense--unless there's only one POP.

1) GEO
2)  We in our industry not use words  "non-subscriber ground stations"
There are teleports  (place for antennas) and HUB or NOC (network operatiomal center) . We have 2 teleports in Russia (and some years ago we rent Uplink and had our NOC in teleport Brewster. WA) 
Mostly we use DirecWay, HughesNet, HX, last is Jupiter  as NOC. Another what we  have or support are Evolution from iDirect, LinkStar from ViaSat,   and some HW from Gilat anf Newtec
3) Here under POP  I understand place  where provider (Space X)  change user`s   trafic with other US internet providers ..

OK.  So using your terminology, you don't route traffic from your teleports (what Starlink calls "gateways") through your NOC, do you?  You collect usage data at the teleport, summarize it, and send it back to the NOC, while the actual data packets go on to whoever you're using for a transit carrier, right?

What you've been describing for Starlink would be the equivalent of taking traffic from hundreds of their gateways and routing it back to the NOC.  That's not going to happen.  Each gateway--and frankly each satellite--will enforce traffic policy and will summarize usage data.  The amount of traffic between the routing elements (the birds and gateways) and the NOC will be measured in kbps, not Gbps.

Yes, the gateways are where traffic is exchanged with transit ISPs.  They are, in internet parlance,  "border gateways", and they communicate routing information with the other ISPs using BGP, the "border gateway protocol".  But once the data packet is handed off to the peer carrier, it's gone.

Offline vsatman

Re: Starlink : Networking Protocols Discussion
« Reply #44 on: 10/04/2020 05:22 pm »
OK.  So using your terminology, you don't route traffic from your teleports (what Starlink calls "gateways") through your NOC, do you?  You collect usage data at the teleport, summarize it, and send it back to the NOC, while the actual data packets go on to whoever you're using for a transit carrier, right?

???? Not undestand..
 to simplify  - I hope you know  HughesNet ?? and as it works??

We make 100% the  same , but  in small size ..
 if Hughes has about 800000 VSAT , we have only 15000.

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #45 on: 10/04/2020 11:06 pm »
OK.  So using your terminology, you don't route traffic from your teleports (what Starlink calls "gateways") through your NOC, do you?  You collect usage data at the teleport, summarize it, and send it back to the NOC, while the actual data packets go on to whoever you're using for a transit carrier, right?

???? Not undestand..
 to simplify  - I hope you know  HughesNet ?? and as it works??

We make 100% the  same , but  in small size ..
 if Hughes has about 800000 VSAT , we have only 15000.

Yeah, it's a bent-pipe with a very small number (1? More than 1?) of gateways.  If the NOC and the gateway are co-located, then what you're describing works fine.

I've been a Hughesnet user before, and it's pretty clear that they're proxying all TCP connections to either the gateway or the NOC, so that each SYN-SYN-ACK exchange doesn't take 700ms.  It just so happened that I had to use an IPsec-based VPN to work from out in the woods, and the modem couldn't recognize the TCP connection packets.  That made any kind of web browsing almost unusable.

This architecture is completely untenable for Starlink, where hundreds of gateways will be required for full global coverage.
« Last Edit: 10/04/2020 11:07 pm by TheRadicalModerate »

Offline vsatman

Re: Starlink : Networking Protocols Discussion
« Reply #46 on: 10/05/2020 08:50 pm »
Yeah, it's a bent-pipe with a very small number (1? More than 1?) of gateways.  If the NOC and the gateway are co-located, then what you're describing works fine.
I've been a Hughesnet user before, and it's pretty clear that they're proxying all TCP connections to either the gateway or the NOC, so that each SYN-SYN-ACK exchange doesn't take 700ms.  It just so happened that I had to use an IPsec-based VPN to work from out in the woods, and the modem couldn't recognize the TCP connection packets.  That made any kind of web browsing almost unusable.
This architecture is completely untenable for Starlink, where hundreds of gateways will be required for full global coverage.

For Star topology VSAT Network  NOC and Gateway are in one place - NOC managed  network , time to  transmit, size for packetы and its places in  frames for all VSATs .  The Gateway is door outside networks to internet.

and yes,  if you use IPsec-based VPN  HughesNet  (and another NOC  Viasat , Gilat etc.) not see headers and cannot use spoofing and  transmit with normal speed 2..10 Mbits.. in this case  you have 200...400 kbits not more. Latency 700..800 ms - is big problem. Internet via GSO is not competitive service .

About Starlink  - each Starlink Satellite has  typical star topology network with 1 Gateway operated (managed)  by a single NOC for the entire network. I don't see why something else as bent pipe is needed here.
 "simplest way is the best!"


 

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #47 on: 10/06/2020 05:44 am »
About Starlink  - each Starlink Satellite has  typical star topology network with 1 Gateway operated (managed)  by a single NOC for the entire network. I don't see why something else as bent pipe is needed here.
 "simplest way is the best!"

I agree that bent pipe is fine, except for locations out of range of a gateway.  That's not what you said, though:

Quote
d.   User Terminal1 - sat - Gateway - StarLink POP (point of present with billing system and trafic management) - Gateway - Sat - User Terminal 2

My complaint is that you don't do traffic management and billing in some POP downstream of the gateway.  The gateway itself sends billing info to and receives traffic management policies from a NOC that's completely out of the data path.  The gateway is the POP.

Almost all flows between subscribers (except for flows going between subscribers on the same satellite, transoceanic flows, or flows with low-latency QoS) will go sub1 -> satellite1 -> gw1 -> terrestrial transit internet -> gw2 -> satellite2 -> sub2.

Offline vsatman

Re: Starlink : Networking Protocols Discussion
« Reply #48 on: 10/07/2020 06:51 pm »
My complaint is that you don't do traffic management and billing in some POP downstream of the gateway.  The gateway itself sends billing info to and receives traffic management policies from a NOC that's completely out of the data path.  The gateway is the POP.
GW is point where interin proprietary protocol is changing in IP (4 or 6) and go in fiber. But trafic has to route in  facebook or tiktok, but GW is  in mounts in 30 miles  from small town in  Montana. 
what is the pass  for IP packets ??

Online launchwatcher

  • Full Member
  • ****
  • Posts: 756
  • Liked: 726
  • Likes Given: 988
Re: Starlink : Networking Protocols Discussion
« Reply #49 on: 10/07/2020 08:52 pm »
My complaint is that you don't do traffic management and billing in some POP downstream of the gateway.  The gateway itself sends billing info to and receives traffic management policies from a NOC that's completely out of the data path.  The gateway is the POP.
GW is point where interin proprietary protocol is changing in IP (4 or 6) and go in fiber. But trafic has to route in  facebook or tiktok, but GW is  in mounts in 30 miles  from small town in  Montana. 
what is the pass  for IP packets ??
huh?   is there any evidence that Starlink isn't passing ip packets end-to-end (encapsulated in its own link layer?)


Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #50 on: 10/07/2020 10:08 pm »
My complaint is that you don't do traffic management and billing in some POP downstream of the gateway.  The gateway itself sends billing info to and receives traffic management policies from a NOC that's completely out of the data path.  The gateway is the POP.
GW is point where interin proprietary protocol is changing in IP (4 or 6) and go in fiber. But trafic has to route in  facebook or tiktok, but GW is  in mounts in 30 miles  from small town in  Montana. 
what is the pass  for IP packets ??

A Starlink gateway is more than just a protocol converter.  It's the actual border router.  So the GW in the mountains in Montana passes IP packets to some terrestrial ISP and forgets about them.  After that, they're just ordinary internet packets, to be routed to Facebook or Tiktok or wherever.  "Wherever" also includes being routed to another Starlink gateway, where they're sent to a satellite and then bounced down to some other subscriber.  So you can do regular client-server traffic or peer-to-peer traffic exactly the same way.

Now that I know you're a Hughesnet VNO, I think I understand your confusion:  Hughesnet doesn't really work like this, because it has to proxy TCP at the gateway.  To internet websites and other TCP applications, the gateway looks like a whole bunch of endpoints (internet browsers or TCP applications), and the subscriber nodes effectively don't exist.  It's only when there's IP traffic that can't be recognized as TCP (either because it's something like UDP, or because the IP packets are encrypted) that the IP endpoint appears to be actually on the subscriber node.

That's not how Starlink is going to work.  The subscriber node is always the IP endpoint, for all traffic, because it doesn't suffer from the horrible latency problems that occur when using a GSO satellite.  If a web browser in a Starlink customer's farmhouse in Montana needs to establish a TCP connection with Facebook, it just establishes the connection by sending a SYN packet, which goes end-to-end to the server (or peer), which sends an end-to-end SYN packet back to Montana, which dutifully sends the ACK packet, and now the connection is fully open to send or receive data packets. 

That customer's neighbor, using Hughesnet or most other GSO systems, tries to establish the same connection, but the satellite modem intercepts the connection request and tunnels it back to the gateway, reducing the 600ms latency that the TCP SYN-SYN-ACK connection establishment would take down to almost only 200ms, and in the process preventing the neighbor from tearing his hair out.  But the cost of that tunnel is that the gateway has to act as the endpoint and do the SYN-SYN-ACK handshake itself, which means that it really is a protocol converter.

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #51 on: 10/07/2020 10:17 pm »
huh?   is there any evidence that Starlink isn't passing ip packets end-to-end (encapsulated in its own link layer?)

There's some Elon Twitter evidence that the packets inside the Starlink network (i.e. between the subscriber modem, the satellite(s), and the gateway(s)) might be stripping IP and substituting something lighter weight.  If that's actually true, then the subscriber modem and the gateway would have to convert between IPv4/6 and this hypothetical lightweight protocol.  But the net result will be that it looks like an IP packet to the rest of the internet, and the conversion process will be really fast and dumb.  (Personally, I won't be surprised if Starlink packets are IPv6 encapsulated with a proprietary MAC header, which makes conversion just as fast and dumb as any other IP router, but either way will work.)

Note that GSO internet systems are more complicated than this, doing much more complex protocol conversion on TCP streams at the gateway, to reduce connection setup latency, which kills your browser performance if you don't do it.

Offline DigitalMan

  • Full Member
  • ****
  • Posts: 1679
  • Liked: 1178
  • Likes Given: 76
Re: Starlink : Networking Protocols Discussion
« Reply #52 on: 10/07/2020 11:12 pm »
My complaint is that you don't do traffic management and billing in some POP downstream of the gateway.  The gateway itself sends billing info to and receives traffic management policies from a NOC that's completely out of the data path.  The gateway is the POP.
GW is point where interin proprietary protocol is changing in IP (4 or 6) and go in fiber. But trafic has to route in  facebook or tiktok, but GW is  in mounts in 30 miles  from small town in  Montana. 
what is the pass  for IP packets ??

A Starlink gateway is more than just a protocol converter.  It's the actual border router.  So the GW in the mountains in Montana passes IP packets to some terrestrial ISP and forgets about them.  After that, they're just ordinary internet packets, to be routed to Facebook or Tiktok or wherever.  "Wherever" also includes being routed to another Starlink gateway, where they're sent to a satellite and then bounced down to some other subscriber.  So you can do regular client-server traffic or peer-to-peer traffic exactly the same way.

Now that I know you're a Hughesnet VNO, I think I understand your confusion:  Hughesnet doesn't really work like this, because it has to proxy TCP at the gateway.  To internet websites and other TCP applications, the gateway looks like a whole bunch of endpoints (internet browsers or TCP applications), and the subscriber nodes effectively don't exist.  It's only when there's IP traffic that can't be recognized as TCP (either because it's something like UDP, or because the IP packets are encrypted) that the IP endpoint appears to be actually on the subscriber node.

That's not how Starlink is going to work.  The subscriber node is always the IP endpoint, for all traffic, because it doesn't suffer from the horrible latency problems that occur when using a GSO satellite.  If a web browser in a Starlink customer's farmhouse in Montana needs to establish a TCP connection with Facebook, it just establishes the connection by sending a SYN packet, which goes end-to-end to the server (or peer), which sends an end-to-end SYN packet back to Montana, which dutifully sends the ACK packet, and now the connection is fully open to send or receive data packets. 

That customer's neighbor, using Hughesnet or most other GSO systems, tries to establish the same connection, but the satellite modem intercepts the connection request and tunnels it back to the gateway, reducing the 600ms latency that the TCP SYN-SYN-ACK connection establishment would take down to almost only 200ms, and in the process preventing the neighbor from tearing his hair out.  But the cost of that tunnel is that the gateway has to act as the endpoint and do the SYN-SYN-ACK handshake itself, which means that it really is a protocol converter.

Also, since Elon mentioned the goal of putting gateways at data centers (such as google or facebook), with 0 legacy internet latency, it would be impractical to work in the way that some suggest.

Offline watermod

  • Full Member
  • ****
  • Posts: 519
  • Liked: 177
  • Likes Given: 153
Re: Starlink : Networking Protocols Discussion
« Reply #53 on: 10/08/2020 10:15 am »
Also, since Elon mentioned the goal of putting gateways at data centers (such as google or facebook), with 0 legacy internet latency, it would be impractical to work in the way that some suggest.
That's interesting.  It would suggest gateways at the major internet stock trading companies and at places like the Dow Jones stock computer centers.   Same would go for meeting software so a gateway at Zoom and one at Skype might be in the works too.  Same for Amazon and Apple's Siri.

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #54 on: 10/08/2020 08:06 pm »
Also, since Elon mentioned the goal of putting gateways at data centers (such as google or facebook), with 0 legacy internet latency, it would be impractical to work in the way that some suggest.
That's interesting.  It would suggest gateways at the major internet stock trading companies and at places like the Dow Jones stock computer centers.   Same would go for meeting software so a gateway at Zoom and one at Skype might be in the works too.  Same for Amazon and Apple's Siri.

That doesn't really sound like a gateway.  It sounds more like the endpoint for a commercial subscriber.  The more interesting gateways will be the ones placed at internet exchange points, which are sorta-kinda datacenters, but with big racks of routers instead of big racks of servers.  IXPs are often where transit and edge ISPs peer to swap traffic.

Offline DigitalMan

  • Full Member
  • ****
  • Posts: 1679
  • Liked: 1178
  • Likes Given: 76
Re: Starlink : Networking Protocols Discussion
« Reply #55 on: 10/08/2020 09:32 pm »
Also, since Elon mentioned the goal of putting gateways at data centers (such as google or facebook), with 0 legacy internet latency, it would be impractical to work in the way that some suggest.
That's interesting.  It would suggest gateways at the major internet stock trading companies and at places like the Dow Jones stock computer centers.   Same would go for meeting software so a gateway at Zoom and one at Skype might be in the works too.  Same for Amazon and Apple's Siri.

That doesn't really sound like a gateway.  It sounds more like the endpoint for a commercial subscriber.  The more interesting gateways will be the ones placed at internet exchange points, which are sorta-kinda datacenters, but with big racks of routers instead of big racks of servers.  IXPs are often where transit and edge ISPs peer to swap traffic.

You're right, he did call them ground stations, not gateways.

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #56 on: 10/10/2020 11:31 pm »
Same would go for meeting software so a gateway at Zoom and one at Skype might be in the works too.  Same for Amazon and Apple's Siri.

For a long time I've only been an amateur space geek, but before I retired I was an actual expert at live voice and video telecommunications.  I don't know for sure how Zoom does this, but I know exactly how Facetime and Skype do it.  I'm about 99.9% sure that Zoom does the same thing.

When you establish a connection between user A and user B for a voice or voice/video call, there's first a signaling step, which then establishes a bearer channel between the two users' devices.  Signaling is not overly latency sensitive; it's what's happening in the moment between when you press "connect" and you hear ringback.

Signaling usually is implemented in a client/server model.  The user's client uses DNS to find the Skype/Zoom/Facetime/whatever server, and the two engage in a protocol, during which the server locates the client being called and starts signaling it as well.  The standard these days is something called the Session Initiation Protocol (SIP), but there are proprietary versions, as well as variants that work somewhat better when implemented as web applications (the IETF has an "rtcweb" group that handles this).  Part of that protocol results in the negotiation of an encoding format between user A's and user B's devices, as well as an exchange of IP addresses and port numbers over which the encoded packets will flow.  That then establishes the bearer channel.

From then on, there's almost no signaling with the server; the bearer packets go peer-to-peer.

However, note that there's very little improvement in signaling performance if the signaling protocol goes through inter-satellite links or just over the terrestrial internet.  The difference between the two results in the phone ringing maybe 200ms later in one vs. the other. 

But there can be a lot of difference in conversation quality for the bearer packets, because delays in the bearer channel result in people trying to talk over each other, which gets really annoying.  (This is why TV interviews taking place over Zoom are so chaotic, with people interrupting each other even more than they already do on TV.)

So putting a ground station on the Zoom server doesn't do much.  However, letting the bearer packets flow over the inter-satellite links could be a nice improvement in conversation quality, and worth the premium for some types of telepresence.

The same basic separation of signaling and bearer happens in a lot of different applications:  gaming, tele-robotics, and other forms of tele-control are all examples.

Now some weasel words:  When you have multipoint teleconferences (i.e., conversations between more than two people), these days it usually works same way as I described, with a separate bearer stream being established between each pair of users.  But as the number of users in the conference rises, this requires more and more total bandwidth, and more and more computational load on the users' devices.  At some point, it becomes easier to allocate a "multipoint control unit" which then handles a single bearer channel between itself and each member of the conference.  That effectively converts the bearer channels from the peer-to-peer model back to a client-server model.  These days, you can easily get more than 5 participants in a conference before you need to put an MCU in the loop.  But when you do, reducing latency to the server becomes just as important as reducing it to the users, and a dedicated ground station could be desirable for this (relatively small) segment of the conferencing market.  However, big public conferencing services typically distribute their MCUs out to POPs close to their customers, which reduces latency, which again tilts the balance back to the terrestrial net.

Note that video streaming (Netflix, Amazon, Hulu, etc.) works somewhat differently from this, but streaming doesn't have a latency issue at all, for the same reason it doesn't matter whether the phone rings 200ms later:  once the connection is set up, all you care about is throughput, not latency.

Streaming services also use content distribution networks, which are a network of servers between the main repository and the consumers of the content.  This is pretty much the same architecture as moving the MCUs into the POPs:  you have content caches in the POPs, which are fed from the main repository using a whole raft of algorithms so that the content most likely to be requested is near to the requester.

As with live video, this makes the terrestrial network a better choice for most content.  Starlink will have excellent latency with the inter-satellite links, but mediocre-to-lousy throughput.  The terrestrial net has it the other way around:  excellent throughput, so-so latency.

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #57 on: 10/24/2020 06:14 am »
Copied over from the Starlink: General Discussion thread.

There are two dishes on each satellite for communicating with the gateways over Ka-band.  The user terminals communicate with the satellite over Ku-band frequencies.

So when a gateway either goes offline or falls too far up-range, the dish assigned to it should find the furthest accessible gateway down-range, and the other dish handles all of the traffic until the other one is back up.

Terminals are going to experience a large number of router flaps, because they have to re-home to the next bird coming overhead.  But the consequences of those flaps (out-of-order packets being the worst) can be minimized if the birds route the same flows to the same gateways. 

I think that implies that, as a gateway falls too far up-range for a bird to use, it should release all the terminals being routed through that gateway, forcing them to re-bind to the next bird up-range.  That bird will likely have the same gateway bound, so the flow shouldn't experience any out-of-order packets.
This is why I've been thinking that part of the OSI stack will need to be custom. As a sat starts reaching the end of its useful range for a particular end user it will need to tell the end users hardware to start transmitting to another sat but to keep listening for a while in case there are packets in transit that didn't get the memo. Gateway connections will face the same issues.

You really mean the TCP/IP stack here, not OSI.  Every time you say OSI in that context I get PTSD-like ISO 8073 flashbacks.  That was a dark time, man.

That said:

1) The OSI layering works fine for this handoff.

2) IP networks do this kind of handoff all the time.  It's what happens when the cellular network hands your phone off to another base station.  It's a solved problem.

In the worst case, the old bird receives traffic for an ex-terminal and it simply feeds it back to one of its current gateways for forwarding.  This can result in some out-of-order packets.  In general, out-of-order packets can cause problems, but TCP has both fast retransmit and selective ACK features that will handle this if it's fairly limited, without dropping into congestion avoidance.

Quote
This most logically fits into MAC function. It's literally a 'sliding window' problem with a twist. From a ground point of view it's a fixed window (let's ignore mobile users) with sats sliding into and out of the window. From the sats point of view the window is sliding to expose new connections while loosing others. Logically they are very similar.

The Starlink MAC likely contains the decision for what terminal to allow to register, and also when to tell it that it's dropped and needs to go find the next up-range bird.  But there are no connections at this level.  There are only packets, and the decision whether to accept them or not.

IP is fine with this kind of stuff, both on the router side (where the IP addresses of now-discarded terminals simply show up with next hops to a gateway), and on the terminal side (where this is basically equivalent to losing your DHCP lease and needing to do another router discovery).

Quote
Let's ignore gateway connections as the connection issues are similar, maybe simpler, and independent from the bandwidth carried.

Each sat has a customer load that changes over time. The following sat, or one a few slots back, needs to know what customers load it's about to receive, and just as important, needs a fairly good idea where to aim the beam.

Nope.  All the up-range bird needs to know is that a terminal is asking to register in a spot that's under its control.  (Presumably, the bird that just dumped the terminal has enough state not to accidentally re-accept a registration request.)

Quote
The initial hookup will be a delicate process if the sat has to spread a wide low gain beam trying to find the end user. Much better to have a good idea where to aim and with only a little beam spread and little loss of gain, nail it and get down to work. If a pass off needs geographical data, why not make long/lat an appendage to the MAC address?

The geographic modeling software is a done thing. I'd be dumbfounded if there weren't libraries, maybe open source. A GPS for the customer hardware is trivial. What's hard is how a brand new end user would get hooked up the very first time. How would the sat know where to aim? How would the terminal know where to look for a sat?

The only thing I can come up with is a beacon signal put out by the ground equipment spread wide enough to have a high probability of snagging a sat at any time.

On the sat end a beam doing scans looking for beacon signals. The beam width and gain would be limited by the number of antenna elements that can be dedicated to this. Beacon signals would always be at a set frequency with no hopping and the sat is always looking.

When the sat picks up a beacon it can throw more elements into the beam to pin a rough position for the beacon and raise gain enough to upload exact position and download an updated sat ephemeris if necessary. At that point the link can move over to he general comms band and the search array can continue looking for beacons.

If I were doing this, I'd have the terminal know the ephemeris for the up-range birds and start beaconing the proper section of sky, with the proper beam steering, one after another until one of them accepted the registration.  Ain't no stinkin' low power, man.  Just blast away in the general vicinity until you find something.

Yes, this is absolutely dependent on GPS to work quickly.  Yes, there may be a case where the ephemeris in the terminal's NVRAM as shipped from the factory is out of date, and finding the first bird takes a while.  But that's done at installation time, once.

As for lat/long in the MAC header, it's a lot of useless bits.  Instead, I'd include the lat/long in the registration beacon.  After that, the bird knows where the terminal is, and knows when to cut it loose.

However, I do think that it's probably useful for the network to segment all potential service areas (i.e., the whole globe, eventually), into a geographically fixed set of regions, and encode the region number as part of the IPv6 address for the terminal.  That makes routing really simple.  But you don't want that stuff in the MAC, because then it's not visible to IP.  IP addressing architectures are often geographically based; this is nothing new.

This does have an implication for the satellite, however.   It shouldn't just let a spot beam drift across the face of the earth.  Instead, the spot beams should "snap" to one of the identified regions.  That lets the whole network easily compute which satellites have which IP addresses, which makes the routing tables very efficient.

Note that mobile terminals, especially fast mobile terminals, are going to need a different architecture than the fixed terminals.  I'd expect their IP addresses to be structured differently, and the routing lookups for them to be a little less efficient. 
« Last Edit: 10/24/2020 06:20 am by TheRadicalModerate »

Offline OTV Booster

  • Senior Member
  • *****
  • Posts: 5103
  • Terra is my nation; currently Kansas
  • Liked: 3553
  • Likes Given: 6004
Re: Starlink : Networking Protocols Discussion
« Reply #58 on: 10/24/2020 07:24 pm »
RadicalModerate: Wuff! I actually understood a lot of that. Nice. My networking experience damped out with the tech bubble and my routing background... Well, let's just say it's lacking.


[size=78%]"You really mean the TCP/IP stack here, not OSI.[/size]"
TCP/IP is two layers of the OSI model, isn't it? You referenced some history I'm not familiar with. Terminology changes. Didn't mean to bring up painful memories.


The reason I was focusing on MAC is because so many of the issues are strictly hardware. The sat and the user terminal need to do beam forming and aiming. This profoundly different than a router deciding which of a few physical ports to use. ISTM that this could 'almost' be done in hardware with software supplying some tables. This would reduce internal management bandwidth.


Appending Lat/long To the MAC really isn't all that many bits, and it brings it to attention of MAC without intervention of a higher layer. Ground location precision need not be much greater than ~ 1/4 the sat beam diameter at the surface and shouldn't require all that many bits. At the equator, one minute of arc of earth circumference = 1 nautical mile/6080ft/1852m.


As I think you were saying, MAC could be where handoff decisions are made but I differ in that handoff forced by location (traffic balancing is another issue) should be initiated by the ground terminal as it will, over time, map out obstructions to its field of view.


Placing this closer to the hardware should make hand off much smoother than loosing a DHCP lease. Ground unit requests a handoff. Sat finds a new sat to take the signal and transfers the 'lease' to the new sat while keeping its own copy running for x milliseconds. It also passes the new sat info to the ground unit which splits its beam to cover both sats, and checks in with the new sat. For that x milliseconds the ground station is hooked into two sat. It directs all traffic to the new sat and listens to the old sat only long enough to gather in any orphaned packets.


On the beacon, I agree, slam some power to it. I dared not tread here because of ignorance of what the FCC will allow. Also, as a simple beacon, operating in analog mode would probably work best but again, FCC ignorance along with no idea of how happy modern electronics would be doing this. Once they find each other they can go digital, tighten beams and swap info.


I left the ephemeris issue open because they do go stale over time and despite expectations that user terminals will fly off the shelves there's always the odd situation and there may someday be an inventory buildup. Probably only need to do a date check to decide to update or not.


So much seems to be hardware issues that don't really concern higher layers that I instinctively look to doing as much in hardware as possible. Being ignorant of the finer points of modern routing I can be well off base. Thanks for your patience in retrospect and in advance.
We are on the cusp of revolutionary access to space. One hallmark of a revolution is that there is a disjuncture through which projections do not work. The thread must be picked up anew and the tapestry of history woven with a fresh pattern.

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4394
  • Tampa, FL
  • Liked: 3313
  • Likes Given: 639
Re: Starlink : Networking Protocols Discussion
« Reply #59 on: 10/24/2020 10:35 pm »
RadicalModerate: Wuff! I actually understood a lot of that. Nice. My networking experience damped out with the tech bubble and my routing background... Well, let's just say it's lacking.


[size=78%]"You really mean the TCP/IP stack here, not OSI.[/size]"
TCP/IP is two layers of the OSI model, isn't it? You referenced some history I'm not familiar with. Terminology changes. Didn't mean to bring up painful memories.

The term "OSI" kinda means two things.  The more common usage these days refers to the seven-layer model, but back before TCP/IP conquered the universe, there was an actual ISO, and later CCITT, standard suite of protocols called OSI.  It was awful.   (Imagine an IETF meeting, but instead of just engineers, you had the engineers consulting the State Department on every technical point.  Now imagine the standards that came out of that body.)  ISO 8073 was the transport layer--the TCP-like protocol--in OSI.

The OSI model is way too complex.  For our purposes, all we need is a MAC layer (OSI layers 1 and 2, more-or-less), a network layer (OSI 3), and a transport layer (layer 4).  TCP and UDP are transports, IP is a network layer, and the MAC is the MAC.

Quote
The reason I was focusing on MAC is because so many of the issues are strictly hardware. The sat and the user terminal need to do beam forming and aiming. This profoundly different than a router deciding which of a few physical ports to use. ISTM that this could 'almost' be done in hardware with software supplying some tables. This would reduce internal management bandwidth.

You're right to be focusing on the MAC, because the MAC is what provides a canonical interface to the IP stack.  But that's exactly why you don't need a custom stack all the way up;  you just need a MAC that gets the job done.

Quote
Appending Lat/long To the MAC really isn't all that many bits, and it brings it to attention of MAC without intervention of a higher layer. Ground location precision need not be much greater than ~ 1/4 the sat beam diameter at the surface and shouldn't require all that many bits. At the equator, one minute of arc of earth circumference = 1 nautical mile/6080ft/1852m.

You don't need lat/long on every packet.  You just need it at registration time.  If the terminal is moving, it probably needs to periodically re-register.

Quote
As I think you were saying, MAC could be where handoff decisions are made but I differ in that handoff forced by location (traffic balancing is another issue) should be initiated by the ground terminal as it will, over time, map out obstructions to its field of view.

Fair point.  It's not uncommon to have either end initiate these kinds of handoffs.

Quote
Placing this closer to the hardware should make hand off much smoother than loosing a DHCP lease. Ground unit requests a handoff. Sat finds a new sat to take the signal and transfers the 'lease' to the new sat while keeping its own copy running for x milliseconds. It also passes the new sat info to the ground unit which splits its beam to cover both sats, and checks in with the new sat. For that x milliseconds the ground station is hooked into two sat. It directs all traffic to the new sat and listens to the old sat only long enough to gather in any orphaned packets.

My DHCP example was merely to illustrate that existing IP stacks are used to having to change over to a new router on command.  There's a way that the router can force an early lease expiration.

Quote
On the beacon, I agree, slam some power to it. I dared not tread here because of ignorance of what the FCC will allow. Also, as a simple beacon, operating in analog mode would probably work best but again, FCC ignorance along with no idea of how happy modern electronics would be doing this. Once they find each other they can go digital, tighten beams and swap info.

We know what power the FCC has licensed for the ground terminals.  Just use that.  The important point here is that the ground terminal knows where the birds are, because it has the ephemeris.

However, there is a load-balancing issue.  A bird may hear a registration and decide that another bird should take it;  in that case, it can just send an "I hear you, but keep looking" response to the registration, and the terminal will do just that.  How the birds decide when to load-balance is probably fairly complicated, but I'd expect it to be part of the process of assigning them to a specific region.  That's also likely a MAC-specific function.

Quote
I left the ephemeris issue open because they do go stale over time and despite expectations that user terminals will fly off the shelves there's always the odd situation and there may someday be an inventory buildup. Probably only need to do a date check to decide to update or not.

So much seems to be hardware issues that don't really concern higher layers that I instinctively look to doing as much in hardware as possible. Being ignorant of the finer points of modern routing I can be well off base. Thanks for your patience in retrospect and in advance.

I agree that stale ephemerides are a possibility, and that may easily require a terminal to do a fairly comprehensive "scan" of the sky to find a bird.  But that happens exactly once, because after that the registration process downloads a fresh ephemeris, and then periodically updates it.

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1