From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 43C953CB40 for ; Sun, 19 Feb 2023 18:45:21 -0500 (EST) Received: by mail-wm1-x331.google.com with SMTP id j41-20020a05600c1c2900b003e1e754657aso1115488wms.2 for ; Sun, 19 Feb 2023 15:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=ncng3dB/YH4k9/tUUSl7nRBIWBBrFgdI0ofZSLhDYRk=; b=BKfQCeU6Ln++KZJbnGZCjy3T2hWcN6a10kMuTHeo1GE7XVXnPN2OomYTsBRTE5Mijx 1gB/Cuq5BuBPNU0I5dkDLRYqIw11wnjhmWNsN/ASEI9Bp85MuXbnuM5cCb4pRFvj0ItX varau5fnD9hlQ8ImHEm1W26CaqPy2ozVnfMjDvNoQs+2A7aUlO2dI1jwv0CLxvf0T/37 eOhJm9yxkxahLmZqENEmy73M9DtJ74CKBbUXCP64JnS7ZsFwiz8R3uYOmsmIMjwWFqLI VW+iQYkywLECpTu8gWRQSRF0Hk5RnRyAXc/1DmHoD3p/8NJEtYohv1Tt4wAUsSkJ2DFT nsTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=ncng3dB/YH4k9/tUUSl7nRBIWBBrFgdI0ofZSLhDYRk=; b=gd28lBo5zeUEP/YY9pVW2XaAI6sEothFfpLCqQCNZMyrSEIWRFnR2+9JS1iKstoMaW uvzgVQIFQmV+PHfmSgZRR6/cgmL1Crvl1FWENMIXkcIAoIOlzHSLKrSNY1iaL5LOoSqv JXzspAN1MnL7Z5A52EHL4WzMgwzXrTYLx0zc0NC+iNsI2puHwYPv4d+7WYh1QBPWVnYD 2ZF6ut07xjwuFYPx8ITXBLOBRmpH1kptQEqgudAdmEPtPPqurPquHZ/ZJFm6nkAXB3we CBD+TOsGWRV/G7jKd9ndKfDXCxi4KF80y1u6Ps4oIGbc2E+to6T9o0UXTaFXT8Gfpsal fKPw== X-Gm-Message-State: AO0yUKX7V4jOctLbDwi5Mw1DKlWvgC1ytG6bc2IxjxgSRNi9IlHdQvVg 9YAXw70zvnqUuuPJfEyeHYLkG0KuU/GEuR2F0qc= X-Google-Smtp-Source: AK7set88q4I4wAan1uOS7xceh9FrNHBOXZIJMWlGDiMP9RjHwdTNKoBsBZvs0jefLM/XgpkS4C8gwoWbX+1NMSzyE9g= X-Received: by 2002:a05:600c:8506:b0:3e2:1c73:a1aa with SMTP id gw6-20020a05600c850600b003e21c73a1aamr152368wmb.206.1676850320275; Sun, 19 Feb 2023 15:45:20 -0800 (PST) MIME-Version: 1.0 References: <26ac4e4e00b1d0f20c816630fafb7e58@rjmcmahon.com> <4012c0f33597bb20b5034957b5c8e1a2@rjmcmahon.com> In-Reply-To: <4012c0f33597bb20b5034957b5c8e1a2@rjmcmahon.com> From: Dave Taht Date: Sun, 19 Feb 2023 15:45:08 -0800 Message-ID: To: rjmcmahon Cc: Rpm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:45:21 -0000 On Sun, Feb 19, 2023 at 3:44 PM rjmcmahon wrote: > > 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. The test I did in that blog series was with RFC3168 ecn. No loss on the lin= k. > 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, t= o > >> > see how they frame the buffering problems to themselves in their pos= t: > >> > https://www.linkedin.com/pulse/sizing-router-buffers-small-new-big-s= harada-yeluri/ --=20 Surveillance Capitalism? Or DIY? Choose: https://blog.cerowrt.org/post/an_upgrade_in_place/ Dave T=C3=A4ht CEO, TekLibre, LLC