<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto">We really don’t have a lot of information as to how traffic is encapsulated and switched/routed from POP to gateway to satellite to terminal. I believe there is no need for anyone to reinvent the wheel when there are existing protocols that can be used for this sort of thing. <br />
<br />
I’m placing my bets on cellular networks, where the concept of LTE UE Context matches quite a few things Starlink would be required to do, such as dynamically change allocation of radio resources, and mapping a subscriber to a physical cell and logical channel structure.<br />
<br />
There is not a lot Starlink can do to predict network traffic, they can only hope that as the subscriber base grows, the peaks will “even out”, as we see in our networks. Here are some 8,000 CPEs at 4Mbps rate limit:<br />
<br />
<img style="max-width:100%;height:auto" src="cid:C000DAB3E0564BDDA06ACD7335F9DA1D" /><br />
<br />
Traffic shifts, other than due to a dramatic events (a whole area losing power), are in the 1-5% region. In contrast, this is 220 CPEs at the same 4Mbps rate limit, where the shifts are in the 20-35% range:<br />
<br />
<br />
<img style="max-width:100%;height:auto" src="cid:2A822C3E5C0D4641B708CDFCCF6CE91C" /><br />
Thus, Starlink needs to place more efforts into predicting spot beam traffic patterns than, for example, gateway to POP.</div>
</div>
<div name="messageReplySection">On Jun 9, 2021, 23:37 +0200, Nathan Owens <nathan@nathan.io>, wrote:<br />
<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">
<div dir="ltr">
<div>> This would seem to wind up overloading the downlink to the gateway, as well<br />
as causing hard to predict fluctuations in bandwidth. This is definitely a<br />
complex situation where I can see buffers being added looks like a good<br />
cure-all.</div>
<div><br /></div>
<div>We'll find out soon enough... Polar launches start in July.<br /></div>
<div><br /></div>
<div>> Do you know how traffic is being steered? I.e. how does the Gateway say</div>
which terminal traffic is to? All we know is that tweet "Simpler than IPv6"<br />
Some kind of SDN, but based upon what kind of discriminators?<br />
Are there circuits involved (ala ATM or PPPoE), tags like MPLS or 802.1Q?
<div class="gmail-yj6qo gmail-ajU">
<div id="gmail-:1a7" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" /><br /></div>
<div id="gmail-:1a7" class="gmail-ajR" tabindex="0">My intuition would be that traffic is encap'd when it enters a PoP based on the destination IP, and the state of the constellation. The encapsulation could just be MPLS with a segment routing-like approach, it would contain the desired gateway, satellite, and terminal ID.<br /></div>
</div>
</div>
<br />
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jun 9, 2021 at 2:18 PM Michael Richardson <<a href="mailto:mcr@sandelman.ca">mcr@sandelman.ca</a>> wrote:<br /></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br />
Mike Puchol <<a href="mailto:mike@starlink.sx" target="_blank">mike@starlink.sx</a>> wrote:<br />
> This is correct, with a few twists once you throw in inter-satellite<br />
> links. In future satellite versions, optical<br />
> links will allow satellites within the same orbital plane to use each<br />
> other as relays, thus providing coverage in areas not within a<br />
> gateway’s coverage.<br />
<br />
This would seem to wind up overloading the downlink to the gateway, as well<br />
as causing hard to predict fluctuations in bandwidth. This is definitely a<br />
complex situation where I can see buffers being added looks like a good<br />
cure-all.<br />
<br />
Allowing for direct terminal to terminal traffic would ultimately help<br />
as many of the latency sensitive things like gaming and video calls are often<br />
rather local.<br />
<br />
mcr> (Also, we talk about uplink/downlink from the point of view of the the end<br />
mcr> user station. But, are there better terms from the satellite's point of<br />
mcr> view to distinguish traffic to/from the end user?)<br />
<br />
> In general, downlink is anything from satellite to ground, be it<br />
> satellite -> gateway or satellite -> terminal, and uplink the reverse<br />
> path. These are the clearest terms to use IMHO. Thus, if satellite to<br />
> terminal has 75/25 DL/UL duty cycle, the satellite to gateway link will<br />
> be reversed, with 25/75 DL/UL duty cycle.<br />
<br />
Yeah, so in order to speak usefully about some of this stuff, I think we need<br />
to distinguish between traffic going "up" which is going towards the Gateway,<br />
from traffic which might be going "up" from the Gateway (or across from<br />
another satellite). Some additional terms would help. I had hoped that<br />
there were some :-)<br />
<br />
Do you know how traffic is being steered? I.e. how does the Gateway say<br />
which terminal traffic is to? All we know is that tweet "Simpler than IPv6"<br />
Some kind of SDN, but based upon what kind of discriminators?<br />
Are there circuits involved (ala ATM or PPPoE), tags like MPLS or 802.1Q?<br />
<br />
--<br />
] Never tell me the odds! | ipv6 mesh networks [<br />
] Michael Richardson, Sandelman Software Works | IoT architect [<br />
] <a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a> <a href="http://www.sandelman.ca/" rel="noreferrer" target="_blank">http://www.sandelman.ca/</a> | ruby on rails [<br />
<br /></blockquote>
</div>
</blockquote>
</div>
</body>
</html>