From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 A0F6B3B29E; Thu, 14 Oct 2021 18:00:21 -0400 (EDT) Received: by mail-io1-xd2a.google.com with SMTP id h196so5560131iof.2; Thu, 14 Oct 2021 15:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+J6pHiYiPAQB0dXM4IXv6sabZJKLcSiVN4KaUGAlhU4=; b=pAeVPtfMfiW/mTBRYZHESUQgpnIfH5TEZDLVEkd/KWf0vZh1tBhBtloT7diWkX3Uqb qGOU9duQWERdRXtD91Cgpej+whlI9adeWBNrr40fGd8H56mn5CtbnL+rOc9IX/R5joPH E2M38BJSaA3W1bpy9DcLrdVka/HEBVRf75/d9pkGdvDER1YrsC1ttX3uFNUM2F51F/uc jIxjPilWfCWIt32HRn7Gyuait/VJfGQAMBfcFUv7SdpYenKFi76SFrdemhYg/j2hiH+V /L6MzoKJ45JRvEs5b/T/pXuKcZk77xPciRjr0b+QJNb0VRI2iXvEjWVnRDdTGr5R4kPp 4LEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+J6pHiYiPAQB0dXM4IXv6sabZJKLcSiVN4KaUGAlhU4=; b=1eiAXtdekfUUpMtZ5m6RUqN5nh2NKRX6iEPtQVWLhxf18FVQNSYQxg8/b2iE+MPMPO uNMiJP0uF/PZ4KHv3M6UAp4veZVFMznJt77cLMcm4cUrKfNioxdC9BSG0tS5qL+KwiCN 8MTViPZ6MuqArKzw6MG7V7AdtJjCu7KeftUSzOaIK6CMgsATU+z193CeX+u4di0g6t1w 9ffPyJtCwnVWZgFVLoRAg4w4cwYFgLHXh3PNace1yXGqd5sH0Aia6DJVNGEE7hrw28Ua Yo1bGuwVxXUFgTSZziQPskdbF9+dpZQP9xwQE6HzcOkyCoWf+op5xzR4wb9ZzhM5cca2 WH6Q== X-Gm-Message-State: AOAM533EdCmtAIwHru3rBTmG3XOnVoNkbieqyoTiVUl4PetNGJwjj6U0 gU/1g8f9NgmKfArLppMZXCG8FHAE0Nwp9VKRRQU= X-Google-Smtp-Source: ABdhPJzliNomoi+BHXm9SVjQOpkOcGZoQZiRJa+AbIiGZtHGT5n+YsARlV+hWW/kpXAK4ZZTFtYgfr1reV3cjJLZJ7I= X-Received: by 2002:a6b:ce03:: with SMTP id p3mr1120748iob.163.1634248820629; Thu, 14 Oct 2021 15:00:20 -0700 (PDT) MIME-Version: 1.0 References: <87sfx31dt5.fsf@toke.dk> In-Reply-To: <87sfx31dt5.fsf@toke.dk> From: Dave Taht Date: Thu, 14 Oct 2021 15:00:08 -0700 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Sebastian Moeller , Cake List , ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] [Cake] l4s kernel submission 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: Thu, 14 Oct 2021 22:00:21 -0000 On Thu, Oct 14, 2021 at 2:44 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Dave Taht writes: > > > weirdly enough, my gmail account has not received anything from netdev > > since oct 11. > > You're not alone in that: > https://lore.kernel.org/netdev/20211014112718.6aed7f47@kicinski-fedora-pc= 1c0hjn.dhcp.thefacebook.com/T/#t ok. One of these years I'll go back to running my own email server full tim= e. > > yes, i think fq_codel will be better, and even the proposed > > too-shallow threshold will make for less of a dent on the internet. > > > > still... I do wish I'd seen this earlier. > > Earlier? You forwarded the patch hours after it was posted... I have a daily search for fq_codel, bufferbloat, etc. I have noticed lately that some mailing list traffic from us is being indexed again. I wish I knew why our lists were not indexed by google. Anyway, lacking being on that thread, it's currently impossible to reply. I would certainly like more to be exploring HFCC - I do agree that a shallow marking threshold is increasingly necessary at rates beyond 10Gbit, and that more would read - https://github.com/heistp/l4s-tests#key-findings before the internet is split into a fast and slow lane. That said, the l4s fq_codel patch is intrinsically fair, which is vastly superior to the dualpi approach. I think that the over-shallow proposed threshold of 50us - the lowest I'd seen to date was 250us! won't work on anything other than bare iron or from a self-local qdisc, and that will lead to the implementation being naturally slow rate on virtualized hosts, but lossless, which would be a win, and for all I know interact well with the fast/slow queue concept. I certainly think bbrv2 needs more testing, as it has always seemed to be a more promising approach than prague. My biggest feedback on the patch so far is I dislike the overload on reporting where the CE came from, and would prefer that l4s_ce be exposed to userspace. We have very little data on actual ce's in the field as it is - conflating the two statistics won't help - I also hate adding anything more to the hot path. And if we have to do it, making sce available as an optional at the same time has the same computational cost. And it still bugs me, very much, that bbrv1 has no rfc3168-like response. Perhaps with some time to work on a coherent reply to this patch and figuring out how to get back on netdev, I can say all that better. Or I can just go back to fixing up my boat. > > -Toke --=20 Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw Dave T=C3=A4ht CEO, TekLibre, LLC