From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 E7ACF3B2A4 for ; Sun, 2 Feb 2025 06:40:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1738496397; x=1739101197; i=moeller0@gmx.de; bh=PjPlIXor06Lrbws137xFV4/z7tSlMyljuS2D+NEq7bw=; 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=iQCOCqHoyrQSg5DObDmjdTIhbM+6imSRB7aG/dBHYQgIFp/Iag0L57xUh3j2w4Ha YCfs8L5jLnR3yttx1wMwM9On94efyknZ8hrNypCctfz/QOXCUvTl/3LlyHSZ2G3zG KxF6OPLVACy5vylp5SeV7c1EQt+2R9Ks/nWEAv7m5DWhHpngqPO4BD07pgZeh3p4n srXA9MSzBEVz5gGDlWNPVRDWjS5v05vzihebOZ+Bn+huEOwrLrRq36X93/TdCDm2F 4SHKOsmv4rjtadLheKwdgylajEEGJwWgEfgnHfZ4E3S35YaiBGYLVMeQZ2/pPs5S7 GcRDQoQMQy2rgNB4pA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.112.17.185]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N4z6q-1tUlDd2MRI-00wMB0; Sun, 02 Feb 2025 12:39:57 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\)) From: Sebastian Moeller In-Reply-To: <0492E50C-BB28-455D-9E4A-B6272EA7F6AD@gmail.com> Date: Sun, 2 Feb 2025 12:39:46 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , David Collier-Brown , Rich Brown via Bloat Content-Transfer-Encoding: quoted-printable Message-Id: <93E5FE09-C0C6-4912-B51B-07F4F8479F83@gmx.de> References: <48F77C27-0E57-4F96-9BD8-238CC93342F8@gmail.com> <9A110AF4-E976-4228-9FA6-92C5C99F611A@gmx.de> <48FB68A5-8320-4B46-97E1-4C67BB7B7B1B@gmx.de> <4B1379B8-7EF6-4D34-8091-451A48585811@gmail.com> <0492E50C-BB28-455D-9E4A-B6272EA7F6AD@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Provags-ID: V03:K1:y+ozZ4gct33Ia1+lNpledkit5p/1+gKrlE9/XxR5/Sj+rgyGkv4 DVpyTEEuRXe58hRhWpSNxB69/rwOUz7KmUfPvQzyk/0xsje9p/cC+NT1cxF8IRpjzWUO4Gj vlCs0mI8YsO7rF7YZUSraZDjFUVAsi7iOKvzXiW5429Hqbxv+7nYLNtWqXkuz8ycOPcES80 MqLRngrLoNBmkxC+oqCvA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:a8vEJVt3h8Y=;RuySYhw7GjfRuy2cUB+60BIjQ3o P3CXuo2F2FydBU2APUHxcxSvmSPDrO08wxPc0+eJmv7ES/REYn9OPeYYUKGbf2sgFWetrVCrw xAmpvbyM6Sjxy6z7PkDz02rcxPwjcr0SOgQhIqu1MZSrdOuDFBa+ATExyeWwMMWAHbLqyHTCI jLvbtKbZyR2MHxbHQUY1TIDEg6CGEhRrnNUyGfDzuHREsarn8FYXqW8uo8ycve48ppC2BGF8O 3PBvchtPVNGujmRu0SutH3DTLvL/0w55KSaEDTaGBwTDQWNLl2K6RlEdQEuNNs7e+6nwhOklR duh/nMW50uPaeVIJ+fvhY/JBzhT1n8YBw4ec2VihuHl5ExhnnZdsBsZrjk/seBMoXzgwpAoX8 4uZEoPDWpJ+atBqML7MSPU9UVL0AFFCZlWJLtI6BF4IUKEPkE/EU/7VqKOiXf9sfXPzPJCv2z 16qLqXdZrp+00ejTaaUbFWU8jETDNZTToheokwvyr/tv7gZ9n4KtCHMVI6BvE266OfsPwsVL4 E5v5cfbwMDIJZgcfLhFcSdEq9i4OKvByIq7hEM1Xbwax+KL70c7/LgyLCn8sy8S58/OtwjRhA fFoW0k6lMvQ1aRBq1xcFZ76UgkWs5LoY/l2akiMe4e/f01H6zYqCbPDuMMa1FPuOxa0/vdPuL TYlOurJExR9xjRmWCzlOq+2FYGVSrhb5xltCD1LGrijnXTfSckSSXZInIsooenbLP/qsD+HGM xMFkeq4rNbkMh/CSdcyLXW0oep7NTda3zOCGpieWld1ec8hvixVWDEuxamA4lxjM6/NVL9pA0 eBOiMUQsZirEXJSbFiFsZJ6fsecY/gYvvbtK263HnzuHrn7TUA3pJuY8WcaGftYWBsy7xPPuw TsyICjYXxisoyMGsPr9wawLPgkBZNlBPLIOj6hBQhlCYrZT4RXOrKdOSdXD86cM/zJXIrlVfm dQBGIsDB1/Uoe8WJkkqKXi8Hjwpl5UMOl3UCwXe3cvi74zUCsxNuqOztkHwrlwj5weApfZM/C bwKPHSe+O84dicuHxyQ/JMWGiJSikaFZRxSQZr52kYg0LuiD0FAK/atI/AamwjUyLAsmqJ4q5 JmVrzzH5944XCdf6OjaN/cw5y4x6Ka4LwAJq/TG5GB1geFwzbCHAa/tvwYbNKzvo4LtrhScb2 eOFZkuvrAE867PYVVnAqULpr+v2Zuqw1hi/L1hFL2ByAw+gAgRa7U0E1JLhaRgzrfhcllb24V luqJwxI9oar93Eq175cylL8DiOeRjIC1THJZpmkCjimsSvOGu7fQnj31hV+C1gphGBcRIrZOy HMvrvFgGnPh986HVAo6gSapX1O4UbvdiNAHtqCPuXqe4DY= Subject: Re: [Bloat] Comcast & L4S 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: Sun, 02 Feb 2025 11:40:01 -0000 Hi Jonathan, thanks for the graphs... > On 2. Feb 2025, at 01:09, Jonathan Morton = wrote: >=20 >> On 1 Feb, 2025, at 8:05 pm, Sebastian Moeller = wrote: >>=20 >>> about as tight as you can reasonably make it while still = accommodating typical levels of link-level jitter. =20 >>=20 >> Not sure, in a LAN with proper back pressure I would guess lower than = 5ms to be achievable. This does not need to go crazy low, so 1 ms would = likely do well, with an interval of 10ms... or if 5 ms is truly a sweet = spot, maybe decouple interval and target so these can be configured = independently (in spite of the theory that recommends target to be 5-10% = of interval). >=20 > Actually, the 5ms target is already too tight for efficient TCP = operation on typical Internet paths - unless there is significant = statistical multiplexing on the bottleneck link, which is rarely the = case in a domestic context. =20 I respectfully disagree, even at 1 Gbps we only go down to 85% = utilisation with a single flow I assume. That is a trade-off I am happy = to make... > Short RTTs on a LAN allow for achieving full throughput with the queue = held this small, but remember that the concept of "LAN" also includes = WiFi links whose median latency is orders of magnitude greater than that = of switched Ethernet. That's why I don't want to encourage going below = 5ms too much. Not wanting top be contrarian, but here I believe fixing WiFi is the = better path forward. > DelTiC actually reverts to the 25ms queue target that has historically = been typical for AQMs targeting conventional TCP. Not doubting one bit that 25ms makes a ton of sense for DelTic, but = where do these historical 25ms come from and how was this number = selected? > It adopts 5ms only for SCE marking. This configuration works very = well in testing so far: >=20 > > As for CPU efficiency, that is indeed something to keep in mind. The = scheduling logic in Cake got very complex in the end, and there are = undoubtedly ways to avoid that with a fresh design. Ah, that was not my main focus here, with 1600 Gbps ethernet already in = the horizon, I assume a shaper running out of CPU is not really = avoidable, I am more interested in that shaper having a graceful = latency-conserving failure mode when running out of timely CPU access. = Making scheduling more efficient is something that I am fully behind, = but I consider these two mostly orthogonal issues. >=20 > - Jonathan Morton >=20