[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 at 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/