From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 00C343CB37 for ; Tue, 14 Mar 2023 12:51:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1678812695; i=moeller0@gmx.de; bh=csapV5p0OObZOL6Y40Bt2H9DyGbBZ0JSdfsJnVeo05Q=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Gi7sixY45cvv7E8kSGqoJFf6QSpvaOTAqbuabF84SPLnch1n5DZuG5NgK3vGLslKc 8KWrXzphmzdabjD4S2OmiudGOxZKVI7juq4F7Os6R7bLtFh61YQV0rbl+3RjV3E11n qak+KEJQOkaJD0XqzpNhgSbc1WM4+PCMXLGehaMiKz8gjtIMZfRgSsaDkU+tedTqaa m++exCXH5ISXzKeNPczVLrHBKLXyYvgQPC1eRywlkmyIGutRxhgIkEfcv0Dl8syLeP gy8piyapvvYE8mQR2JAhPmBV0e2pPHNb7cFIHoG+8lIF9Ab1dHxgtiyGJw8v1XUKJ9 6kq6O7aGaR5ew== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MY6Cl-1q1kyJ3hzZ-00YVbj; Tue, 14 Mar 2023 17:51:34 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 14 Mar 2023 17:51:34 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , cake@lists.bufferbloat.net, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <68DD535C-620A-4227-B6A3-967010D4240A@gmx.de> References: <167348364734.15098.9183646444272144529@ietfa.amsl.com> <659CE6DE-2B9D-4210-BAF8-BCC99E2ED875@cablelabs.com> <7434C6A7-4CED-4D39-A852-2714AB9DA1DC@cablelabs.com> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Provags-ID: V03:K1:A28rrL6XyT8KDIWy1P6a+eBwoWXAxg5RVznXdlqaE6NkrLvh/Ee oxTSg2M0yyvVndjYbOXxs4H1pjGY0YJYxQGzlQpwxoy7zx5ZsSdsRyZ6z9Xwib12m3btJmu GucSZhF5KtXvBFUcHEIefyFVP49ipd7yoBHOAIgr1rJXg2pBKNZMbeL6BJ7ewGnulwPIkJC YE2Jv0GMj2fEkb5de+LPg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:s8KV31H3hT0=;ypT4fBwdcehpb+zo5a6RXwfjzHM YZnl+SrKYOkC0wNj4gr0Rr6zS9MCB7EVLwYst8+PzeojkvqR40C9FuTeBKJ8ZXd36QCS2ft/U HDaP6Kh3O6WfhB9EJu0HUmk2rUCEJvkOvGEQjOlOMYQOmaQDIR+/+kjtO4DIElCu5PlaCV7BF 6uCn5vU8CzactJahDhbIACAHredq7ZEKAGjwuPELYDyQ3n6kBqZ/lYYjnTklDmFZNi+2wNdOe T0vYfi+u5SLnOtNHmsB/jdcwpcZWHZYus1V40PeLE5GGUELw3E4doAbbFi1fphXyMyT3wsDm1 VeEGv39yyD6dxkVL9dNWY9x1CEzXBtkDofTFnCeIugJoZeJFQ7qGfv0O47JDvEcVWPdjJjBq6 Z5N89auDRcOuJfnm7JXJ+Tc2JgRnH9mdudgPV3LnHKLMO+3Md56dQaBoiNy9bIJIEYoD/qWJ2 W+pVUJLqfPk/CrjteddvdXSgAhLNJbnQgDwQBTnwLcHAjkf5mLpXjvUKd17hVJ6ECXnLLHayO wWslFBE1CG6ntEZqLC4ZikCcVpshd7iZSSuPRQ52ujfBuu0Psa2wQGvjfo1YI1hi05LAyNvka 7kuC/buuKvNHcTw7PD5j2OZX3GiVSgD1XJP97N6to6TspxQk28O7R52jcktpl0HtXBq2l+P73 ouOPDWXmJ35PRnEeR2pDuAk/bHKsclrzE683iERx2K86v5ZdctYYpDVK3gHS+/uL25YEnuA2u Gfmk+mBJJbDOf3zFQz3Nr1RmudXM3CAj2bduZo4FmsQOguX50+XSV7pQKPfC2twrh0iK8WTZq xZ7P/mg921cwbzQh8DlNSABCn2jYCzOAKm5dilUtXF8/mJ4wDTkzd3bt2z1xuG6O4qzk5cBPP nPI1RR7HM5coXlIsoSReA2WY7WCNU1ctK/EtS+dq0TEmZD5BDi46YENYrqTVVrbCu1mwnr+oh u+4vov/+7z7nw7BwvdJG/cIzR0Y= Subject: Re: [Cake] [tsvwg] 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 16:51:37 -0000 Hi Ruerdiger, > On Mar 14, 2023, at 16:09, = wrote: >=20 > Dave, >=20 > thanks for asking - I'm not an NQB author, and my know-how on Linux = QoS / Cake is fairly zero. Did you want to address Greg? >=20 > I myself am still struggling to understand how NQB operates. I = understand the idea behind it, but questions on operation still remain. >=20 > NQB has been designed for AC_VI, not AC_VO. This is not how I remember it... it is designed to operate at = slightly elevated conditional priority over AC_BE, it is just that WiFI = does not offer that so Greg went for the next best thing AC_VI happily = accepting the airtime unfairness this is going to introice. I think = calling this designed for AC_VI is maked "designed" do too much work in = that sentence. > So aggregating it with other video related DSCPs may make sense. = Greg's draft partially suggests other PHBs to forward NQB, I think. My = main concern is that no flow should be able to starve off Best Effort by = design. Let's please use a realistic definition of "starve" here that is = less absolute than "suppress to minimal congestion window" which = occasional seems to be used in this WG. > If the Linux Cake implementation does so, also if combined with WiFi = scheduling, then I'm fine. In cake "Video" is really just a name for one of the elevated = priority classes (to give users a sense of what they could put in = there). Now cake does not use priority queueing but if a priority tin = exceeds its capacity share that class is scheduled (round-robin) I = believe with best effort.=20 > If the result is, let's all mark all traffic by (e.g.) NQB as then = we'll certainly seize more bandwidth than BE/default, we don't need NQB. That is what is going to happen in cake: the Video tin gets 50% = of capacity at priority (under contention, without other takes that flow = gets up to 100%), if even a single flow is in there that single flow = gets that 50% (if it actually uses it) even if competing with more flows = in best effort... >=20 > This is not to say, NQB does or will starve off BE/default. No cake avoids starvation, but a flow abusing a priority tin can = gain a considerably unfair throughput gain. However none of this is actually needed, just leaving it in best effort = and letting flow isolation and sparse boosting do its thing should be = good enough for NQB use cases. The fact is cake really does not need NQB = for the kind of service NQB is designed for. If you disagree Dave I am = happy to see data showing this to be wrong. > I'm however not sure, whether I understood operation of it completely = and I think, draft text is insufficient or not precise. I saw and = appreciate that precise flow definitions are part of the Linux/cake = implementation. Draft NQB offers none at all. Indirectly it does, after all that is what queue protection = operates on. I do wonder though how this is going to fare with tunneled = traffic... Regards Sebastian >=20 > Regards, >=20 > Ruediger=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Dave Taht =20 > Gesendet: Dienstag, 14. M=C3=A4rz 2023 15:02 > An: Geib, R=C3=BCdiger > Cc: Greg White ; tsvwg IETF list = ; Cake List > Betreff: draft-ietf-tsvwg-nqb-15.txt vs the cake AQM >=20 > 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. (?) >=20 > Cake (please see the man page here: > https://man7.org/linux/man-pages/man8/tc-cake.8.html ) supports = multiple diffserv models. >=20 > besteffort is exactly that, besteffort, and will not gain NQB support. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Anyway, does that work for everyone? >=20 > 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.