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 587B93B29E for ; Fri, 19 Mar 2021 10:24:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1616163887; bh=NaRbDXrSADQLhZ8fbfJYpwhLlm8yaGDnsB2Wv05tFpA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=HZX0mP8qSB4bWcKRY4CM4e/HsnDPfsYBPc9SVg014qD/VpZv0h8LDr1w9XJ5U0LzP qKz+7SpyF19UfJP/U4OjFQXHnYv6IC2fzIPpNNiolXFK3ZRZ7UVPm0RCnJyD76XhJM AXr/q/4PCVxrBKUwsuQd88ExzJIjNHQDYTDe8c1g= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.250.106] ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MGQnP-1lSzD81pMb-00GoZ3; Fri, 19 Mar 2021 15:24:47 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Sebastian Moeller In-Reply-To: <73737060a1d857675ad5f44a17ddb30b342da5ba.camel@heistp.net> Date: Fri, 19 Mar 2021 15:24:46 +0100 Cc: ECN-Sane Content-Transfer-Encoding: quoted-printable Message-Id: <275D5675-18EB-46F1-9B3F-427681B089CF@gmx.de> References: <42F85394-FF4B-48BF-89B1-082D97CFA76C@gmx.de> <73737060a1d857675ad5f44a17ddb30b342da5ba.camel@heistp.net> To: Pete Heist X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:I8Wd8W/oVKFGaOpgh5c3NfG/IxH2Dg3j414dNJkuvNyhaQg3bpt mo0/3f1HMdNjGzdADRvg3CFOsqXggDOej9y3uICnGsPVZnyoau8ck9HsMLFG0t3SGcg54fT y4KqJeklr4XDyM0K1DCaqZEpxUAceInOiIjVhztuJQAsL8//j9Epl6VJw8vTlcvsuHewdu5 T5zv30lCwp9dTxYa/appw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:qGwCGvyE16I=:kZal81d8NuPZM7/6gBWlG5 2u2nj2OgJLyB5AcKi8djukoy0R0P2iNSr320Z3pyOIIVrZzMO70z+bhPbBNdzcM8+hqJB+ow9 b8md2bFSTIAGprCm8kNZsm86SM4QN3EnpZVjsdS5C/N5V8JbxyLx+fQEyn0We4ZT58Caxq6QY i41ChK0grK8+QoxY9dh4fdMZ1k48Mqek7/aBv3q2QCcfhrkekIvUYRQHVaVSGQB2/PBGudfgg OTo8AgFxoHbVBDpwhwaRvnJP/Op96YoLmMuRz0EDoNuBlX/7RbvTNtnfDJnoHol1Z6p8oXT+n xfI9B8kFn7wZTBcKR+qOIQOCN5wto2N8H3TwH5kgQ2fK/1h5rYvab1eLZlmuzfQTO2OCWxmrb EC9bWrvcbWzGBen7uy41AmbBOLSPU+2wJP8xNmbSXeJkixUpMrS82Vb2lduk/Pzh3uPPuzcoC aRdrgtye9CW7mMXj6UKqBnHrqjqM+JM0xuFtbJpC6GMEO62ZoqfkKiaDVZ9pfakcvbHVSxtxf cyGtdqsiIkfXHO7exb8K5aolhiqy4jXtxb9yfkioLYcIoaG6IsPbcA3atpjPiC67TAPp7gzg4 uVN1QsgFkeeXe3X27pLT9g7djmQEUVujXgPEENGpLD++68rQbE4zt6TF0PHFACFKan5ASfCG3 ho/LF7K8XZ9X+V2OzN43wy01sIg8eLxBSLlPD3IUBpzjjN5DKw9qEL1BhdKF/jhSYJ7G0kyXo sybAVUVbE+P/fid09xwPOGCltILP5koBqOd/4Ypz1DAlFZkEX96JikitewwxrnqfZHTQRQE7K /ySHO0RFltdj5J7d4KxIH1Y/v3xIh03aVUIvW7CpWTAE3gKU3zqCZ411XiwBMetaYyeOuORO/ WKcZITOrquH/CfFEmsg72zXcTlwpZvwigtf6q5kArlQ+utY6yxqjRsuk9j2tdIYplwfkYeDU9 PJp2xN0EOYjPyh2I0tbW95WB/fALLL1dz98MBgmowhMz3P09cQqjwUclZWSzxjTbQyFFK/xms 4DtGEwFMKQqn3AhMhlhAWFyYmVli0q5RegdhZuRntISO40anPxu5Dt7KLtHfFpS009y/mFBAY 2Nc+ZR73idkEjsjWageLdCRkFNXcLc54bmqKsz8gQwUhqn2euJWTwhYGEvL8/xe2QdjJ/IPuT JndNH5v3hlZQPWO/36AC5cdz6fITlIvVa66f/t9hkbblYlid0+LzJkkc3uwTl1mYEF/Q8= Subject: Re: [Ecn-sane] re-marking ECT(1) to ECT(0) (was: mosh ecn bits washed out) 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: Fri, 19 Mar 2021 14:24:49 -0000 Hi Pete, if I were to design a high priority lane cutting through all the clutter = of other's flows in the LL-queue, I would create a tunnel that asserts = ECT(1) but does not react to CEs and simply would employ some FEC to = deal with the expected packetloss more gracefully (to take over the = queue it should sufficie to suffer less from packet loss than the rest).=20= Et voila, L4S should effectively ceed the LL-queues 15/16th = capacity to my data, mwuahaha... Best Regards Sebastian > On Mar 19, 2021, at 10:18, Pete Heist wrote: >=20 > ... >=20 > On Fri, 2021-03-19 at 09:56 +0100, Sebastian Moeller wrote: >> Hi Pete, >>=20 >>> On Mar 19, 2021, at 09:25, Pete Heist wrote: >>>=20 >>> Meaning, the negotiation succeeds and ECT(0) is set going up, but >>> zeroed on packets by the time they come down? >>>=20 >>> The negotiation can also be blocked with iptables --ecn-tcp-remove, >>> which just zeroes out ECE and CWR, preventing negotiation >>> (https://git.netfilter.org/iptables/tree/extensions/libipt_ECN.c), >>> but >>> I doubt that's very commonly done. >>=20 >> Oh, that looks interesting, probably not too hard to extend >> this to also allow to selectively only re-map ECT(1) and or ECT(0). I >> wonder what TCP Prague would do if its ECT(1) flows are switched to >> ECT(0) in transit? >=20 > I suspect it would then dominate all traffic in the C queue, or any > other RFC3168 signalling queue > = (https://github.com/heistp/l4s-tests/#unsafety-in-shared-rfc3168-queues > ). That might be an easy way to game the dual queue for higher > throughput. >=20 > Pete >=20 >> Best Regards >> Sebastian >>=20 >>>=20 >>> On Thu, 2021-03-18 at 13:00 -0700, Dave Taht wrote: >>>> mosh, which has long had excellent support for ecn, appears to be >>>> getting the >>>> ecn bit washed out along my path from california to england. >>>>=20 >>>> ecn survives up that way, but not down. >>>>=20 >>>> Just a single data point thus far. >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecn-sane mailing list >>> Ecn-sane@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/ecn-sane