[Starlink] Hello

[Karl Auerbach]

Hi - I just joined this list, so I'll make my introduction here and then 
sit back and try to just listen for a while.

I have several points of view in all of this:

   - Curiosity

   - When I was at Sun (circa 1991-3) we worked with a Russian LEO 
system.  We ran into many of the issues I am reading about here, plus a 
few which are not being mentioned - such as solar blanking (this occurs 
in multiple forms, such as when the sun bounces off the earth, blinding 
the satellites I worked with or a sending satellite transits the face of 
the sun from the point of view of a ground station or receiving 
satellite) or atmospheric conditions (such as heavy rain/snow over a 
ground station.)  We also tried inter-satellite routing, but the 
complexity was beyond our capabilities at the time.  One lesson we 
learned was that due to power consumption issues on our satellites, we 
had to do shortest-hop routing (i.e. large hop counts) rather than 
longest-hop routing (lower hop counts.)  (As you can intuit, our 
satellites were somewhat like flying IP packet routers.  And because our 
constellation of satellites was merely a few hundred, we could 
pre-compute satellite-satellite and satellite-ground-station 
relationship in advance and retain our sanity.)

   - I have written massive amounts of bad code.  And my father and 
grandfather were, respectively, TV and radio repair guys.  So I'm really 
interested in building tools to help people diagnose and fix things.

   Our company is IWL (InterWorking Labs): https://iwl.com/ .  The tool 
I've been working on the most is an evolved version of Postel's 
"Flakeway", a man-in-the-path router that does things intentionally 
badly, or downright incorrectly.   I've moved it down to layer 2, so 
that it deals with Ethernet frames (with the ability to inspect/classify 
based on Ether, VLAN, MPLS,  IPv4/6, UDP/TCP, etc headers) and then 
subject those to various kinds of impairments such as delay, jitter, 
duplication, re-ordering, etc etc.  One can also dial in rate limiters 
and have some control over the algorithm used, the queue sizes, and the 
drop method (head drop, tail drop, some version of RED, etc - in other 
words you can dial in a bufferbloat scenario.)

   One of my interests here is whether I can build a tool that would be 
useful to people implementing code that is moving traffic over Starlink 
- I'd like to give people a way of sitting in the development labs and 
dialing-in various parameters so that they can tune their code to work 
well over a Starlink path without actually needing to have such a path.

   So I am very interested in the traffic characteristics that people 
will obtain when they use a Starlink path.  I'm interested in a lot more 
than that vague word "bandwidth".  Of course packet rates are 
interesting, but so are the loss rates, the delays, the variations in 
delay (jitter) and the way that those things onset and recede, in other 
words characterizations of burst behavior.

   And in these dynamic behaviors I'm interested in the fast-frequency 
stuff, such as variation in inter-packet/frame spacing, but also low 
frequency stuff, such as rain bursts or that solar blanking stuff that I 
mentioned.  And from what I've read here so far, I anticipate some 
"interesting" transient effects once Starlink enables 
satellite-to-satellite relaying.

I am a mathematical ning-ning.  About the only thing I know about 
queueing is that I can't spell it twice in the same way.

On the other hand, I've spent years upon years inside various kernels 
(including some vary strange ones built on long forgotten architectures, 
such as capability based machines.)

If you want to know more, my personal website is https://cavebear.com   
It has info about me, a lot of opinion pieces, my old CaveBear Catalog - 
https://www.cavebear.com/cb_catalog/ - "If we have it, you don't need 
it" (some people have actually tried to buy some of my products!)

And our company website is https://iwl.com

OK, now I'll go back into new-to-the-list-listen mode.  (But I will 
happily answer questions.)

     --karl--