From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 287293CB37 for ; Tue, 14 Mar 2023 10:02:04 -0400 (EDT) Received: by mail-wr1-x431.google.com with SMTP id p4so8257314wre.11 for ; Tue, 14 Mar 2023 07:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678802523; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FKw4t8AorS/XRbHTcXRIvXbiQ1OoG2SmB8vwZs2kkmI=; b=mRIVNXz0Eagv4pKzmXu7dWX1cfiGqSKhqBbYSjRwBnsSSC3o2tmfo7fovzm+47Wo2M d/orTm58H/AS4H3p99B1qTbnLFHfRygfg9gQbvngEFKFcgBTiKWhuLZsFpCojUbaPWtY XQc5r626BzgLUS+fjVt/trG1vTThxjmwAz23nYBTmGYg2dcCQwJG4l4ZtfEhWrudJa0r sQ83ZkXkcN+YP63otHjjBwQKVe8C4Icusfv76dXYHe37gGlzKsUwRRGNrRCdN/FgVviC Z8q3G4WkGzfWTcVZeJof95lZjQmkFHgjpSyot7FVQ0iryKneWd/CXuN5qcGqx5KFvpKI vWRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678802523; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FKw4t8AorS/XRbHTcXRIvXbiQ1OoG2SmB8vwZs2kkmI=; b=vqMmrUeP/ohCYQ6tnh/GmaDLiRvKWv2eaSpXozQhbGSsFv+gh16JZ5bbu9tNZ0BiXZ woxYrFEvbSl2hBr2IF+iojNgUCxB8fsmE3ruu+BeDB0oKy5l0AMob/0y5s0dMmox4x3s HRWembw4xaPf9OSqepw1vbbQOM44tpubx4JG1bzps7kqyZlmuC9A5muNernbFcyo8DLs 2aGXoSPYCWxuRmGswfG3J01Qdz4rQbxvrUE7qpelcNfq/KZYSjX5Vk6JvtWsNkWRrGGL kHTFSxlFusQbdfQ1kkXkHRjVYcseGlj5VhNmQLRBnT0ckYTcsairDnINRZQWnlsJLpCw 7Kpw== X-Gm-Message-State: AO0yUKXv4mBfxkQ2AvHmYoBM9amfE97kels5eLLgDwjaMuBB1DYsOXgW 01kzZ4swzwMcHE9J9m3gqriSMGaW2el/bg8eWQY= X-Google-Smtp-Source: AK7set8xixzHlBwKw82dSl/tgm3DEfCVv6IqUgjFb5BZqZHnEWEi7bnpdh+Ew1L/pgbEZLfSaEH4IRRISKEbaCvz17s= X-Received: by 2002:a5d:4347:0:b0:2c9:8a3c:9fc0 with SMTP id u7-20020a5d4347000000b002c98a3c9fc0mr7903247wrr.13.1678802522872; Tue, 14 Mar 2023 07:02:02 -0700 (PDT) MIME-Version: 1.0 References: <167348364734.15098.9183646444272144529@ietfa.amsl.com> <659CE6DE-2B9D-4210-BAF8-BCC99E2ED875@cablelabs.com> <7434C6A7-4CED-4D39-A852-2714AB9DA1DC@cablelabs.com> In-Reply-To: From: Dave Taht Date: Tue, 14 Mar 2023 07:01:51 -0700 Message-ID: To: Ruediger.Geib@telekom.de Cc: Greg White , tsvwg IETF list , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Cake] draft-ietf-tsvwg-nqb-15.txt vs the cake AQM X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2023 14:02:04 -0000 I have been sitting on the cake related patches for this for years now, and it is my hope to get support for NQB into the next linux release, regardless of whether it gets through last call at this time, unless the selected codepoint number changes. (?) Cake (please see the man page here: https://man7.org/linux/man-pages/man8/tc-cake.8.html ) supports multiple diffserv models. besteffort is exactly that, besteffort, and will not gain NQB support. The diffserv3 interpretation is the default, and given that flow queuing handles most of the NQB-like problems naturally, and Voice (CS7, CS6, EF, VA, TOS4) is all that is handled there today, I am thinking of *not* elevating NQB into that class is the right thing. NQB fits nicely into the diffserv4 model in the video class, so I will put it there. since covid we tend to use the diffserv4 model a lot to manage videoconferencing better. As for the CS0-CS7 precedence model inc cake, we have declared that obsolete in the code, and wherever NQB falls into it, great. And the diffserv8, I don=C2=B4t know. Anyway, does that work for everyone? Part II of this would be a discussion of the various wash modes, but merely getting the right byte into the right lookup tables after all this discussion, would be nice.