From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp72.ord1d.emailsrvr.com (smtp72.ord1d.emailsrvr.com [184.106.54.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5B0163B29E for ; Wed, 9 Jun 2021 18:38:02 -0400 (EDT) X-Auth-ID: karl@auerbach.com Received: by smtp18.relay.ord1d.emailsrvr.com (Authenticated sender: karl-AT-auerbach.com) with ESMTPSA id B9FFBA016B for ; Wed, 9 Jun 2021 18:38:01 -0400 (EDT) To: starlink@lists.bufferbloat.net Reply-To: karl@cavebear.com From: Karl Auerbach Organization: IWL Message-ID: Date: Wed, 9 Jun 2021 15:38:01 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Classification-ID: e505e691-1af8-4762-9220-7214de9123eb-1-1 Subject: [Starlink] Hello X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 22:38:02 -0000 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--