From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9EF383B2A4 for ; Sat, 13 May 2023 19:00:44 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id D517B18E40F; Sat, 13 May 2023 16:00:43 -0700 (PDT) Date: Sat, 13 May 2023 16:00:43 -0700 (PDT) From: David Lang To: Ulrich Speidel cc: Sebastian Moeller , Ulrich Speidel via Starlink In-Reply-To: Message-ID: References: <13812EAA-BE80-47BA-A28F-637FA01A0ABB@gmx.de> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============2158522419348037814==" 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: Sat, 13 May 2023 23:00:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============2158522419348037814== Content-Type: text/plain; format=flowed; charset=US-ASCII On Sun, 14 May 2023, Ulrich Speidel via Starlink wrote: > I'd also imaging total user numbers to be lower and the > bandwidth demand per user to be less (hands up who takes their 50" TV onto > trains to watch Netflix in HD?). most phones are >HD resolution, and the higher end are >4k resolution. the network bandwidth doesn't care if the resulting screen is 5" or 50", the resolution is all that matters. > The other is that most places have 3+ networks serving the train line, which > brings down user numbers, or you have in-train cells, which communicate with > off-train POPs that have no extra users. but the density of people in a train car is MUCH higher than in an office, even if split a couple of ways. David Lang > But yes, good question IMHO! > > Cheers, > > Ulrich > > On 13/05/2023 11:20 pm, Sebastian Moeller wrote: >> Hi Ulrich, >> >> This situation is not completely different from say a train full of LTE/5G >> users moving through a set of cells with already established 'static' >> users, no? >> >> >> On 13 May 2023 12:10:17 CEST, Ulrich Speidel via Starlink >> wrote: >> >> Here's a bit of a question to you all. See what you make of it. >> I've been thinking a bit about the latencies we see in the >> Starlink network. This is why this list exist (right, Dave?). So >> what do we know? 1) We know that RTTs can be in the 100's of ms >> even in what appear to be bent-pipe scenarios where the physical >> one-way path should be well under 3000 km, with physical RTT under >> 20 ms. 2) We know from plenty of traceroutes that these RTTs >> accrue in the Starlink network, not between the Starlink handover >> point (POP) to the Internet. 3) We know that they aren't an >> artifact of the Starlink WiFi router (our traceroutes were done >> through their Ethernet adaptor, which bypasses the router), so >> they must be delays on the satellites or the teleports. 4) We know >> that processing delay isn't a huge factor because we also see RTTs >> well under 30 ms. 5) That leaves queuing delays. This issue has >> been known for a while now. Starlink have been innovating their >> heart out around pretty much everything here - and yet, this >> bufferbloat issue hasn't changed, despite Dave proposing what >> appears to be an easy fix compared to a lot of other things they >> have done. So what are we possibly missing here? Going back to >> first principles: The purpose of a buffer on a network device is >> to act as a shock absorber against sudden traffic bursts. If I >> want to size that buffer correctly, I need to know at the very >> least (paraphrasing queueing theory here) something about my >> packet arrival process. If I look at conventional routers, then >> that arrival process involves traffic generated by a user >> population that changes relatively slowly: WiFi users come and go. >> One at a time. Computers in a company get turned on and off and >> rebooted, but there are no instantaneous jumps in load - you don't >> suddenly have a hundred users in the middle of watching Netflix >> turning up that weren't there a second ago. Most of what we know >> about Internet traffic behaviour is based on this sort of network, >> and this is what we've designed our queuing systems around, right? >> Observation: Starlink potentially breaks that paradigm. Why? >> Imagine a satellite X handling N users that are located closely >> together in a fibre-less rural town watching a range of movies. >> Assume that N is relatively large. Say these users are currently >> handled through ground station teleport A some distance away to >> the west (bent pipe with switching or basic routing on the >> satellite). X is in view of both A and the N users, but with X >> being a LEO satellite, that bliss doesn't last. Say X is moving to >> the (south- or north-)east and out of A's range. Before connection >> is lost, the N users migrate simultaneously to a new satellite Y >> that has moved into view of both A and themselves. Y is doing so >> from the west and is also catering to whatever users it can see >> there, and let's suppose has been using A for a while already. The >> point is that the user load on X and Y from users other than our N >> friends could be quite different. E.g., one of them could be over >> the ocean with few users, the other over countryside with a lot of >> customers. The TCP stacks of our N friends are (hopefully) >> somewhat adapted to the congestion situation on X with their cwnds >> open to reasonable sizes, but they are now thrown onto a >> completely different congestion scenario on Y. Similarly, say that >> Y had less than N users before the handover. For existing users on >> Y, there is now a huge surge of competing traffic that wasn't >> there a second ago - surging far faster than we would expect this >> to happen in a conventional network because there is no slow start >> involved. This seems to explain the huge jumps you see on Starlink >> in TCP goodput over time. But could this be throwing a few >> spanners into the works in terms of queuing? Does it invalidate >> what we know about queues and queue management? Would surges like >> these justify larger buffers? >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > > --===============2158522419348037814== Content-Type: text/plain; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: <418r07pn-65so-795s-1854-64rp7pnoo54n@ynat.uz> Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU3Rhcmxpbmsg bWFpbGluZyBsaXN0ClN0YXJsaW5rQGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApodHRwczovL2xpc3Rz LmJ1ZmZlcmJsb2F0Lm5ldC9saXN0aW5mby9zdGFybGluawo= --===============2158522419348037814==--