[Rpm] Almost had a dialog going with juniper...

[Rpm] Almost had a dialog going with juniper...

[Dave Taht]

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/

-- 
Surveillance Capitalism? Or DIY? Choose:
https://blog.cerowrt.org/post/an_upgrade_in_place/
Dave Täht CEO, TekLibre, LLC

Re: [Rpm] Almost had a dialog going with juniper...

[rjmcmahon]

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 design 
flaw for a serious router mfg. 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.

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/

Re: [Rpm] Almost had a dialog going with juniper...

[rjmcmahon]

A bit off topic, but the AP/client power asymmetry is another design 
flaw similar to bloat.

Not sure why nobody is talking about that.

https://www.youtube.com/watch?v=Ey5jVUXSJn4

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 design
> flaw for a serious router mfg. 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.
> 
> 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/
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

Re: [Rpm] Almost had a dialog going with juniper...

[Dave Taht]

On Sun, Feb 19, 2023 at 3:34 PM rjmcmahon <rjmcmahon@rjmcmahon.com> 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/



-- 
Surveillance Capitalism? Or DIY? Choose:
https://blog.cerowrt.org/post/an_upgrade_in_place/
Dave Täht CEO, TekLibre, LLC

Re: [Rpm] Almost had a dialog going with juniper...

[rjmcmahon]

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 <rjmcmahon@rjmcmahon.com> 
> 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/

Re: [Rpm] Almost had a dialog going with juniper...

[Dave Taht]

On Sun, Feb 19, 2023 at 3:37 PM rjmcmahon <rjmcmahon@rjmcmahon.com> 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, and
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=Ey5jVUXSJn4

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 design
> > flaw for a serious router mfg. 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.
> >
> > 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/
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm



-- 
Surveillance Capitalism? Or DIY? Choose:
https://blog.cerowrt.org/post/an_upgrade_in_place/
Dave Täht CEO, TekLibre, LLC

Re: [Rpm] Almost had a dialog going with juniper...

[Dave Taht]

On Sun, Feb 19, 2023 at 3:44 PM rjmcmahon <rjmcmahon@rjmcmahon.com> 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 link.

> Bob
> > On Sun, Feb 19, 2023 at 3:34 PM rjmcmahon <rjmcmahon@rjmcmahon.com>
> > 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/



-- 
Surveillance Capitalism? Or DIY? Choose:
https://blog.cerowrt.org/post/an_upgrade_in_place/
Dave Täht CEO, TekLibre, LLC

Re: [Rpm] Almost had a dialog going with juniper...

[rjmcmahon]

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 <rjmcmahon@rjmcmahon.com> 
> 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, and
> 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=Ey5jVUXSJn4
> 
> 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 design
>> > flaw for a serious router mfg. 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.
>> >
>> > 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/
>> > _______________________________________________
>> > Rpm mailing list
>> > Rpm@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/rpm

Re: [Rpm] Almost had a dialog going with juniper...

[rjmcmahon]

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 <rjmcmahon@rjmcmahon.com> 
>> 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, and
>> 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=Ey5jVUXSJn4
>> 
>> 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 design
>>> > flaw for a serious router mfg. 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.
>>> >
>>> > 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/
>>> > _______________________________________________
>>> > 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

Re: [Rpm] Almost had a dialog going with juniper...

[Frantisek Borsik]

[-- Attachment #1: Type: text/plain, Size: 4286 bytes --]

What's the saddest thing for me is that the Juniper lady has acknowledged
that Dave IS right and then she added those 2 AQM to the her article (where
it should be), however, then she blocked me, and maybe even Dave, or others
that were commenting on it? Besides the actual evaporating of those
comments.

Sad. I'd visit Your Los Gatos neighbor Bob, for a small talk, Dave ;-)

All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/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 <rpm@lists.bufferbloat.net>
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 <rjmcmahon@rjmcmahon.com>
> >> 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, and
> >> 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=Ey5jVUXSJn4
> >>
> >> 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 design
> >>> > flaw for a serious router mfg. 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.
> >>> >
> >>> > 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/
> >>> > _______________________________________________
> >>> > 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
>

[-- Attachment #2: Type: text/html, Size: 7720 bytes --]

Re: [Rpm] Almost had a dialog going with juniper...

[Dave Taht]

On Mon, Feb 20, 2023 at 9:57 AM Frantisek Borsik via Rpm
<rpm@lists.bufferbloat.net> 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 <rpm@lists.bufferbloat.net> 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 <rjmcmahon@rjmcmahon.com>
>> >> 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, and
>> >> 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=Ey5jVUXSJn4
>> >>
>> >> 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 design
>> >>> > flaw for a serious router mfg. 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.
>> >>> >
>> >>> > 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/
>> >>> > _______________________________________________
>> >>> > 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



-- 
A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
Dave Täht CEO, TekLibre, LLC

Re: [Rpm] Almost had a dialog going with juniper...

[rjmcmahon]

Did your tests specifically use a Juniper router? If not, posting those 
plots on her thread probably only leads to confusion. I think removing 
them is appropriate.

Test results are very much "your mileage will vary" and the conditions 
of the tests need to be obvious, otherwise I think they muddy the water.

Starting with an assumption that every engineering group has bloat is 
probably ok for a T&M engineer, but anybody making or implying claims 
against a specific vendor without actual measurements is something I 
think we all should avoid.

We release iperf 2 as open source so each engineering group can measure 
their systems themselves without any biases ahead of those measurements, 
and each group can freely inspect the tool too in order to see what it's 
actually doing.

Bob
> On Mon, Feb 20, 2023 at 9:57 AM Frantisek Borsik via Rpm
> <rpm@lists.bufferbloat.net> 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 
>> <rpm@lists.bufferbloat.net> 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 <rjmcmahon@rjmcmahon.com>
>>> >> 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, and
>>> >> 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=Ey5jVUXSJn4
>>> >>
>>> >> 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 design
>>> >>> > flaw for a serious router mfg. 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.
>>> >>> >
>>> >>> > 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/
>>> >>> > _______________________________________________
>>> >>> > 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