From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id ADBBA3B29D for ; Fri, 8 Apr 2022 12:34:06 -0400 (EDT) Received: by mail-ed1-x52a.google.com with SMTP id d7so10648794edn.11 for ; Fri, 08 Apr 2022 09:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=Hwq0MbRj7wpEUENI53lU9TwjEg49oq1Qt+iXilYpHgs=; b=F3ysM5DFwnrVpDBJ61j3QIoNZ9KLCP4M4PSiJ18QTkpmVwfIFXi391yrtZu2E6uqCR 9EfSD+Dvz9QATfI5Zm1BWLlQAiacr6+bdRwyNTkmIkMtuq/q6kaYwi+9NYufNCkOrI7I eVdtiPUoG2N+l6PKINatwnxpidp7GosetVuaqPxqoOGGe1OJ18b5f9uQi8Mlb7ATnsEa 3v0oQgCg1j7IuDtF+Oj/cb/HTpbE4AL1wet/Q2VWQIIPwIg6YZOE+wCmHwlQqzmMtwWC JUrcgstlVDzxv21VJhUh9LUvB7Osq9I3i/tG0ZBOpA4LvqlmVPCsCBZyVkb5pm6PWvse exVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=Hwq0MbRj7wpEUENI53lU9TwjEg49oq1Qt+iXilYpHgs=; b=gdj5yVu68pXNS17sb9d7yOFiPRjeprG9DIW8k9lj5M/FPJAd92/MD/B7T1bvixdqX+ VLt0PoNe8bYI9OHOVRzOB3PVPy32IaQGdnsduJts3DOrw1POgYK7uSM1Sy1dTyA4VNun RgZf9obVBvMXq33HB9G46KPoF+kCQN089hq+/ydI9gn5i4FAsROqrDZ6sgf9mx7HkATi NMkWJlBgEMX3rsuD2Voc9DqMHqGa2TpV5TsR7bBNMxfgKAingI1v5fAm2otnvz8YQ85z xxe7dw3vA3Jmzxv8LyzVyJZMdirs/rR8qnfam+f1dRnU+8vYpDCkYNN2SffS8D70U+8q uoFA== X-Gm-Message-State: AOAM531x+dleVrKHybd3ltqFd2ihf1eMwpDkIq/5m1DdGjA9EgwJ4Vaz jt7TlwRP9b9jkSF3qZAGulWJWay1YIj2c06wE2S/4xVVEvJQ+w== X-Google-Smtp-Source: ABdhPJw/WnWLFAJyLyXG5YJwDTXDaPowWUrVQnrxJ64HQdybOh8KMoLAlzNqPnd4vWjNAGP0VHReinx9tDObM7rYRpY= X-Received: by 2002:aa7:d148:0:b0:41c:df0f:194a with SMTP id r8-20020aa7d148000000b0041cdf0f194amr20605813edo.42.1649435645226; Fri, 08 Apr 2022 09:34:05 -0700 (PDT) MIME-Version: 1.0 From: Dave Taht Date: Fri, 8 Apr 2022 09:33:57 -0700 Message-ID: To: ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Ecn-sane] rtt-fairness 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: Fri, 08 Apr 2022 16:34:06 -0000 I have managed to drop most of my state regarding the state of various dctcp-like solutions. At one level it's good to have not been keeping up, washing my brain clean, as it were. For some reason or another I went back to the original paper last week, and have been pounding through this one again: Analysis of DCTCP: Stability, Convergence, and Fairness "Instead, we propose subtracting =CE=B1/2 from the window size for each mar= ked ACK, resulting in the following simple window update equation: One result of which I was most proud recently was of demonstrating perfect rtt fairness in a range of 20ms to 260ms with fq_codel https://forum.mikrotik.com/viewtopic.php?t=3D179307 )- and I'm pretty interested in 2-260ms, but haven't got around to it. Now, one early result from the sce vs l4s testing I recall was severe latecomer convergence problems - something like 40s to come into flow balance - but I can't remember what presentation, paper, or rtt that was from. ? Another one has been various claims towards some level of rtt unfairness being ok, but not the actual ratio, nor (going up to the paper's proposal above) whether that method had been tried. My opinion has long been that any form of marking should look more closely at the observed RTT than any fixed rate reduction method, and compensate the paced rate to suit. But that's presently just reduced to an opinion, not having kept up with progress on prague, dctcp-sce, or bbrv2. As one example of ignorance, are 2 packets still paced back to back? DRR++ + early marking seems to lead to one packet being consistently unmarked and the other marked. --=20 I tried to build a better future, a few times: https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org Dave T=C3=A4ht CEO, TekLibre, LLC