From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-h2p-567354.sys.comcast.net (resqmta-h2p-567354.sys.comcast.net [IPv6:2001:558:fd02:2446::5]) (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 A16CE3CB37 for ; Wed, 22 May 2024 09:18:58 -0400 (EDT) Received: from resomta-h2p-554994.sys.comcast.net ([96.102.179.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resqmta-h2p-567354.sys.comcast.net with ESMTPS id 9jjdsVZcaiHBi9lrsshpAF; Wed, 22 May 2024 13:18:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1716383936; bh=kG/HdZYAaetz920n8AbTIonyy7nE/i7bLT9Tk59hA3o=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type:Xfinity-Spam-Result; b=p8VolWZI4xnlJzR0Ri3MuLDn7OvFu5jb5lb52q7Tlx5qRSppqXQ05W/5oFvEKK36J HwsxfuAZl8n/LmsLHIWLv2I4WjQeK0IB2qyJjMrwCO9ok8VY6fImdZKBqBZ9VGuGXA BzMBpl0HIcW+MSjHXFBftrAjKQ8p4gMA2XaN5yCXDdfjBIlZcmnUdFJgP1NvFm1S3o CDLI92losZzBmJTR7iMrBuJy8KOfrOFiUoaEO4QqOwzS2Qajbpf57/gt71VWI7eWFH ZjTYpfFT3bb4J3gBsJ9spIE4KRZ0dQOGK8ukCYHGsGQ+DZ/gP1SiA+uKit14WhSaN1 LCEeB0L5AHaKw== Received: from home.sewingwitch.com ([IPv6:2600:1700:a64d:600f:2e0:81ff:feb5:9463]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-h2p-554994.sys.comcast.net with ESMTPSA id 9lpMsfo4i8D5o9lpTs8UVq; Wed, 22 May 2024 13:16:33 +0000 Received: from [10.96.7.39] ([10.96.7.39]) (authenticated bits=0) by home.sewingwitch.com (8.14.7/8.14.7) with ESMTP id 44MDGI78016112 for ; Wed, 22 May 2024 06:16:18 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 home.sewingwitch.com 44MDGI78016112 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sewingwitch.com; s=default; t=1716383779; bh=kG/HdZYAaetz920n8AbTIonyy7nE/i7bLT9Tk59hA3o=; h=Date:From:To:Subject:From; b=hI+M9rin4BuisZzihxvO01Xf7f7iTWO3iOD38iGtecnMKt8X/S29oa5e+fHm7R7ZV MYLWqz6bJGWT6Oh2ms9KGRT6wb0vy2UtLepd9ApVXEugD7frmL2wSsz51XYtGGjBaw qmjvDLw/Nj/Zq2HLuJ6lfH+tekwsR0yTij4QTDwA= Date: Wed, 22 May 2024 06:16:17 -0700 From: Kenneth Porter To: Bufferbloat Mailing List Message-ID: <4223FB1D3EC8265F9E30D997@[192.168.11.128]> X-Mailer: Mulberry/4.1.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1633 X-Scanned-By: MIMEDefang 3.4.1 on 10.96.0.132 X-CMAE-Envelope: MS4xfFfPhsiH1+Zvl5ywp6dvcSWD5VTIKIC2E1oWcM6rY6qYXhmt5aB6WDIllJo9uSDOJv9JY0h4DVoSjJ4pT3RLmu4vhrwTPaZFmIv/uZid4dRH4CYiFswK ZPnfpBEKOdGaWgnvIx4c3U0rXMadwYj4mt2OelS4sbCa8ghKswj3urMeK6eUX8lrPeEwudbWeKbuplWtwQaJEwRVTjbek8/jj1ddYpgzsA88RT1qTTLm27Rn o0z22xE4nw9g9yj4wqacdtez1wtQ20RoKi7L2CPucgE= Subject: [Bloat] A Transport Protocol's View of Starlink X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2024 13:18:58 -0000 This technical paper on Starlink by the chief scientist at APNIC crossed my feed this week. [I thought I'd share it to the Starlink list here but my application to join that list seems to have gotten stuck so I'll share it here for now.] >From the end of the paper: > While earlier TCP control protocols, such as Reno, have been observed to > perform poorly on Starlink connections, more recent TCP counterparts, > such as CUBIC, perform more efficiently. The major TCP feature that makes > these protocols viable in Starlink contexts is the use of Selective > Acknowledgement [11], that allows the TCP control algorithm to > distinguish between isolated packet loss and loss-inducing levels of > network congestion. > > TCP control protocols that attempt to detect the onset of network queue > formation can do so using end-to-end techniques by detecting changes in > end-to-end latency during intermittent periods of burst, such as BBR. > These protocols need to operate with a careful implementation of their > sensitivity to latency, as the highly unstable short-term latency seen on > Starlink connections, coupled with the 15-second coarse level latency > shifts have the potential to confuse the queue onset detection algorithm. > > It would be interesting to observe the behaviour of an ECN-aware TCP > protocol behaviour if ECN were to enabled on Starlink routing devices. > ECN has the potential to provide a clear signal to the endpoints about > the onset of network-level queue formation, as distinct from latency > variation.