[LibreQoS] Network protocol abuse...

[Dave Taht]

This is pretty cool looking, karl. How fast can it go? (see also, libreqos.io)

---------- Forwarded message ---------
From: Karl Auerbach <karl at cavebear.com>
Date: Wed, Jun 9, 2021 at 3:38 PM
Subject: [Starlink] Hello
To: <starlink at lists.bufferbloat.net>


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--



_______________________________________________
Starlink mailing list
Starlink at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC