From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6432F3B29E for ; Wed, 9 Jun 2021 17:18:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8646C38AD2; Wed, 9 Jun 2021 17:19:39 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Og0t4V4PqqcN; Wed, 9 Jun 2021 17:19:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 15F8E38AD0; Wed, 9 Jun 2021 17:19:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 45EFB486; Wed, 9 Jun 2021 17:18:50 -0400 (EDT) From: Michael Richardson To: Mike Puchol cc: Nathan Owens , Dave Taht , starlink@lists.bufferbloat.net In-Reply-To: References: <901ae36f-c5f1-4b0d-af17-90d29c212f78@Spark> <22686.1623247935@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Starlink] dynamically adjusting cake to starlink 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 21:18:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mike Puchol wrote: > 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=E2=80=99s coverage. This would seem to wind up overloading the downlink to the gateway, as well as causing hard to predict fluctuations in bandwidth. This is definitely a complex situation where I can see buffers being added looks like a good cure-all. Allowing for direct terminal to terminal traffic would ultimately help as many of the latency sensitive things like gaming and video calls are oft= en rather local. mcr> (Also, we talk about uplink/downlink from the point of view of the= the end mcr> user station. But, are there better terms from the satellite's poi= nt of mcr> 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 wi= ll > be reversed, with 25/75 DL/UL duty cycle. Yeah, so in order to speak usefully about some of this stuff, I think we ne= ed to distinguish between traffic going "up" which is going towards the Gatewa= y, from traffic which might be going "up" from the Gateway (or across from another satellite). Some additional terms would help. I had hoped that there were some :-) Do you know how traffic is being steered? I.e. how does the Gateway say which terminal traffic is to? All we know is that tweet "Simpler than IPv6" Some kind of SDN, but based upon what kind of discriminators? Are there circuits involved (ala ATM or PPPoE), tags like MPLS or 802.1Q? =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDBMDoACgkQgItw+93Q 3WVVRQf+KkHsVaeQkG15wbxcF/Hyp+FOGbmBLnYa974gkUN5zKPzUrcEbiz0ifwv aVCLKQdfk6YxLol9nM0HLhkdMuKfq7tkH5XnI2JQgIDmQ1hNKDjNAj6q7ORIbCTG 8fE3iaHhg01J3lmo9pJxjRBHFdc7znWMZRpxj3W0WzTccy3aZmoGuyaXHgWLoA2f uWVoqAij53Wv99g3HN7gllkTib9VANOh5H3vCNovwPabIqFBWaEMd6pZ4pM7dJOy VXfcuGE83/RoXzu+z5N5q3rf9lInRx/FyPMpZIzfItvrAENqL6tLQSYAfvQFilP/ UMrBHmfsVpNqOytRLhnt7TTcG963tw== =Y34J -----END PGP SIGNATURE----- --=-=-=--