[Starlink] dynamically adjusting cake to starlink

[Mike Puchol]

Hi Michael, inline below:
On Jun 9, 2021, 16:12 +0200, Michael Richardson <mcr at sandelman.ca>, wrote:
>
> welcome! So happy to have you.
>
> Mike Puchol <mike at starlink.sx> wrote:
> > As for the topic at hand, I understand the concept - in essence, if we
> > can find what the Dishy - satellite - gateway triumvirate is doing in
> > terms of capacity and buffering, we can apply that information into our
> > own router’s buffer/queue strategy. I have taken a quick look at the
> > document, and there is one assumption that is wrong, AFAIK, which is
> > that the satellites are “bent pipes” - they actually process packets,
> > which means they are an active component of buffering and queuing in
> > the path (for optical links to work, satellites would necessarily have
> > to process packets).
>
> So, when we say "bent pipe", we don't mean that literally. (I know that it
> was literally true at some point). We don't mean to imply that the satellite
> does not reconstruct the binary content of the packet from the baud's of
> symbols.

Understood - however “bent pipe” has some implications from traditional GSO terminology. Modern satellites reconstruct the binary stream, but still act as a “bent pipe” in the traditional sense.
>
> What we primarily mean is that stuff goes in one side *ALL* comes out the
> other side, and that the satellite does not *at this time*, make nexthop
> decisions based upon (IP) packet content. Of course there are some kind of
> identifier to tell the satellite what end-user station to send data to in the
> direction towards the user.

This is correct, with a few twists once you throw in inter-satellite links. In future satellite versions, optical links will allow satellites within the same orbital plane to use each other as relays, thus providing coverage in areas not within a gateway’s coverage. This is particularly relevant in high latitudes where fiber is scarce, so the polar orbits are getting optical links first. Take the scenario where each satellite has its own gateway, the uplinks and downlinks are balanced. Now, assume the case where a satellite does not have a gateway in range, but has another satellite in range which does have a gateway link (A):


Suddenly, satellite A needs to handle the traffic from its own cells, plus the cells served by satellite B. This can go on, with multiple satellites being relayed by a single satellite - there will be limits, of course, as the Ka band gateway links do not have infinite capacity. If you take a look at my tracker, the velocity of the satellite calls for extremely frequent topology changes - Starlink has indicataed they re-calculate every 15 seconds.

Whatever mechanism Starlink uses to route traffic internally it is certainly more advanced than a modern “bent pipe” regenerative (or I have totally overestimated the capabilities!), and involves a level of packet or frame handling higher up the stack.
> (Also, we talk about uplink/downlink from the point of view of the the end
> user station. But, are there better terms from the satellite's point of
> view to distinguish traffic to/from the end user?)

In general, downlink is anything from satellite to ground, be it satellite -> gateway or satellite -> terminal, and uplink the reverse path. These are the clearest terms to use IMHO. Thus, if satellite to terminal has 75/25 DL/UL duty cycle, the satellite to gateway link will be reversed, with 25/75 DL/UL duty cycle.
> It is my understanding that at some point, traffic between (end-user)
> stations will be possible via multiple satellite hops, and without a trip to
> the ground to a routing decision. But that isn't happening right now.

That isn’t happening, but you don’t want to design a system that needs a massive upgrade further down the line once you put optical inter-satellite links into operation. It’s much easier to design, implement and use the mechanism from the get go, as it simplifies other things (traffic delivery from gateways to a specific POP via user context, for example).

Best,

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20210609/42cc14a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Starlink beam arrangements-2.png
Type: image/png
Size: 39962 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20210609/42cc14a5/attachment.png>