[Bloat] vyatta in AT&T 5G gear

[Stephen Hemminger]

On Tue, 16 Oct 2018 08:14:36 -0700
Dave Taht <dave.taht at gmail.com> wrote:

> On Tue, Oct 16, 2018 at 8:06 AM Stephen Hemminger
> <stephen at networkplumber.org> wrote:
> >
> > On Tue, 16 Oct 2018 11:59:18 +0200
> > Stefan Alfredsson <stefan.alfredsson at kau.se> wrote:
> >  
> > > On 2018-10-16 11:31, Mikael Abrahamsson wrote:
> > >  
> > > > On Mon, 15 Oct 2018, Dave Taht wrote:
> > > >  
> > > >> Vyos (the open source fork of vyatta) was one of the first to add
> > > >> fq_codel support... I wonder....
> > > >>
> > > >> http://linuxgizmos.com/att-releases-white-box-spec-for-its-linux-based-5g-routers/
> > > >>  
> > > >
> > > > Isn't Vyos just running the Linux kernel for forwarding? So they
> > > > received fq_codel for free when the Linux kernel got support for it?
> > > > They just had to make it configurable?
> > > >  
> > >
> > > Yes, according to this blog post,
> > > http://www.five-ten-sg.com/mapper/blog/Bufferbloat%20solved%20with%20Vyos
> > >
> > > "Now that Vyos "helium" is available with a Linux 3.13 kernel, the
> > > fq_codel queueing discipline can be used to solve many bufferbloat
> > > issues. The nightly "lithium" builds contain my patches that allow
> > > fq_codel to be used via the native Vyos configuration system."
> > >
> > > Anyway it's nice to see the Vyatta heritage living on in it's various
> > > forms (the AT&T "production hardened" Vyatta, to the Ubiquity EdgeMax
> > > and some UniFi devices, to the VyOS open version and now the future
> > > plans with dNOS -> DANOS.
> > >
> > > /Stefan
> > >
> > >
> > >  
> >
> > There are two basic components to network OS, the control plane and the
> > data plane.  VyOs has the old V1 which is filesystem based control plane
> > and kernel dataplane. DaNoS has yang/netconf database based control plane
> > (in Go) and DPDK (or switch offload?) based dataplane.  Ubiquity redid
> > the control plane as well, and uses their own hardware for dataplane.
> >
> > So more of "my grandfather's ax"...  
> 
> so in other words we should have done a dpdk version long ago. And even then,
> this white box brags of the "deep buffering" in the switch chip.
> 
> ... and I have an initial report of 2 seconds of buffering on one of
> the first 5G devices.
> 
> Sigh.
> 
> And what was so wrong with the "everything as a file" model??

Two things were an issue. At scale, the filesystem was a bottleneck and it
would have been harder to implement netconf/yang model as required by
the big boy market.

Filesystem works as toy. (see plan 9)