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 55B603CB37 for ; Wed, 22 May 2024 12:04:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1716393848; x=1716998648; i=moeller0@gmx.de; bh=FBN58JNl0y7u7dVTK3tnE7EJoZagbDVdls2MPzt9Z28=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=E5H89vtiJHf7h5HlNn1fHakZss//Ocezddr+x+i/EsMVEYXzCpB2QlfoPcWOuuKE Aj5ttykQJaVNxgQ3vQy5T6angUO0AVNjjWZDR2i9yQr7Y8cxLmoUNyKuALTmG0jT0 FO8kMu9X13Y0w72VeYd44wiaMNg0NpHjH30orrVFfBaRTrECWxmOwwpXBsbpe527o HtD9/6W1ZinPQEuKkWxl6EQCuRLDcCiGIHsB9D4To9Mfw5ovIdVeFBla5N5KpIIk0 iEQvFO3wDbKmIQg+PKcaJ+vzhfWhgOoDkvpfzxOlGfkhOseL7H2bK6p+7SDu6imac dcJlWfhHTJUrBFx3mg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.3.136.124]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mn2aD-1sqbF91tv5-00lHic; Wed, 22 May 2024 18:04:08 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) From: Sebastian Moeller In-Reply-To: <20240522085927.32b82e93@hermes.local> Date: Wed, 22 May 2024 18:03:57 +0200 Cc: Kenneth Porter via Bloat , Kenneth Porter Content-Transfer-Encoding: quoted-printable Message-Id: <976DC9DC-532A-4C26-8319-8642CDBF8F92@gmx.de> References: <4223FB1D3EC8265F9E30D997@[192.168.11.128]> <20240522085927.32b82e93@hermes.local> To: Stephen Hemminger X-Mailer: Apple Mail (2.3774.600.62) X-Provags-ID: V03:K1:YtoLlt+XR64r8Dyt4qxIVcYkAjI9LkvA7j+IUfL+K8SroWi5nmB 4rTTO+ipSeZ0CcEu8w3egmTP7IUN1/o10kSfRSy62p5vaetoPLN01NAdWiYXEWPA2PVRGht 9pVXp9+Owaqw9XRYlYp6OaSxCM+d0jOOX9jmlLyv/vo2Awib+AN9z2vHF6yAzpjzhng/HqA FGmam7fdY6pXPO6fezyFQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:1EPOMzHMXso=;8K5uTxHeS7ISvFxeit+V3bS2QpE ohJvN+QOhnuqERU1JCAdJrCGXFzF3p5R6jSGnYnShmA4wLTyuT0xK9t3oYngzXQSzkOY3e0Zf asrdhf+zdYQKieyfdFXB1MI1GxOiXtJxfEbt0tzS95smE4Jnty7Mx0HIS4QTifPJMRk/56Dbz paSJkRg+xJPupy3B1nEPi6RwW4JGul9Diq0Q6RSfuoDZU1Y+GR01xIC+uhgrD21x718Ixj9oM LADhmzk40MD+3WVFMVD/DBwZ5XUkz1U0JOo+aN3KetaT9tBmX+1Jn7gMvNxhbqQRcxIZS3WX9 IH9RTHUiQ+fJThKfir+XmkbindHTKsyNBZRccuGZjZ8HL0N8gprqx5e50ohYa/7HRni/nf0sj vHFZKK/BEt2VQhVrEZ1P/h/L237IrdEP3VjAcm+gBxMOyhmRROGBC1riJm+BUzMXYR8OMhi7f P2XrymWYduQV635j/UZz/bqhiFGAvva3qol+AQcYYJs41arm830eQRE72w0umhd5Q1lxuL8oK 4PDsg/ZbrVaTY9eDWaekk3wB3FZIptTjo1mtoMKSSUFshhcXOv5VuXduac9D0xe7plIltEQzu VE1xR13PqkqS95Pm7V1b35snkCCbeoaH9PLfU7LP9FaPMyscneqN57zDyFDVp6T+GmA9QHn+V GAjW8G40IZUuYPHLRXfS4XS/ZMnTMs0xRC7LHI8HMm5sQQD4IkCjHrm6b0LFJAVkvmxTJKbLa 08OXzhd9GrCXntINujA4bOde+eU7fBQnneuYSCnDSIFeLfy+N7acQpaqJguzmGqGAHDldaabX 4tJiEk+hs01IZfl6S541AXM7lA1688qw1HKiR23SA853Q= Subject: Re: [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 16:04:15 -0000 > On 22. May 2024, at 17:59, Stephen Hemminger via Bloat = wrote: >=20 > On Wed, 22 May 2024 06:16:17 -0700 > Kenneth Porter via Bloat wrote: >=20 >> This technical paper on Starlink by the chief scientist at APNIC = crossed my=20 >> feed this week. [I thought I'd share it to the Starlink list here but = my=20 >> application to join that list seems to have gotten stuck so I'll = share it=20 >> here for now.] >>=20 >> >>=20 >>> =46rom the end of the paper: =20 >>=20 >>> 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. >>>=20 >>> 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. [SM] Is that actually what BBR does? I believe BBR cyclically reduces = its sending rate to measure the minRTT but during its bandwidth probes = (or intermittent periods of bursts), it actually measures the rate via = the ACK feedback and not the increased queueing delay? >>> 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. >>>=20 >>> 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. =20 >=20 > It frustrates me that all research still looks primarily at Reno, = rather > than the congestion controls that are actually implemented in Linux = and Windows > which are used predominately on the Internet. > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat