From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A86BE3B2A4 for ; Sun, 14 May 2023 05:06:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1684055162; i=moeller0@gmx.de; bh=jkZK2jPxyx4CWIbbjI7PAi3lTFaNmufcpfWVK7dJ0Hg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Wyi0iR4f1dfdmmJoiMLzbiQJE3k4VTp2QfdCttzrvwEiximxD5CVCKIZJsIVJoDZ7 H6qmep3+woN7c70xUEe+DnYKhV2mary4hwN0waRjHIpB50AmSzWghpkeArgTVHCS7g tONtWYKwRvvVvtBGK5hln8J6n6Vz9mlFeuKnlMyBWeRgI9A7Z4/urk986O5KzHx7u7 fbbUh9yxL31tGJHoxTTBjkSz2N0eitvx2nsWMb8aoMlAIdVaosXASyXXkfmcehyHqA GQjBpDo8sbHDp6pHCiTWCL2q0fqrnFkeCNi/MCDY/FP8R+d0HzmdhCd6ktItFbv4p5 4+WzF40kNuHdw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.3.112.195]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MatVh-1qaDiL2RXn-00cRBx; Sun, 14 May 2023 11:06:02 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) From: Sebastian Moeller In-Reply-To: <077e6ad1-d7cc-2d57-39f8-e9646bea32a5@auckland.ac.nz> Date: Sun, 14 May 2023 11:06:00 +0200 Cc: David Lang , "starlink@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: References: <0no84q43-s4n6-45n8-50or-12o3rq104n99@ynat.uz> <48b00469-0dbb-54c4-bedb-3aecbf714a1a@auckland.ac.nz> <728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz> <077e6ad1-d7cc-2d57-39f8-e9646bea32a5@auckland.ac.nz> To: Ulrich Speidel X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Provags-ID: V03:K1:ENx7wiNbx+6FpsslGckq1xg68zgEAtYx452tiC276mZ2Jv4Xnn4 G8cv5IfbY4KgA1omcap14LPw/RGMaH8M3ANCx8+L83vmMG0CKIbN4YoVLQHdDX8EFMeU30g 3gPNFYMV9P/VFrP49+leMxwon5amQ0TEM51T9vJFyrMJ2EE9a9SX7NPqw56rkrwtNt+qp6H yX+Wxk4NqX2eCNdSclpJA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:INjx/FHGxiE=;Sjfru3M6mhECd9i8g4ML3y8VEHh 7ICippXKmUdTlYu9FHDXh+b6dT7AIVM9mv9A6FEG5qBgAmOO5mPyjwufS/tuTFIUl054NewVa +6HudytT09CgRN3iTp10brYxTDyA/7FQGDE8p/Fv6SDl0E5AcR46bwS6hjMI3W51JPUFHIz7J UGe/kFx/wsQHTguKzLJl84zzXYkfH7BlyxQZ8waGefsvr1wz6yXbgOdYtVF9JRCFDcBTY6Mxz lztkzWf6nNnuuFSklqGKFn8Ua5d69KJ8Or9MQ3+mqQQ5q4bCzVwVXAxr/Lo8iWWheROS/QjMf mTt4iu4Rz1G923BzCzfYPoKmMIeT8ByRn35z+3eUx7lkt0OLqkPEh0yO0QEOGwN3o1+SS2qPY hoCZMvwwN9/fPlvnENml416u1igV3CMjBYmnhshc9cV5eG7RST/uuwJ2ssvi32KOdT5/ZwW8d 3TvY0o2MvqepA7p/+jTD4e6rAeavSW45htpfNvewEnc8cxyY0UgzEUY2xfICJ1EfEuoa2+cAK 3dO129Y67SimwHhNEx/TOxjuu9dQWYcHaLw9P7WatjruRPvvQcmT8/CTcJFVnp2PPNG7ItBnZ Zep3jb+1mmZjZhQX2FdJv5bOJNB//dHHeu+LZSOTMFvJVcvrLu0mL6sNSNxk7mokQWZYDLj0j sjYpPfgVwPMuROBtr5rh/EFzeqboc/SWgQ2c0RvqoWMFy+uD8wdTl1mxzC+JR4kx/DiO9IWVr evXDwCSWvFY8vdLb7s5LzvlvRGHeCDR4vlpPcIO0UKrSgPIjLSVsMkFard3KTh4IVj9qn/7N7 pazusiMCOGST+8lmtvN7Y2NIK+GVQoil0CgcfgeLd0VcUZNAMF2HUwjtHn8NPA5RAvFBDePdf 8aW3XVyZ/ByMfkDfZXtFvWG3sJHfNb76m7Ha930/NZXDewVbBdrFfDIFwSH0d/Z5JI119BJuE httY5Q== Subject: Re: [Starlink] Starlink hidden buffers 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: Sun, 14 May 2023 09:06:12 -0000 Hi Ulrich, silly question, does starlink operate using fixed geographical cells and = are CPE/dishies assigned to a single cell? In which case handover would = not have to be so bad, the satellite leaving a cell is going to shed all = its load and is going to take over the previous satellite's load in the = cell it just starts serving. Assuming equal "air-conditions" the = modulation scheme should be similar. So wouldn't the biggest problem be = the actual switch-over time required for dishies to move from one = satellite to the next (and would this be in line with the reported = latency spikes every 15 seconds)? > On May 14, 2023, at 10:43, Ulrich Speidel via Starlink = wrote: >=20 > On 14/05/2023 6:55 pm, David Lang wrote: >>=20 >> I just discovered that someone is manufacturing an adapter so you no = longer have=20 >> to cut the cable >>=20 >> = https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0= BYJTHX4P >>=20 > I'll see whether I can get hold of one of these. Cutting a cable on a = university IT asset as an academic is not allowed here, except if it = doesn't meet electrical safety standards. [SM] There must be a way to get this accomplished with in = regulations if the test requiring this is somehow made part of the = experiment, no? (Maybe requires partnering with other faculties like = electrical engineering to get the necessary clout with the = administration?) > Alternatively, has anyone tried the standard Starlink Ethernet adapter = with a PoE injector instead of the WiFi box? The adapter above seems to = be like the Starlink one (which also inserts into the cable between = Dishy and router). >=20 >> > Put another way: If you have a protocol (TCP) that is designed to = reasonably=20 >> > expect that its current cwnd is OK to use for now is put into a = situation=20 >> > where there are relatively frequent, huge and lasting step changes = in=20 >> > available BDP within subsecond periods, are your underlying = assumptions still=20 >> > valid? >>=20 >> I think that with interference from other APs, WIFI suffers at least = as much=20 >> unpredictable changes to the available bandwidth. > Really? I'm thinking stuff like the sudden addition of packets from = potentially dozens of TCP flows with large cwnd's? =20 [SM] But would these really be added to an already existing = load? >>=20 >> > I suspect they're handing over whole cells, not individual users, = at a time. >>=20 >> I would guess the same (remember, in spite of them having launched = >4000=20 >> satellites, this is still the early days, with the network changing = as more are=20 >> launching) >>=20 >> We've seen that it seems that there is only one satellite serving any = cell at=20 >> one time. > But the reverse is almost certainly not true: Each satellite must = serve multiple cells. [SM] Which is not necessarily a problem if the half-pipe to the = base-station has enough capacity for all the per-cell traffic = aggregated? >> But remember that the system does know how much usage there is in the=20= >> cell before they do the handoff. It's unknown if they do anything = with that, or=20 >> if they are just relaying based on geography. We also don't know what = the=20 >> bandwidth to the ground stations is compared to the dishy. > Well, we do know for NZ, sort of, based on the licences Starlink has = here.=20 >>=20 >> And remember that for every cell that a satellite takes over, it's = also giving=20 >> away one cell at the same time. > Yes, except that some cells may have no users in them and some of them = have a lot (think of a satellite flying into range of California from = the Pacific, dropping over-the-water cells and acquiring land-based = ones). [SM] But the coming satellite should have pretty much the same = over-air capacity as the leaving satellite, no? Sure there can be some = modulation changes, but I would guess the changes would typically be = relatively small? >>=20 >> I'm not saying that the problem is trivial, but just that it's not = unique > What makes me suspicious here that it's not the usual bufferbloat = problem is this: With conventional bufferbloat and FIFOs, you'd expect = standing queues, right?=20 [SM] I thought it had been confirmed that starlink uses some = form of AQM so not a dumb FIFO? > With Starlink, we see the queues emptying relatively occasionally with = RTTs in the low 20 ms, and in some cases under 20 ms even. With large = ping packets (1500 bytes). >>=20 >> David Lang > --=20 > **************************************************************** > Dr. Ulrich Speidel >=20 > School of Computer Science >=20 > Room 303S.594 (City Campus) >=20 > The University of Auckland >=20 > u.speidel@auckland.ac.nz > =20 >=20 > http://www.cs.auckland.ac.nz/~ulrich/ >=20 > **************************************************************** >=20 >=20 >=20 >=20 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink