Quote from: TheRadicalModerate on 09/27/2020 08:08 pmQuote from: vsatman on 09/27/2020 07:52 pmQuote from: sdsds on 09/23/2020 07:43 ama.- never touch the ground except at our two homes, i.e. go home1 -> sat -> home2b.- always go through a Starlink ground gateway i.e. go home1 -> sat -> gateway -> sat -> home2c.- 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
Quote from: vsatman on 09/27/2020 07:52 pmQuote from: sdsds on 09/23/2020 07:43 ama.- never touch the ground except at our two homes, i.e. go home1 -> sat -> home2b.- always go through a Starlink ground gateway i.e. go home1 -> sat -> gateway -> sat -> home2c.- 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.
Quote from: sdsds on 09/23/2020 07:43 ama.- never touch the ground except at our two homes, i.e. go home1 -> sat -> home2b.- always go through a Starlink ground gateway i.e. go home1 -> sat -> gateway -> sat -> home2c.- 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
a.- never touch the ground except at our two homes, i.e. go home1 -> sat -> home2b.- always go through a Starlink ground gateway i.e. go home1 -> sat -> gateway -> sat -> home2c.- some mix of a and b?
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.
Quote from: TheRadicalModerate on 10/03/2020 05:59 amTell 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) GEO2) 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?
Quote from: TheRadicalModerate on 10/03/2020 10:06 pmOK. 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.
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!"
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.
Quote from: TheRadicalModerate on 10/06/2020 05:44 amMy 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?)
Quote from: vsatman on 10/07/2020 06:51 pmQuote from: TheRadicalModerate on 10/06/2020 05:44 amMy 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.
Quote from: DigitalMan on 10/07/2020 11:12 pmAlso, 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.
Quote from: watermod on 10/08/2020 10:15 amQuote from: DigitalMan on 10/07/2020 11:12 pmAlso, 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.
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.
Quote from: TheRadicalModerate on 10/22/2020 11:29 pmQuote from: gongora on 10/22/2020 09:19 pmThere 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.
Quote from: gongora on 10/22/2020 09:19 pmThere 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.
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.
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.
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.
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.
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.