From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bobcat.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3E1D13CB40 for ; Sun, 19 Feb 2023 18:44:12 -0500 (EST) Received: from mail.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) by bobcat.rjmcmahon.com (Postfix) with ESMTPA id 849FC1B258; Sun, 19 Feb 2023 15:44:11 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com 849FC1B258 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1676850251; bh=B1lykcWIJmIrBhkOaBrRXL2n+rJXGkIvvY1Ae9JX++c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lP+jSNkRaTyfBuFovqU1fH0AgcUQ+PaFTr6H1/4Qp0PwWsWoIYwpv2ovvjkdz/rmX wPUtJZlqvzzsJI4cy+/RvHMj/xqLifiWr/ffRNQaq8wDmz9mHkSOPB/yBfs14wbYW3 cLffLvE1FGOZtnmJnWB8RnsH3Hbg2nSVh+JZ2wYc= MIME-Version: 1.0 Date: Sun, 19 Feb 2023 15:44:11 -0800 From: rjmcmahon To: Dave Taht Cc: Rpm In-Reply-To: References: <26ac4e4e00b1d0f20c816630fafb7e58@rjmcmahon.com> Message-ID: <4012c0f33597bb20b5034957b5c8e1a2@rjmcmahon.com> X-Sender: rjmcmahon@rjmcmahon.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Rpm] Almost had a dialog going with juniper... X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2023 23:44:12 -0000 It's a conflict in design goals. They're trying to sell to customers that don't want data loss in the data centers for things like RDMA messaging and claiming their equipment is universal to all use cases. It's really not. We're TCP end/end guys and packet loss can be a very good signal. Bob > On Sun, Feb 19, 2023 at 3:34 PM rjmcmahon > wrote: >> >> Their post isn't really about bloat. It's about the discrepancy in i/o >> bw of memory off-chip and on-chip. > > The original comment thread was about how the flow queuing aspect of > fq_codel derived algorithms, would leverage on-chip resources better, > and about how VOQs do misbehave today. > > >> >> My opinion is that the off-chip memory or hybrid approach is a design >> flaw for a serious router mfg. > > I concur. I think we need smarter buffering, not more buffering. > Admittedly while the overhead for > 10,000 fq_codel'd virtual queues (e.g. 1 million total queue states) > without tuning is presently 64M that needs to live in high speed > memory for that next indirect lookup... it is possible to trim that > down quite a lot. > >> The flaw is thinking the links' rates and >> the chip memory i/o rates aren't connected when obviously they are. >> Just >> go fast as possible and let some other device buffer, e.g. the end >> host >> or the server in the cloud. > > Juniper will hold onto their big buffers are > profitable^H^H^H^H^H^H^H^Hneeded strategy until the bitter end. > >> >> Bob >> > https://blog.cerowrt.org/post/juniper/ >> > >> > But they deleted the comment thread. It is interesting, I suppose, to >> > see how they frame the buffering problems to themselves in their post: >> > https://www.linkedin.com/pulse/sizing-router-buffers-small-new-big-sharada-yeluri/