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 DC2E83B29D; Sat, 26 Aug 2023 08:34:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1693053282; x=1693658082; i=moeller0@gmx.de; bh=2+QssBM84uifZ+6YBy0IhlAV0pYhrMAyqETnz/xxN3w=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=n2CdHuaaiFQUls4dEpHq9Gi8ZXANTFmGWQW+vKUxESG1rVQW5Xkd4GZINjckEtf4U5RC2k3 JBZfsQwUN3SVfr1/aljEBZvFzNiQAHXja4xTuX7gGTsFmjl+kISbe1jbqg2vsBGAiPLbWYaa3 xoTtMubNnTU0FR0+AO5mbVbvxJzR5mn011WdYOl7nKSDveuyVXyh9NbOnOUq4srh//UBZZet5 3e1Ek6pQ59EIh8qgN56/Fi5nIIQuY8EDB6Mdp89MlhLNTFABCyCgSfxI43VDU0FvsltlpxQHI pZCTONzBZVuKkhgIZLYxvK+8hRmiX2WERCsqbkYxc6hEhfq6dUNQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.1.16.9]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MVNB1-1qAkxp3EgR-00SMyI; Sat, 26 Aug 2023 14:34:42 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Sebastian Moeller In-Reply-To: <66279D1A-5B4B-482E-91B2-86AFCFB6C20E@gmail.com> Date: Sat, 26 Aug 2023 14:34:42 +0200 Cc: ECN-Sane , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <2CDBEC1D-7CD8-4733-9232-7220505E2966@gmx.de> References: <553CF2FE-5A3C-4912-B367-4BF2C6A98D2A@gmx.de> <66279D1A-5B4B-482E-91B2-86AFCFB6C20E@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:cEIh2GY4XviIFpG9+hycY29VrZswIHi/5ysJFIYUwb9pCZ8dSnt 4s7dl4RQnJMdY9BRR661t6ATZLRPsYxLekjnODT/dSS2GRLkyN+387IelCOP4J/qSbWeS8P kpkOft4Bzr6D5dhhGqnJrJ1JFfdvFIp8QXHAcXk41rMnoaTP9NWCofQCDaO/4/Ow/z06Fgc qbDEvp2hzxX7M4LndDHEA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:1DlGENI1pS8=;PqNQVGtPIvEC9VDckvbelDNBDJp Z3dC+tX4YzO0VoUkSQYpJsKl3ety7KN49+sUfDa5MSKIwZB8ZU/r74qa6C+9cWxOb4tE9E+aE 0vb0x9iUpmBEWwisqMZcEAbJU4FW8KE7P0hZgfFADKXb0CTlvKtS+z5jxgwX3AXy3U3+WAewA 2Hf1ZgzcK5bIIahMWyqZ/7CvvuYm6h5JUnJsllx6MzNQULyskMYL1DxoS1TvwXOb3ZwqhNphx +lL2JUe8oggmnaEwD5xRDua/2cyKGAiqMANGmeNW+en7bwWek3/7ymBOzoXdFvgPyVF1ZhWpI CWE5f+U5PBu0G7awSzRQ5yjqhQq5suxH+PZJ+MkjnGts2JeYl16g8Pd5nymA5X5J52uDGhE2V x988zQZMmqbFvokn/5c/salgz7zErhJUe0MgSGPUR0f+zj6knub54w2PxK6zQB/gxn+GYZfs5 MsQoyMn5n6MQ7lrdn9IIRtwg2MfXlb1HkSGP7VlxilEP1KPo5fbqYxE9+lRCzLgdc+3XSP8ne mkjwpaXXrSX7uw+e+KWAN7IoycKyEI576ON03AVP8tgBjIBNthkRlmtVtAUtKYz75AZMT44Eo t+HgQ00PM6vt4Qm9SaupD3zbi8MfIlPuxY9lZ7BNFCXBe7TNu6+Cmw+qv+og9Sm5JUa3NrnYl VHLyjZ/Rh4S8l6ghy6JFGAGjv9jB8GRl93u7+mIK6sAg06HF46VqmCMbAcgzC+BHMTcvs3s9u TLCJKHlgX3sL/IWeEKobQq+K0pnzHrV41U7jsR8VZaW2EhlchHz2C6+98M5TRQOuletWGHGqE SZgn0xIUoOFg5syzBN5+lVUK8VdJqAjUXMWHQEC8Q5ag2YK7BaeusUyAOeltc7drhjnUd3QaD 0VeSrojVY6iyGbIld7W+tH2VVv+zaHjJ55IqEmpJXZH/DZzpyXqgB2zA3fCBEadBi0nu3cIJF 2jyYmg== Subject: Re: [Ecn-sane] quick question X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2023 12:34:45 -0000 Hi Jonathan, much appreciated!=20 > On Aug 26, 2023, at 14:06, Jonathan Morton = wrote: >=20 >> On 26 Aug, 2023, at 2:48 pm, Sebastian Moeller via Ecn-sane = wrote: >>=20 >> percentage of packets marked: 100 * (2346329 / 3259777) =3D 72% >>=20 >> This seems like too high a marking rate to me. I would naively expect = that a flow on getting a mark scale back by its cwin by 20-50% and then = slowly increaer it again, so I expect the actual marking rate to be = considerably below 50% per flow... >=20 >> My gut feeling is that these steam flows do not obey RFC3168 ECN (or = something wipes the CE marks my router sends upstream along the path)... = but without a good model what marking rate I should expect this is very = hand-wavy, so if anybody could help me out with an easy derivation of = the expected average marking rate I would be grateful. >=20 > Yeah, that's definitely too much marking. We've actually seen this = behaviour from Steam servers before, but they had fixed it at some = point. Perhaps they've unfixed it again. Hmm, I guess the next time around I will take a packet capture = and see whether I see ECE (expected) and especially CWR flags in these = streams... my side is a recent ubuntu (kernel from the 5.15 series I = believe) with sysctl configured to negotiate ECN... >=20 > My best guess is that they're running an old version of BBR with ECN = negotiation left on. BBRv1, at least, completely ignores ECE responses. = Fortunately BBR itself does a good job of congestion control in the FQ = environment which Cake provides, as you can tell by the fact that the = queues never get full enough to trigger heavy dropping. Yes, good point! Next time I see a big download I will take a packet = capture to look for additional markers of ECN activity... Sidenote, = BBRv1 ignoring ECN and not making sure to veto ECN negotiation really = seems like a sub-optimal coincidence... >=20 > The CUBIC RFC offers an answer to your question: >=20 > >=20 > Reading the table, for RTT of 100ms and throughput 100Mbps in a single = flow, a "loss rate" (equivalent to a marking rate) of about 1 per 7000 = packets is required. The formula can be rearranged to find a more = general answer. Thanks! Will look into this... Regards Sebastian >=20 > - Jonathan Morton