Re: [Bloat] vyatta in AT 5G gear

2018-10-16 Thread Dave Taht
Jan Ceuleers  writes:

> On 16/10/2018 17:14, Dave Taht wrote:
>> And what was so wrong with the "everything as a file" model??
>
> On a single box - not a lot.
>
> On a 5G network, which might consist of 10^3 - 10^5 boxes you need
> aggregation and abstraction layers.

I was mostly just venting. Still... I'd hoped that the next generation
fios gear would get bufferbloat right... and with all the 5G boasting
about the 1ms mac, that they'd get queuing delay below 20ms also.

I was also hoping the DOCSIS 3.1 line cards would get it right...

It has been a disappointing day.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


Re: [Bloat] vyatta in AT 5G gear

2018-10-16 Thread Stephen Hemminger
On Tue, 16 Oct 2018 08:14:36 -0700
Dave Taht  wrote:

> On Tue, Oct 16, 2018 at 8:06 AM Stephen Hemminger
>  wrote:
> >
> > On Tue, 16 Oct 2018 11:59:18 +0200
> > Stefan Alfredsson  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 "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) 
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


Re: [Bloat] vyatta in AT 5G gear

2018-10-16 Thread Jan Ceuleers
On 16/10/2018 17:14, Dave Taht wrote:
> And what was so wrong with the "everything as a file" model??

On a single box - not a lot.

On a 5G network, which might consist of 10^3 - 10^5 boxes you need
aggregation and abstraction layers.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


Re: [Bloat] vyatta in AT 5G gear

2018-10-16 Thread Dave Taht
On Tue, Oct 16, 2018 at 8:06 AM Stephen Hemminger
 wrote:
>
> On Tue, 16 Oct 2018 11:59:18 +0200
> Stefan Alfredsson  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 "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??

double sigh.

> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


Re: [Bloat] vyatta in AT 5G gear

2018-10-16 Thread Stephen Hemminger
On Tue, 16 Oct 2018 11:59:18 +0200
Stefan Alfredsson  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 "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"...
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


Re: [Bloat] vyatta in AT 5G gear

2018-10-16 Thread Stefan Alfredsson

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 "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



___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


Re: [Bloat] vyatta in AT 5G gear

2018-10-16 Thread Mikael Abrahamsson

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?


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat