From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 1A73F3B29E for ; Mon, 20 Feb 2023 13:27:54 -0500 (EST) Received: by mail-wr1-x42e.google.com with SMTP id 6so1740426wrb.11 for ; Mon, 20 Feb 2023 10:27:54 -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=mmkeycVjP0OL3maa8KBQWs0L1zipKzUMYgWvu11Re9k=; b=hPbs8YYVUE3Kdsgv4rXMBed1FtLrlyxei6tqiK0OjMQmYPL3cbcF+WtQPMtilU7lJq zuhYaBUp90JsjWFyzqczItEIemxn7PytfU8ciXEwAcmZlTYoD0Id3CuVciebWQ6mmbWX V57AkJ9Q+GQwJnI9tWzx6eEcEdnh/I0jz93BbRV1VyzltikkEt/MZhLjL82eS8GV8K0I Uqigywfpcm2XA/STgy0Huk5qjw6nYZn4UGsjDOPEmnQG44qljDWT/9BSFAaYp2BKCpx1 +IYsuvklt+kgAmCpXRfRgJiuAyY3mMcIPnpZebB+dsZY4XzA6984dYa+2QS44lxWyZ3f BXag== 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=mmkeycVjP0OL3maa8KBQWs0L1zipKzUMYgWvu11Re9k=; b=xFAGDyHNsY4dMfmQuC6eJBAgf4/hH4/1aK1MkLthHzAqP6diJXVOovSk9xsp58lJis v2eRoK3iq+m3wzyhEEsN3Lyt5/G+zRfPdhKf0WGbsEOnimOo4EY5DSzFLgTYEoos9yUG 92ZVGARDIZ3xdR0S/GvOmnQZXxIilo8E3VixOIKZsF63mFCIY7YxZZe1nZSWvkntOhOD PRHBU3WoKbmwRF3lbmw4q7SdWh/z5ssc6EAUTpgZQBcTksKvDEBS91zOqp4QHzqGA/Xb Pia4u+x8/ZIN4DPiJVy4gt7DXfmAW+wXoT+I6wfswo3WWiiXcIXqRFKWeU5ChF90fCTr 03Rg== X-Gm-Message-State: AO0yUKUQr7EaANIjuWPQK/PIPKYLqvs0nEIi6iEyKEIc3dO/Q1ZH/9Bc NyW464ALUZcodQFHQ+nIdOvJowVbUxA1KkS5BmE= X-Google-Smtp-Source: AK7set+SfHqIaYr2yGheMFLYvb0ZT2sBRhlUAS3SH+SJHCw1qs3lsevGIvAkSLqkmYYHRUgHYmayjE3L1sV2gR5UiHs= X-Received: by 2002:a5d:570c:0:b0:2c5:6459:4ebd with SMTP id a12-20020a5d570c000000b002c564594ebdmr359854wrv.46.1676917672823; Mon, 20 Feb 2023 10:27:52 -0800 (PST) MIME-Version: 1.0 References: <26ac4e4e00b1d0f20c816630fafb7e58@rjmcmahon.com> <1209c1b2fb917edc8bf33a73782823bd@rjmcmahon.com> <3f89e35c27c144bbe4b6c8f2128e1557@rjmcmahon.com> <53b644b95d0901ef52f16bf53914517c@rjmcmahon.com> In-Reply-To: From: Dave Taht Date: Mon, 20 Feb 2023 10:27:41 -0800 Message-ID: To: Frantisek Borsik Cc: rjmcmahon , 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: Mon, 20 Feb 2023 18:27:54 -0000 On Mon, Feb 20, 2023 at 9:57 AM Frantisek Borsik via Rpm wrote: > >Besides the actual evaporating of those comments that's the saddest thing = for me... The article has improved in multiple respects, actually mentioning better packet management earlier than it had, and the overall tone shifted nicely. Frank... in the future, please criticise the ideas, and framing, and not the person. I was, I'll admit, incensed at seeing the comment thread disappear, but I then took a day to write a much better article about the VOQ problem with purchased circuits I have observed many times, and posted it widely. The comment - still preserved on that piece - with that link to that blog entry - I have a nice screenshot of now. :) Stirring up a little controversy along the way towards the truth is fine! We are all in this bloat together, and need to engineer our way out. I really do hope that what I see in so many VOQ -> XGbit SLA configurations (where the delay is additive per voq) is not as common (or as under-observed) as I think it is. Perhaps the scripts and blog I posted will encourage more folk to look at this problem more deeply, as it certainly seems to exist at many ISP->internet interconnects. Maybe good solutions will be posted somewhere on some support site that can be achieved on more hardware available today. https://blog.cerowrt.org/post/juniper/ > All the best, > > Frank > > Frantisek (Frank) Borsik > > >om/in/frantisekborsik >> > Signal, Telegram, WhatsApp: +421919416714 > > iMessage, mobile: +420775230885 > > Skype: casioa5302ca > > frantisek.borsik@gmail.com > > > > On Mon, Feb 20, 2023 at 1:02 AM rjmcmahon via Rpm wrote: >> >> Here, look at this. Designed as a WiFi aggregation device. >> >> https://www.arista.com/en/products/750-series >> >> It supplies 60W PoE and claims support for 384 ports. Oh, the max >> distance per PoE AP is 100 meters. >> >> That's insane as a power source and the 100M distance limit is not >> viable. >> >> Our engineering needs to improve a lot. >> >> Bob >> > Cisco's first acquisition was Crescendo. They started with twisted >> > pair and moved to Cat5. At the time, the claim was nobody would rewire >> > corporate offices. But they did and those engineers always had an AC >> > power plug nearby so they never really designed for power/bit over >> > distance. >> > >> > Broadcom purchased Epigram. They started with twisted pair and moved >> > to wireless (CMOS radios.) The engineers found that people really >> > don't want to be tethered to wall jacks. So they had to consider power >> > at all aspects of design. >> > >> > AP engineers have been a bit of a Frankenstein. They have power per AC >> > wall jacks so the blast energy everywhere to sell sq ft. The >> > enterprise AP guys do silly things like PoE. >> > >> > Better is to add CMOS radios everywhere and decrease power, >> > inter-connected by fiber which is the end game in waveguides. Even the >> > data centers are now limited to 4-meter cables when using copper and >> > the energy consumption is through the roof. >> > >> > Bob >> >> On Sun, Feb 19, 2023 at 3:37 PM rjmcmahon >> >> wrote: >> >>> >> >>> A bit off topic, but the AP/client power asymmetry is another design >> >>> flaw similar to bloat. >> >> >> >> It makes no sense to broadcast at a watt when the device is nearby. I >> >> think this is a huge, and largely unexplored problem. We tried to >> >> tackle it in the minstrel-blues project but didn't get far enough, an= d >> >> the rate controllers became too proprietary to continue. Some details >> >> here: >> >> >> >> https://github.com/thuehn/Minstrel-Blues >> >> >> >>> >> >>> Not sure why nobody is talking about that. >> >> >> >> Understanding of the inverse square law is rare. The work we did at >> >> google fiber, clearly showed the chromecast stick overdriving nearby >> >> APs. >> >> >> >> https://apenwarr.ca/diary/wifi-data-apenwarr-201602.pdf >> >> >> >> >> >>> https://www.youtube.com/watch?v=3DEy5jVUXSJn4 >> >> >> >> Haha. >> >> >> >>> >> >>> Bob >> >>> > Their post isn't really about bloat. It's about the discrepancy in= i/o >> >>> > bw of memory off-chip and on-chip. >> >>> > >> >>> > My opinion is that the off-chip memory or hybrid approach is a des= ign >> >>> > flaw for a serious router mfg. The flaw is thinking the links' rat= es >> >>> > 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. >> >>> > >> >>> > 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-bi= g-sharada-yeluri/ >> >>> > _______________________________________________ >> >>> > Rpm mailing list >> >>> > Rpm@lists.bufferbloat.net >> >>> > https://lists.bufferbloat.net/listinfo/rpm >> > _______________________________________________ >> > Rpm mailing list >> > Rpm@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/rpm >> _______________________________________________ >> Rpm mailing list >> Rpm@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm > > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm --=20 A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/ Dave T=C3=A4ht CEO, TekLibre, LLC