Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

[dpr...@deepplum.com]

Meltdown is very easy to exploit, and doesn't need heavy CPU usage (well, the 
obvious exploit is dumping all of kernel data space, which might be somewhat 
slower than a memcpy() of that data. :-)
 
Essentially, you run a loop that uses speculative memory tests to load a unique 
userspace cache line for each bit of kernel memory, and after loading some 
cache lines, you check to see if those userspace locations are in the cache. If 
you stick lo L1 cache, you can do this concurrently on multiple cores. But you 
don't need multiple cores, one will do.
 
That assumes that you are running a program that wants to read your kernel data 
looking for passwords in the clear, etc.
 
Sceptre may require heavy CPU usage, but Meltdown doesn't.
 
Depending on how you set up your "home router", you might allow "infected" or 
"trojan" programs to run in userspace there. I wouldn't do that, because 
hardware is cheap. But some people like to throw all kinds of server code into 
their router setups - even stuff like node.js servers.
 
The really core issue with Meltdown at the highest level is that the kernel is 
addressable from userspace, except for the "privilege level" in the page table 
entries. That's a couple of bits between userspace and data that userspace 
isn't supposed to ever see. And those bits are ignored during specutlative 
execution's memory accesses.
 
-Original Message-
From: "Dave Taht" 
Sent: Thursday, January 4, 2018 9:53am
To: "Jonathan Morton" 
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than 
x86?



On Thu, Jan 4, 2018 at 6:49 AM, Jonathan Morton  wrote:
>> On 4 Jan, 2018, at 3:59 pm, Dave Taht  wrote:
>>
>> Alan cox has been doing a good job of finding the good stuff. Power
>> and the IBM z-series are also affected.
>
> Conversely, the ARM-1176, Cortex-A7 and Cortex-A53 cores used by various 
> iterations of the Raspberry Pi are not affected. These are all in-order 
> execution CPUs with short pipelines, and I think they're representative of 
> what you'd want in CPE.

Well, I'd hope that this string of bugs stalls deployment of more
advanced arches in this space until the speculative execution bugs are
fully resolved.

(and I *vastly* prefer short pipelines)

> - Jonathan Morton
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] fcc initial comments due sept 10

[dpr...@deepplum.com]

1000/25 is my current low cost service. Due to competition, low cost 1000/1000 
is rapidly spreading in the Boston area, on a number of novel tech 
infrastructures. Sadly, government thinks that Monopoly is the tool to "incent" 
reluctant incumbents, and/or classification by FCC surveys.

Competition (new entrants, or multiple providers) does it without the FCC even 
being engaged.

But businesses DONT want competition if they can corrupt the government cheaper.

Look at Pennsylvania... Bought and paid for, Comcast Country. Tax subsidies, 
laws against Muni Fiber, ... Comcast has great technologists, for sure. So did 
Bell Labs in its heyday. But touchtone took 20 years and still didn't make it 
widely, even though it would have allowed advanced switching services.

FCC isn't the place to make things happen.

-Original Message-
From: "David Lang" 
Sent: Mon, Aug 13, 2018 at 11:45 pm
To: "dpr...@deepplum.com" 
Cc: "Dave Taht" , cerowrt-devel@lists.bufferbloat.net, 
"bloat" 
Subject: Re: [Bloat] [Cerowrt-devel] fcc initial comments due sept 10

On Fri, 10 Aug 2018, dpr...@deepplum.com wrote:

> Now 25 Mb/sec is totally fine for most standard WWW/email usage, and even a 
> little YouTube watching.

I'm currently doing that fairly comfortably on a 5/1 line, 25mb would be very 
nice to be able to get.

David Lang


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] expressobin

[dpr...@deepplum.com]

https://www.cnx-software.com/2018/08/03/clearfog-gt-8k-high-end-networking-sbc-marvell-armada-a8040-processor/

Looks interesting... I like the SFP+ being there, too.

(Regarding Xilinx ... My focus is on the FPGA. The ARM cores are less 
interesting, other than that the FPGA side can directly access their cache 
system creating a powerful, fast, coherent autonomous DDR backed memory 
addressable memeory for packets that does not need processor intervention. But 
Xilinx parts are not cheap)




-Original Message-
From: "Dave Taht" 
Sent: Wed, Aug 1, 2018 at 4:06 pm
To: dpr...@deepplum.com
Cc: "Toke Høiland-Jørgensen" , "Daniel Ezell" 
, "Cake List" , 
cerowrt-devel@lists.bufferbloat.net
Subject: Re: Re: [Cerowrt-devel] expressobin

On Wed, Aug 1, 2018 at 5:49 AM dpr...@deepplum.com  wrote:
>
> Yeah. Small FF 2 port Celeron board is what I use. And I have a 4 port Atom 
> that runs like a bat out of hell.
>
> Currenty fiddling with Xilinx Dev boards, just put packet processing in FPGA 
> for Cake, and no problem with 2.5 - 10 Gb/sec. Just need a free piece of low 
> level SFP+ interfacing logic.

cool. which? ultrascale?

I was looking over
http://cseweb.ucsd.edu/~ssradhak/Papers/senic-nsdi14.pdf again

> My use case is using the open ChipLink/TileLink bus from RISCV rather than 
> PCIe, making something that might be an open source ASIC design.

How fast can that cpu context switch?

>
>
> -Original Message-
> From: "Toke Høiland-Jørgensen" 
> Sent: Wed, Aug 1, 2018 at 5:23 am
> To: "Dave Taht" , "Daniel Ezell" 
> Cc: "Dave Taht" , "Daniel Ezell" , "Cake List" , 
> cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] expressobin
>
> Dave Taht  writes:
>
> > It turns out it's just two ethernets with one, connected to a 2 port
> > switch. Not what I wanted. I'd wanted something different from the
> > apu2 or edgerouter X to play with, and I know the mvneta driver was
> > bql'd.
>
> I bought one of these to play with:
> https://teklager.se/en/products/routers/tlsense-i3-4lan
>
> x86 (i3 processor), four real ethernet ports, and passively cooled. A
> bit pricy, though; more than $400... But doubles well as a combined
> switch and media player :)
>
> -Toke
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] linus vs wireguard

[dpr...@deepplum.com]

Please note that my comments are from someone who, unlike Edge Security, has 
been involved in secure systems design off and on since 1973, not 2003 which is 
the level of expertise claimed by Edge Security. And I think I am the first 
person to write an automated system kernel exploit generation tool at about 
that time, working on the Multics Security Kernel project. The explotss 
generated searched for cases where the kernel entry points were sensitive to 
concurrent changes in other processors, just like Spectre and Meltdown exploit 
concurrent microarchitecture stuff.

This is why putting complexint in the hands of kernel developers who share a 
single protection domain (the kernel) is REALLY dangerous. It's not a 
theoretical pedantic issue.

But hey, Linus doesn't give a shit.

-Original Message-
From: "Dave Taht" 
Sent: Thursday, August 2, 2018 2:26pm
To: cerowrt-devel@lists.bufferbloat.net
Subject: [Cerowrt-devel] linus vs wireguard

-- Forwarded message -
From: Linus Torvalds 
Date: Thu, Aug 2, 2018 at 11:19 AM
Subject: Re: [GIT] Networking
To: David Miller 
Cc: Andrew Morton , Network Development
, Linux Kernel Mailing List



On Wed, Aug 1, 2018 at 9:37 PM David Miller  wrote:
>
> Fixes keep trickling in:

Pulled.

Btw, on an unrelated issue: I see that Jason actually made the pull
request to have wireguard included in the kernel.

Can I just once again state my love for it and hope it gets merged
soon? Maybe the code isn't perfect, but I've skimmed it, and compared
to the horrors that are OpenVPN and IPSec, it's a work of art.

  Linus


-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] expressobin

[dpr...@deepplum.com]

Yeah. Small FF 2 port Celeron board is what I use. And I have a 4 port Atom 
that runs like a bat out of hell. 

Currenty fiddling with Xilinx Dev boards, just put packet processing in FPGA 
for Cake, and no problem with 2.5 - 10 Gb/sec. Just need a free piece of low 
level SFP+ interfacing logic.

My use case is using the open ChipLink/TileLink bus from RISCV rather than 
PCIe, making something that might be an open source ASIC design.


-Original Message-
From: "Toke Høiland-Jørgensen" 
Sent: Wed, Aug 1, 2018 at 5:23 am
To: "Dave Taht" , "Daniel Ezell" 
Cc: "Dave Taht" , "Daniel Ezell" , 
"Cake List" , cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] expressobin

Dave Taht  writes:

> It turns out it's just two ethernets with one, connected to a 2 port
> switch. Not what I wanted. I'd wanted something different from the
> apu2 or edgerouter X to play with, and I know the mvneta driver was
> bql'd.

I bought one of these to play with:
https://teklager.se/en/products/routers/tlsense-i3-4lan

x86 (i3 processor), four real ethernet ports, and passively cooled. A
bit pricy, though; more than $400... But doubles well as a combined
switch and media player :)

-Toke
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Cake] expressobin

[dpr...@deepplum.com]

Why 3 ports?

Other than what?

-Original Message-
From: "Dave Taht" 
Sent: Tue, Jul 31, 2018 at 11:17 pm
To: "Outback Dingo" 
Cc: "Outback Dingo" , "Cake List" 
, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] [Cake] expressobin

On Tue, Jul 31, 2018 at 8:10 PM Outback Dingo  wrote:
>
> nice, but needs an atheros AC wireless hat or something

youse wifi geeks... :)

I just wanted "some other arch" that could shape cake at a nearly a
gbit. Mips falls over. the apu2 struggles a bit.
> On Wed, Aug 1, 2018 at 4:54 AM Dave Taht  wrote:
> >
> > 50 bucks. Dual core arm. 3 "real" ethernet ports?
> >
> > https://www.amazon.com/Globalscale-Technologies-Inc-SBUD102-ESPRESSObin/dp/B06Y3V2FBK/ref=sr_1_1?ie=UTF8=1491848966=8-1=espressobin
> >
> > with cake: https://github.com/davidk/espressobin-lede-sqm-cake
> >
> >
> > --
> >
> > Dave Täht
> > CEO, TekLibre, LLC
> > http://www.teklibre.com
> > Tel: 1-669-226-2619
> > ___
> > Cake mailing list
> > c...@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] So how far behind is the embedded router world, still?

[dpr...@deepplum.com]

In some ways, the quickness is good, beats the old days of ATT monopoly never 
innovating except over 10 year incremental cycles.

But Linux isn't capable of quick innovation. It's too overcomplicated. Too many 
parts barely fit together, or don't. Huge config files encoding same info in 
inconsistent ways. Poor cross compilation architecture, if there is one at all. 
Days long build cycles.

Then throw in UEFI which has to be built on Windows to get it right.

Not a system that can chase innovation of the small kind. Hardware is now like 
software in how varied it can be. But software is no longer about flexibility 
of abstraction. Every Linux is a Time Sharing System.


-Original Message-
From: "Joel Wirāmu Pauling" 
Sent: Thu, Jul 26, 2018 at 4:34 pm
To: "Dave Taht" 
Cc: "Dave Taht" , "Jonathan Morton" 
, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] So how far behind is the embedded router world, 
still?

Just a note - a lot of this mess is due to China's rapid dev cycles and
race to the bottom on cost vs supply.

Generally a fab house who is in turn contracted by an OEM in China will
have 1 maybe 2 engineers who will do the initial low level C bits required
for a product/board. They get it working on whatever build environment they
have at hand and chuck it over the fence to product unit who ship it. Then
moving onto the next contract never to be seen from again.


-Joel


On 27 July 2018 at 08:15, Dave Taht  wrote:

> On Thu, Jul 26, 2018 at 9:48 AM dpr...@deepplum.com 
> wrote:
> >
> > How would one get Linux Foundation to raise money to sponsor a router
> software initiative?
>
> We tried. Personally, having bled out mentally and financially more
> than once, I am not up to trying again. They don't return our calls
> anymore.
>
> > I can see that all the current network product OEMs might mass up to
> kill it or make it fail. Kind of like coreboot vs. UEFI.
> >
> > But maybe Facebook or Amazon or Google - dedicated white-box fan
> companies - might do it. Or maybe there's a Chinese funding source.
>
> Well, try to sort through
> https://www.forbes.com/sites/forbesnycouncil/2018/07/26/
> why-you-should-start-looking-at-googles-flutter-and-
> fuchsia-now/#795943a6a309
>
> As for china, sure, that would be great. Europe, sure. I think china
> has a huge incentive to get into making better firmware in
> collaboration with europe. As for america...
>
>
> > -Original Message-
> > From: "Jonathan Morton" 
> > Sent: Thursday, July 26, 2018 10:13am
> > To: "Mikael Abrahamsson" 
> > Cc: cerowrt-devel@lists.bufferbloat.net
> > Subject: Re: [Cerowrt-devel] So how fHow wouar behind is the embedded
> router world, still?
> >
> > > On 26 Jul, 2018, at 11:53 am, Mikael Abrahamsson 
> wrote:
> > >
> > > they seem to live in a world where you take a linux kernel that's
> announced as LTS (in the best of worlds), work on that for 1-2 years during
> which you release an SDK, which then the device manufacturers will take and
> start putting their solutions on, which takes another 1-2 years before it
> reaches customers.
> >
> > This in itself sounds like a colossal waste of developer man-hours.
> Which really just serves to underline how clueless CPE vendors are - about
> their core business, no less.
> >
> > They obviously have a lot more resources than we do.  What could *we* do
> with that level of funding and organisation?  Take six months, and put out
> a router that *doesn't* suck for a change!
> >
> >  - Jonathan Morton
> >
> > ___
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> >
> > ___
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] So how far behind is the embedded router world, still?

[dpr...@deepplum.com]

How would one get Linux Foundation to raise money to sponsor a router software 
initiative?

I can see that all the current network product OEMs might mass up to kill it or 
make it fail. Kind of like coreboot vs. UEFI.

But maybe Facebook or Amazon or Google - dedicated white-box fan companies - 
might do it. Or maybe there's a Chinese funding source.

-Original Message-
From: "Jonathan Morton" 
Sent: Thursday, July 26, 2018 10:13am
To: "Mikael Abrahamsson" 
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] So how fHow wouar behind is the embedded router 
world, still?

> On 26 Jul, 2018, at 11:53 am, Mikael Abrahamsson  wrote:
> 
> they seem to live in a world where you take a linux kernel that's announced 
> as LTS (in the best of worlds), work on that for 1-2 years during which you 
> release an SDK, which then the device manufacturers will take and start 
> putting their solutions on, which takes another 1-2 years before it reaches 
> customers.

This in itself sounds like a colossal waste of developer man-hours.  Which 
really just serves to underline how clueless CPE vendors are - about their core 
business, no less.

They obviously have a lot more resources than we do.  What could *we* do with 
that level of funding and organisation?  Take six months, and put out a router 
that *doesn't* suck for a change!

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] So how far behind is the embedded router world,still?

[dpr...@deepplum.com]

Embedded Linux is still a mess.

I've been putting some serious (hacking) effort into RISC-V, using the near 
desktop class HiFive Unleashed board. The vendor (SiFive) and the RISC-V guys 
use buildroot! There is a coreboot project, but nothing for the actual hardware 
exists... Just a lashup for a qemu emulator of a vanilla system.

No reason for lede really ... There is no standard network adapter for its bus 
other than a GigE device.

But this got me thinking about lede, Android, Yocto, Linaro. What a godawful 
mess this world that *Linus doesn't care about* is in.

Now the Linux kernel is OK. It can be made simple. But from the call to init() 
onwards, Linux and BSD just suck. Baling wire and chewing gum. Even initramfs 
is unmaintanable between releases.

Part of this is package mania. Nothing is shrink wrapped. Everything needs re 
testing, by every vendor, every time. And it usually breaks.

Part of this is binaries tied to a particular instance of hardware. Blobs. Why 
do they exist? To divide the OEMs among themselves and waste time and effort, 
mostly. They do reduce the cost of supporting driver tweakers who don't 
understand how the hardware works, or build support that makes the vendor 
unable to improve it's product, but maybe there's a better way ... Create an 
Open Source Community?

And then there are the buses/controllers. I blame Linux for blessing PCI .. an 
overcomplex and downright weird Wintel abortion. With patents all over the 
place, meaning one can't clone it without creating sales for Intel processors.

But Linux's original sin is that it was created solely for x86 environment. 
Yeah people have pushed it, but design decisions in the IO world around it have 
followed the path of least resistance. That is, letting Intel Corporation (with 
its buddy AMD) control Linux design and implementation.

Is it time for a new OS framework that can solve the embedded industry's 
problems of huge waste and obsolescence? Not black sheep Linaro. They get 
little respect. Outside the Linux Foundation's Party Secretariat's dominance.

RISC-V suggests to me that an open hardware world can be better than 
Intel-world. The proposed interconnect, called TileLink, exists, and has a 
simple working version on the board I'm playing with. It is scalable and 
flexible like modern PCI, but has no lock-in and legacy. The ISA is, of course, 
clean and extensible.

So can an industrial strength OS, not based on the Linux spaghetti, be made to 
replace Linux. Its network stack would be Internet v6 (v4 optional) and it 
would have IO done in isolated address spaces, communicating via mapped pages 
with devices and other processes. It would have the ability to launch POSIX 
processes, but keep all that out of the kernel address space, so you could just 
avoid all that on devices like storage and network appliances and IoT.

Maybe one could even start with a Linux kernel, but only that. Init() would be 
entirely different, and only a subset would be used. The ABI would be extended 
for simpler user space coding of device, network, ... logic that directly 
operates the hardware and presents simple queue based (rings?) IPC.

Why not now?



-Original Message-
From: "Mikael Abrahamsson" 
Sent: Thu, Jul 26, 2018 at 4:53 am
To: "Dave Taht" 
Cc: "Dave Taht" , cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] So how far behind is the embedded router 
world,still?

On Wed, 25 Jul 2018, Dave Taht wrote:

> There are still a few companies alive in this space (openrg being one 
> that I know nothing about), but...

There is no single answer to this. Lots of the home routing SoC space is 
now converging on 4.4, but BCM decided to go for 4.1. They came from 3.2, 
3.4 and perhaps 3.10. When I talk to staff at SoC vendors, they seem to 
live in a world where you take a linux kernel that's announced as LTS (in 
the best of worlds), work on that for 1-2 years during which you release 
an SDK, which then the device manufacturers will take and start putting 
their solutions on, which takes another 1-2 years before it reaches 
customers. So already there is significant latency.

This doesn't mean there are not devices out there today, newly installed, 
that have really ancient kernels (as you have discovered). This is 
especially true for cheaper and simpler devices that are very cost 
optimized.

There is movement in the right direction, but revving kernels on older 
platforms is still hard, as in all of IoT space, due to lack of revenue 
from older platforms. Main model is still to sell a device and then there 
is no further income, so no money to continously develop the device.

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net

Re: [Cerowrt-devel] So how far behind is the embedded router world, still?

[dpr...@deepplum.com]

The FCC wants to throw people like you in jail, you know. The rules allowing 
them to do so are coming into force.

-Original Message-
From: valdis.kletni...@vt.edu
Sent: Wednesday, July 25, 2018 3:14pm
To: "Dave Taht" 
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] So how far behind is the embedded router world, 
still?

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
On Wed, 25 Jul 2018 11:50:31 -0700, Dave Taht said:

> I recently took apart verizon FIOS's current firmware for one of their
> more popular routers. It's still running 2.6.21, which shipped in
> june, 2007. Overgeneralizing from this one data point, I am wondering
> if the trendline for new routing products tracking current software
> has got worse or better?

I have to admit I bought a Linksys WRT1200AC and it didn't stay on
factory firmware long enough for me to check, it got Lede installed
right over the top before it got swapped in for the old router

Friends don't let friends run factory firmware... :)


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat andits remedies

[dpr...@deepplum.com]

The best is the enemy of the pretty good.

Isn't there some cumulative lag under load statistic that can be maintained by 
a pinger sampling lag as a function of current rate (upload and download)? The 
Pinger would only ping when load is above a threshold, and only count data as 
valid if load during ping remains above threshold.

If you scatter plot lag times as a function of current load load, there should 
be a very obvious knee very visible at just above the optimal control limit. 

In Luci, this plot could be shown, covering time since last adjustment. The 
user then can see what rate to use, and also evidence of the problem. Just one 
plot and one setting.

-Original Message-
From: "Sebastian Moeller" 
Sent: Wed, Jun 20, 2018 at 4:07 am
To: "Kevin Darbyshire-Bryant" 
Cc: "Kevin Darbyshire-Bryant" , "Jonathan 
Morton" , "cerowrt-devel@lists.bufferbloat.net" 
, "bloat" 
Subject: Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat andits remedies

Hi Kevin,


> On Jun 20, 2018, at 09:12, Kevin Darbyshire-Bryant  wrote:
> 
> 
> 
>> On 20 Jun 2018, at 00:41, Jonathan Morton  wrote:
>> 
>>> On 19 Jun, 2018, at 11:34 pm, valdis.kletni...@vt.edu wrote:
>>> 
>>> Do we have a good cookbook on how to determine the set-rate?
>> 
>> On DSL, the sync rates in each direction should usually be readable from the 
>> modem; they are typically reported on the router's status page.  The 
>> advertised rate is less reliable, to say the least.
> 
> I’ve been experimenting with this hack in sqm-scripts to do just that 
> https://github.com/ldir-EDB0/sqm-scripts/commit/a71ab1c9acd75d6e9254360e832ac7b6f9514e88
>  originally on my parents DGN3500 and currently on my on BT HomeHub5a test 
> line.

Clever (I see how you chiseled data_rates() into shape here, respect)! 
Even though I believe that this is not pppoa specific and should probably check 
whether /lib/functions/lantiq_dsl.sh exists. Actually this code will also work 
on VDSL2 links... (and we should also be able to extract the encapsulation atm 
or ptm).

if [ "pppoa-wan" = "$IFACE" ]; then
if [ -f "/lib/functions/lantiq_dsl.sh" ] : then
...
fi
fi

But would it not be simpler to call /etc/init.d/dsl_control status | grep -e 
"Data Rate:" or somesuch? Cureently openwrt only supports lantiq/intel modems, 
but if broadcom modems should ever be supported I venture a guess they will not 
use /lib/functions/lantiq_dsl.sh to generate the stats output ;) (not that 
there is a guarantee that dsl_control would exost and generate compatible 
output).


But I believe that this is not that helpful as a mode to automatically set the 
bandwidth*, as I assume that most ISPs will shape the downstream bandwidth 
upstream of the DSLAM (if just to avoid having a DDOS against one user taking 
down the whole DSLAM). In my case my ISP even shapes the upstream, which is 
somewhat more puzzling. It looks like a cool way to deal with variable sync 
(either after a re-sync due to say DLM action or due to SRA) so how about 
polishing this a bit and including this as pure informational line in the log? 


*) if this is to be made automatic by say allowing to scrape bandwidth from the 
modem we would need additional setting for setting the shaper percentage. I 
wonder whether all of this is worth it though, given that the number of users 
running sqm on devices in control of the dsl-modem is going to be miniscule, no?

> 
> It fails to work if the ISP does rate banding (BT 20CN does this, BT 21CN 
> doesn’t) where downstream is limited to a rate below downstream sync rate.  
> I guess a lookup table could be implemented.

I predict that a lookup table is going to be constantly out of date, 
especially since at least my ISP is a moving target in both the shaper settings 
as well as the actual overheads (on the plus side they started to send the 
applicable net bandwidth as part of the pppoe negotiations (but failed to 
document how those rates are actually to be interpreted ;) win some loose 
some)). 


Final thought, how about just using this on the luci side to give hints about 
the sync bandwidth in the GUI (like displaying the value of either sync for 
xdsl or the speed for ethernet devices (speed in ethtool parlance, so 10Mb/s, 
100Mb/s, ...)) that will not be as smooth as your solution, but should also be 
more robust against doing the wrmg thing automatically? Or am I 
overcomplicating things again.

Final final thought ;) since lantig_dsl.sh is quite openwrt specific, maybe we 
should do the automatic mode inside of the equally openwrt specific 
/usr/lib/sqm/run instead of in start-sqm that will might also be executed on 
other platforms?


Best Regards
Sebastian

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

___
Cerowrt-devel mailing list

Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies

[dpr...@deepplum.com]

good rant!
 
-Original Message-
From: "Dave Taht" 
Sent: Tuesday, June 19, 2018 3:33pm
To: "dpr...@deepplum.com" 
Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" 
Subject: Re: Invisibility of bufferbloat and its remedies



Well, I ranted: http://blog.cerowrt.org/post/net_neutrality_isps/

I am thinking a string of shorter pieces aimed directly at customers,
reviewers, politicians, etc might do a bit more good than the
gargantuan things jim tends to do.

On Mon, Jun 18, 2018 at 6:46 PM, Dave Taht  wrote:
> I will be in D.C., presenting https://www.cs.kau.se/tohojo/cake/ - next week.
>
> If there are people to see, asses to kick or kiss, I'm up for it, let
> me know. Presently I just plan to give my talk and get the heck out of
> dodge.
>
> One of cake's "minor" features is the *perfect* defeat of the htb
> based shaper in cable modems. If you know the set-rate on the modem,
> you
> just set it to the same thing and get vastly superior performance to
> docsis 3.1, pie, or the sqm-scripts.
>
> On Mon, Jun 18, 2018 at 3:43 PM, dpr...@deepplum.com
>  wrote:
>> I have been one of the most prominent advocates of network neutrality. I'm
>> constantly informing my friends and the press about "buffering" not being
>> related to neutrality at all.
>>
>>
>>
>> I think that's the best we can do.
>>
>>
>>
>> Packet neutrality is actually a key part of the Internet's design, pushing
>> control mechanisms to the edge, with a minimum of "intelligence" in the
>> routers/switches/gateways. In particular, "content-based" and
>> "endpoint-address-based" targeted throttling was never how the Internet
>> Protocol layer was supposed to work. That's a fundamental result of the
>> "end-to-end argument" applied to congestion management. I've spent a lot of
>> time on that issue technically. The original discussions going back before
>> Van Jacobson's early work, up to RED and ECN, all are based on providing
>> congestion signalling sufficient to cause endpoints competing for resources
>> to adapt their behavior cooperatively in real time, while maintaining
>> minimal latency under load.
>>
>>
>>
>> Latency under load is the crucial metric across the entire IP layer,
>> endpoints and routers. It's clear that minimizing latency under load has to
>> be achieved by avoiding buffering insite the network, moving it to the
>> source (and destination).
>>
>>
>>
>> I've given this lecture to policy people a lot. In fact, deliberate creation
>> of "bloat" is a technical strategy that has been used in the past to destroy
>> VoIP and other real-time communicaitons. Microsoft was caught doing it
>> decades ago, as were some other conflicted communicaitons providers. They
>> could selectively delay small packets using DPI, while letting FTPs get full
>> speed. That's one of the reasons we coined the idea of Network Neutrality.
>>
>>
>>
>> But radical right wingers of the sort that blossom in the paranoid world of
>> the dark net started arguing that the routers should have political freedom
>> to do whatever they damn well pleased with packets, because routers are
>> people just like corporations, and a "free market" is the solution to
>> everything.
>>
>>
>>
>> Well, technically, the Internet doesn't work if their is not some mechanism
>> for eliminiating lag under load by eliminating queueing delay in bottleneck
>> nodes.
>>
>>
>>
>> That's ultimately what Network Neutrality is about. There's a lot of other
>> crap being pushed by folks who pile on to the Network Neutrality discussion.
>> People want to "fix prices" for example, arguing that profits are bad. Those
>> guys are not the problem.
>>
>>
>>
>> The problem is that the vertically integrated monopolists want to claim that
>> the Internet should be subject to Deep Packet Inspection at every router,
>> designed to charge rents based on content of the packets and who is the
>> original sender or destination of the packet - that is, charging Netflix or
>> NBC Universal packets nothing, and charging IPFS packets 100x as much.
>>
>>
>>
>> So, no, the Network Neutrality people are NOT the problem with Bufferbloat.
>>
>>
>>
>> Comcast, on the other hand, has been slow-rolling DOCSIS 3.0, because their
>> customers on DOCSIS 2.0 are just ordering faster service tiers to overcome
>> the Bufferbloat in their DOCSIS 2 CMTS's.
>>
>> -Original Message-
&

Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its remedies

[dpr...@deepplum.com]

No doubt.
 
However, sometimes one can get powerful economic forces to  support good ideas.
 
The entire telecom industry was going after the Internet as a concept fiercely 
in the days of "dialup" Internet access. Trying to get the government to allow 
them to price it out of existence, trying to argue that ISDN couldn't be 
deployed, trying to argue that "selective content" (AOL) was better than the 
dangerous open Internet full of kiddy porn and drug cartels, whereas Ma Bell et 
al. would deliver clean and wholesome content only, if the government would 
just allow them to build the National Inofmration Superhighway the way it 
"should be engineered".
 
Yet, the Internet community routed around all of this, by showing hugely 
valuable new ideas that were available instantly, and a vibrant ecosystem of 
innovators working for users, not for the big companies.
 
It's still reasonable to continute that path.  But it is worth remembering that 
when Venture Capital joined in, things started to go awry. @Home (done by Milo 
Medin - funded by Kleiner Perkins, now at Google) was conceived as a closed, 
walled garden, instituting "web caching" that was supposedly "good for users", 
whie at the same time breaking the WWW protocols needed for evolution of the 
Internet, and instituting systematic port blocking that prevented anyone from 
creating servers.
 
But Medin and Kleiner were failures, not getting that openness was at the core 
of the Internet.
 
-Original Message-
From: "Jonathan Morton" 
Sent: Monday, June 18, 2018 7:17pm
To: "dpr...@deepplum.com" 
Cc: "Dave Taht" , cerowrt-devel@lists.bufferbloat.net, 
"bloat" 
Subject: Re: [Bloat] Invisibility of bufferbloat and its remedies



> On 19 Jun, 2018, at 1:43 am, dpr...@deepplum.com wrote:
> 
> So, no, the Network Neutrality people are NOT the problem with Bufferbloat.

No, but I think it's fair to point towards corporate greed and political 
ignorance as common causes of both problems.

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies

[dpr...@deepplum.com]

I have been one of the most prominent advocates of network neutrality. I'm 
constantly informing my friends and the press about "buffering" not being 
related to neutrality at all.
 
I think that's the best we can do.
 
Packet neutrality is actually a key part of the Internet's design, pushing 
control mechanisms to the edge, with a minimum of "intelligence" in the 
routers/switches/gateways. In particular, "content-based" and 
"endpoint-address-based" targeted throttling was never how the Internet 
Protocol layer was supposed to work. That's a fundamental result of the 
"end-to-end argument" applied to congestion management. I've spent a lot of 
time on that issue technically. The original discussions going back before Van 
Jacobson's early work, up to RED and ECN, all are based on providing congestion 
signalling sufficient to cause endpoints competing for resources to adapt their 
behavior cooperatively in real time, while maintaining minimal latency under 
load.
 
Latency under load is the crucial metric across the entire IP layer, endpoints 
and routers. It's clear that minimizing latency under load has to be achieved 
by avoiding buffering insite the network, moving it to the source (and 
destination).
 
I've given this lecture to policy people a lot. In fact, deliberate creation of 
"bloat" is a technical strategy that has been used in the past to destroy VoIP 
and other real-time communicaitons. Microsoft was caught doing it decades ago, 
as were some other conflicted communicaitons providers. They could selectively 
delay small packets using DPI, while letting FTPs get full speed. That's one of 
the reasons we coined the idea of Network Neutrality.
 
But radical right wingers of the sort that blossom in the paranoid world of the 
dark net started arguing that the routers should have political freedom to do 
whatever they damn well pleased with packets, because routers are people just 
like corporations, and a "free market" is the solution to everything.
 
Well, technically, the Internet doesn't work if their is not some mechanism for 
eliminiating lag under load by eliminating queueing delay in bottleneck nodes.
 
That's ultimately what Network Neutrality is about.  There's a lot of other 
crap being pushed by folks who pile on to the Network Neutrality discussion. 
People want to "fix prices" for example, arguing that profits are bad. Those 
guys are not the problem.
 
The problem is that the vertically integrated monopolists want to claim that 
the Internet should be subject to Deep Packet Inspection at every router, 
designed to charge rents based on content of the packets and who is the 
original sender or destination of the packet - that is, charging Netflix or NBC 
Universal packets nothing, and charging IPFS packets 100x as much.
 
So, no, the Network Neutrality people are NOT the problem with Bufferbloat.
 
Comcast, on the other hand, has been slow-rolling DOCSIS 3.0, because their 
customers on DOCSIS 2.0 are just ordering faster service tiers to overcome the 
Bufferbloat in their DOCSIS 2 CMTS's.
-Original Message-
From: "Dave Taht" 
Sent: Monday, June 18, 2018 3:07pm
To: "dpr...@deepplum.com" 
Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" 
Subject: Re: Invisibility of bufferbloat and its remedies



On Mon, Jun 18, 2018 at 9:26 AM, dpr...@deepplum.com
 wrote:
> https://www.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffering/
>
> It's distressing how little the tech press understands the real problem.

Yea, that one is pretty sad.

It still remains a field of active academic research:

https://scholar.google.com/scholar?as_ylo=2018=bufferbloat=en_sdt=0,5

>
> Of course, cable companies like Charter and ATT who have mostly DOCSIS 2 gear 
> deployed can't admit to their plant being bloat-causing.
>
> In fact it protects their cable business against cord cutters.

Lacking competition in general, doesn't help.

What I am actually more frustrated about is the network neutrality
advocates A) conflating "buffering" with malfeasance, rather than a
technical problem
and B) Using politics rather than technology to attempt to achieve
their goals. If *only* a few prominent members of that side of affairs
"got" that some better technology, deployed, might solve some of their
problems and make the internet better for everyone, we'd make more
progress.

fq_codel is a uniquely "american" algorithm, in that it gives the
"little guy" a little boost until it achieves parity with everyone
else.

>
> And the solution is needed in the CMTS once neighbors all start becoming 
> heavier users, because it is a shared buffering pool with no fairness or 
> bloat protection.

My principle observation is that with the changes in traffic patterns
in the last decade, and the predominance of application-rate limited

[Cerowrt-devel] Invisibility of bufferbloat and its remedies

[dpr...@deepplum.com]

https://www.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffering/

It's distressing how little the tech press understands the real problem.

Of course, cable companies like Charter and ATT who have mostly DOCSIS 2 gear 
deployed can't admit to their plant being bloat-causing.

In fact it protects their cable business against cord cutters.

And the solution is needed in the CMTS once neighbors all start becoming 
heavier users, because it is a shared buffering pool with no fairness or bloat 
protection.

Still, routers with queue management that reduce bloat would help a lot, if 
"buffering" is seen frequently under load.

So why isn't anyone talking about this problem after at least a decade of 
knowing it, and knowing how to fix it?

I blame IETF members, individually and collectively. If ietf exists for any 
reason other than as a boondoggle for world travel, it's for resolving issues 
like this one.

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] spacebee

[dpr...@deepplum.com]

To me that is analogous to the idea that since ancient TV sets would show weird 
ghosts when various kinds of radio transmitters were placed nearby (or even be 
disturbed by power-line noise) that the entire effort and rulemaking of the FCC 
should be forever aimed at protecting those TV sets, because someone's 
grandmother somewhere might still own one.
 
It's a technologically backwards idea. It's the kind of idea that made it next 
to impossible to legalize WiFi [I know, I was there]. Only a very key person 
(named M. Marcus, now retired from FCC OET, and a friend) was able to enable 
the use of WiFi technologies in the ISM bands. Otherwise, the idea that all 
current poorly scalable systems ought to be allowed to "block" new technologies 
takes over.
 
All I can say is that if you really think about sharing orbital space in a 
scalable way, there is a lot more "space" available. Which is why I suggested 
"rules of the road" that operate in everyone's interest and privilege no one 
use over another are almost certainly feasible. As satellites get more capable 
(smaller, lighter, more maneuverable, as they follow the equivalent of Moore's 
Law for space) avoidance becomes feasible, *especially if all satellites can 
coordinate via low energy networking protocols*.
 
I know all the scare stories. Planes will fall out of the sky if someone 
accidentally uses a WiFi device or cellphone on airplanes. The Internet will be 
inhabited only by criminals. Encryption is something no one with "nothing to 
hide" needs to use.
 
Please. Think harder. Become an expert on space technology, etc. Not just 
someone who "knowledgably repeats lines from news media articles" as so many do.
 
My point is that while it may be that *geosynchronous equatorial orbit* is very 
tightly occupied, most MEO and LEO space is not densely occupied at all.
-Original Message-
From: "Christopher Robin" <phe...@gmail.com>
Sent: Monday, March 12, 2018 1:34pm
To: "dpr...@deepplum.com" <dpr...@deepplum.com>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] spacebee



The portion of space with usable orbital paths is much, much smaller. One rogue 
rocket with a poor/flawed understanding of that could endanger several other 
satellites. Many systems already in orbit lack the redundancy to handle a major 
collision. And any collision in orbit could ruin the usability of a much larger 
section of space. 


On Mon, Mar 12, 2018 at 1:18 PM, [ dpr...@deepplum.com ]( 
mailto:dpr...@deepplum.com ) <[ dpr...@deepplum.com ]( 
mailto:dpr...@deepplum.com )> wrote:

Well, that may be the case, but it's a non-scalable and highly corruptible 
system. IMO it's probably unnecesary, too. Space is actually quite big.


 
-Original Message-
From: "Jim Gettys" <[ j...@freedesktop.org ]( mailto:j...@freedesktop.org )>
Sent: Monday, March 12, 2018 12:26pm
To: "Dave Taht" <[ dave.t...@gmail.com ]( mailto:dave.t...@gmail.com )>
Cc: [ cerowrt-devel@lists.bufferbloat.net ]( 
mailto:cerowrt-devel@lists.bufferbloat.net )
Subject: Re: [Cerowrt-devel] spacebee




I do believe that the international space treaties require our government to 
control all launches.
Launching satellites without permission is a big no-no.
Note that according to the article, it is collision risk, rather than radio 
radiation, that is the issue here.
Jim


On Mon, Mar 12, 2018 at 12:13 AM, Dave Taht <[ dave.t...@gmail.com ]( 
mailto:dave.t...@gmail.com )> wrote:
This is awesome. The FCC (whic still doesn't "get" spread spectrum
 radio) just discovered it doesn't have authority over the airwaves of
 the whole planet.

[ 
https://spectrum.ieee.org/tech-talk/aerospace/satellites/fcc-accuses-stealthy-startup-of-launching-rogue-satellites
 ]( 
https://spectrum.ieee.org/tech-talk/aerospace/satellites/fcc-accuses-stealthy-startup-of-launching-rogue-satellites
 )

 --

 Dave Täht
 CEO, TekLibre, LLC
[ http://www.teklibre.com ]( http://www.teklibre.com )
 Tel: [ 1-669-226-2619 ]( tel:1-669-226-2619 )
 ___
 Cerowrt-devel mailing list
[ Cerowrt-devel@lists.bufferbloat.net ]( 
mailto:Cerowrt-devel@lists.bufferbloat.net )
[ https://lists.bufferbloat.net/listinfo/cerowrt-devel ]( 
https://lists.bufferbloat.net/listinfo/cerowrt-devel )

___
 Cerowrt-devel mailing list
[ Cerowrt-devel@lists.bufferbloat.net ]( 
mailto:Cerowrt-devel@lists.bufferbloat.net )
[ https://lists.bufferbloat.net/listinfo/cerowrt-devel ]( 
https://lists.bufferbloat.net/listinfo/cerowrt-devel )

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] spacebee

[dpr...@deepplum.com]

Well, that may be the case, but it's a non-scalable and highly corruptible 
system. IMO it's probably unnecesary, too. Space is actually quite big.
 
-Original Message-
From: "Jim Gettys" 
Sent: Monday, March 12, 2018 12:26pm
To: "Dave Taht" 
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] spacebee




I do believe that the international space treaties require our government to 
control all launches.
Launching satellites without permission is a big no-no.
Note that according to the article, it is collision risk, rather than radio 
radiation, that is the issue here.
Jim


On Mon, Mar 12, 2018 at 12:13 AM, Dave Taht <[ dave.t...@gmail.com ]( 
mailto:dave.t...@gmail.com )> wrote:
This is awesome. The FCC (whic still doesn't "get" spread spectrum
 radio) just discovered it doesn't have authority over the airwaves of
 the whole planet.

[ 
https://spectrum.ieee.org/tech-talk/aerospace/satellites/fcc-accuses-stealthy-startup-of-launching-rogue-satellites
 ]( 
https://spectrum.ieee.org/tech-talk/aerospace/satellites/fcc-accuses-stealthy-startup-of-launching-rogue-satellites
 )

 --

 Dave Täht
 CEO, TekLibre, LLC
[ http://www.teklibre.com ]( http://www.teklibre.com )
 Tel: [ 1-669-226-2619 ]( tel:1-669-226-2619 )
 ___
 Cerowrt-devel mailing list
[ Cerowrt-devel@lists.bufferbloat.net ]( 
mailto:Cerowrt-devel@lists.bufferbloat.net )
[ https://lists.bufferbloat.net/listinfo/cerowrt-devel ]( 
https://lists.bufferbloat.net/listinfo/cerowrt-devel )
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] spacebee

[dpr...@deepplum.com]

 
This is fascinating. Could it be that the idea of "open networks of satellites" 
are going to start to play the role of WiFi or UWB? Scalable sharing of orbital 
space, using a simple cooperative protocol? In other words, the first step 
toward what Vint Cerf championed as the "Interplanetary Internet?
 
 
 
If so, that explains why the FCC id doing the bidding of its masters. Sure, we 
need a few rules of the road to manage space orbits, etc. That's in 
*everyone's* public interest.
 
 
 
But do we need the rules to be set by a fully captured regulatory mechanism in 
the pockets of monopoly capital?
 
 
 
I wrote this comment to another mailing list. Thought you might find it 
interesing here as well. (This reflects very deep personal experience with 
building scalable decentralized systems for most of my life, plus encounters 
with the FCC around getting UWB authorized - it was defenestrated in the form 
that they authorized it - and my experiences with the "be very afraid" camp 
that informs the FCC's idea that SDR is not to be allowed, ever, in products 
certified for sale in the US to consumers). It's remarkable how the idea that 
"we need rules of the road" gets perverted into "the US and its corporate 
owners must have power over", esp. in the FCC.
 
---
 
One should ask, why hasn't NASA stepped in to facilitate discussion of orbital 
rules of the road? Preferably the minimum necessary rules, allowing the most 
flexibility to innovate and create value.
 
 
 
And one should also ask, one whose behalf is FCC making these choices?
 
 
 
Space, in theory, belongs to all of us. Not governments defined by national 
boundaries, not the UN, ... it *belongs* to us, just as the Sea does.
 
 
 
It's helpful to have rules (for example, the WiFi rules which extend Part 15's 
"accept all interference and don't deliberately interfere" to a concrete - 
listen for energy before you transmit, and transmit using a power and 
modulation that has the least impact on others. Bran Ferren called this the 
"Golden Rule". The law of the sea is similar.
 
 
 
One can ask whether the FCC has any legitimate constitutional mandate over 
space at all. Maybe that should be taken to the (sadly plutocratic) Supreme 
Court, or even better, a true judicial court that incorporates the interests 
and fairness to all of the planet?
 
 
 
We should remember that if Swarm launched and operated its network of 
satellites from the middle of the ocean (remember Pirate Radio Stations in the 
UK beyond the coastal zone), the US FCC could not touch them. Arguably, there's 
no one who could legally touch them.
 
 
 
That said, we need rules of the road, like we do for drones. But they should 
not be written by those who stand to lose their privileges.
 
 
 ___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] anyone fiddlng with these?

[dpr...@deepplum.com]

This is one of things that is happening. Question is what would be the right 
approach?  Mozilla also seems to be hacking away with little architectural 
thinking. Under the theory that you don't need a theory, just "good code".

What could go wrong?

How did we get Spectre in every processor implementation? Answer: processor 
architects all copied a flawed concept that speculation can easily undo 
observables. But security is often about exfiltration, not just "getting into 
kernel mode".

Where did the operational architecture for these InterNOT of Things devices 
come from? Band aid thinking. Patch on patch.

-Original Message-
From: "Dave Taht" 
Sent: Wed, Feb 14, 2018 at 1:15 am
To: cerowrt-devel@lists.bufferbloat.net
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: [Cerowrt-devel] anyone fiddlng with these?

An esp32 coupled with an arm based 802.14 mcu, or an lte chip...

"With one line of code you'll be securely sending messages to the web."

what could go wrong?"

https://www.particle.io/mesh

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] aarch64 exploit POC

[dpr...@deepplum.com]

Even the Intel meltdown cannot reach between VMs that use hardware virtual 
memory.

Relax, Dave.

The cloud now mostly uses hardware VMs. AWS old Xen instances, and containers 
are subject to bad meltdown  cloud attacks across containers.

Sad about ARM, but ARM servers are pretty rare at this time.

Attacking a PC to expose kernel data via Meltdown is fixed in Linux now. And a 
victim domain has to execute attacker chosen code and data to be Spectre 
vulnerable. So avoid running things as root or letting viruses run in protected 
domains.

It helps to try to figure out exactly what exploits can do. Broad generalities 
are insufficient.

It really bugs me that compiler writers are thinking that they are the solution.

It's a lot easier to fix Spectre in microcode, and Meltdown in the OS paging 
maps.
-Original
From: "Dave Taht" 
Sent: Sun, Jan 7, 2018 at 11:46 am
To: "Outback Dingo" 
Cc: "Outback Dingo" , 
cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] aarch64 exploit POC

On Sun, Jan 7, 2018 at 8:21 AM, Outback Dingo  wrote:
> yes but i would think you would post it to the LEDE / OpenWRT lists also

I'm not reading that email account of mine at the moment, and I'd hope
folk over there are already all over this.

I only logged in long enough to send out a happy new year to everyone.
I was prepping to spend a few days
finishing up the netem patches and maybe trying to submit cake again
before the submission window closed, and then I made the mistake of
inferring what the KPTI patches actually meant, and then this all
happened.

I'd like my vacation back, please.

> On Sun, Jan 7, 2018 at 11:10 AM, Dave Taht  wrote:
>> On Sun, Jan 7, 2018 at 7:47 AM, Outback Dingo  wrote:
>>> OH hell...  notifying all my "cohorts".. thanks for the heads up
>>
>> Then go drinking.
>>
>> Aside from x86 arches (anyone have word on the x86 chip in the
>> pcengines?), it looks like the mips chips simply were not advanced
>> enough to have this level of speculation and out of order behavior.
>>
>> The turris omnia and a few other high end arm chips in this part of
>> the embedded router space are also vulnerable (I'm hoping that the
>> lede folk can compile a list) - but - if you can execute *any*
>> malicious code as root on embedded boxes - which is usually the case -
>> you've already won.
>>
>> The Mill, Itanium, MIPs, and older arms are ok. There are huge lists
>> being assembled on wikipedia, reddit, and elsewhere.
>>
>> My own terror is primarily for stuff in the cloud. There IS a vendor
>> renting time on bare metal in-expensively, which I'm considering.
>>
>> (example: https://www.packet.net/bare-metal/servers/type-2a/)
>>
>> Ironically all the bufferbloat.net services used to run on bare metal,
>> until the competing lower costs of the cloud knocked isc.org out of
>> the business.
>>
>>
>>
>>>
>>> On Sun, Jan 7, 2018 at 10:15 AM, Dave Taht  wrote:
 https://plus.google.com/+KristianK%C3%B6hntopp/posts/6CduVXSy6Kd

 There comes a time after coping with security holes nonstop for 5 days
 straight, when it is best to log off the internet entirely, stop
 thinking, drink lots of rum, and go surfing.

 Today is that day, for me.

 --

 Dave Täht
 CEO, TekLibre, LLC
 http://www.teklibre.com
 Tel: 1-669-226-2619
 ___
 Cerowrt-devel mailing list
 Cerowrt-devel@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>>
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Spectre and EBPF JIT

[dpr...@deepplum.com]

One of the most troubling "overreactions" is due to the fact that the POC by 
Google Project Zero describes an attack on the hypervisor host memory under KVM.
In fine print, and not very explicitly in the Project Zero description, is that 
the version of KVM that was hacked was dependent on the hypervisor being mapped 
into the linear address space of the guest kernel.
In a hypervisor that uses VMX extensions, the EPT during guest execution 
doesn't even provide addressability to the hypervisor code and data. (I haven't 
inspected KVM's accelerated mode, but I can't see why it would have the EPT map 
non-guest memory. I know VMWare does not.)
 
This is validated by a posting from QEMU re KVM, [ 
https://www.qemu.org/2018/01/04/spectre/ ]( 
https://www.qemu.org/2018/01/04/spectre/ ) , again a little hard to understand 
if you don't know how VMX and EPT's work.
 
What this means is that older cloud VMs based on techniques used in 
paravirtualization (Xen, ancient QEMU, older VMware) may be susceptible to 
accessing hypervisor state via Spectre v1.
 
But newer so-called hardware-accelerated VMs based on VMX extensions and using 
the EPT are isolated to a much larger extent, making Spectre v1 pretty useless.
 
Thus, the "overreaction" is that ALL VM's are problematic.  This is very far 
from true. Hardware-accelerated VM's hypervisors are not vulnerable to 
Meltdown, Spectre v2, and probably not Spectre v1.
 
Of course, *within* a particular VM, the guest kernel and other processes are 
vulnerable. But there is no inter-VM path that has been demonstrated, nor do 
any of the discussions explain any means for using speculative execution and 
branch misprediction between VMs running under different EPT's.
 
So for the cloud, and also for NVF's that are run on accelerated HVM's, the 
problem is either non-existent or yet to be discovered.
 
Of course the "press" wants everyone to be superafraid, so if they can say "KVM 
is affected" that causes the mob to start running for the exits!
 
Summary: hardware virtualization appears to be a pragmatic form of isolation 
that works. And thus many cloud providers are fine.
 
 
 
-Original Message-
From: "Jonathan Morton" <chromati...@gmail.com>
Sent: Friday, January 5, 2018 9:07am
To: "Dave Taht" <dave.t...@gmail.com>
Cc: "dpr...@deepplum.com" <dpr...@deepplum.com>, "Joel Wirāmu Pauling" 
<j...@aenertia.net>, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Spectre and EBPF JIT



> On 5 Jan, 2018, at 6:53 am, Dave Taht <dave.t...@gmail.com> wrote:
> 
> It took me a long while to digest that one. The branch predictor
> analysis of haswell was easiest to understand (and AMD claims to have
> an AI based one), and perhaps scrambling that at random intervals
> would help? (this stuff is now way above my pay grade)

Software mitigations for all three attacks have been developed during the 
"responsible disclosure" period.

Spectre v1: adding an LFENCE instruction (memory load fence) to JIT code 
performing a bounds-checked array read. This is basically a userspace fix for a 
userspace attack. Firefox just got this, Chrome undoubtedly will too, if it 
hasn't already.

Spectre v2: three different mitigations are appropriate for different families 
of CPU:

 https://lkml.org/lkml/2018/1/4/742

On AMD CPUs, the small risk actually existing (because AMD's BTB is much less 
prone to poisoning than Intel's) is erased by adding LFENCE to privileged 
indirect branches. This has only a very small cost.

On Intel CPUs until Broadwell inclusive (and Silvermont onwards), a "retpoline" 
structure is necessary and sufficient. This has a bigger cost than LFENCE and 
is pretty ugly to look at, but it's still relatively minor.

On Skylake, Kaby Lake and Coffee Lake, something more exotic is required - I 
think it involves temporarily disabling the BTB during privileged indirect 
branches. That's *really* ugly, and involves tweaking poorly-documented MSRs.

Something similar in nature to the above should also work for affected ARM 
cores.

Meltdown: nothing is required for AMD CPUs. Unmapping the privileged addresses 
when returning to userspace is sufficient for Intel, but incurs a big 
performance overhead for syscalls. The same is likely true for any other 
affected CPUs.

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Spectre and EBPF JIT

[dpr...@deepplum.com]

As I continue to study the Spectre bug, I read the Project Zero post about 
POC's they developed for Spectre.
 
[ 
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
 ]( 
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
 )
 
(the Meltdown and Spectre papers, linked from that page are far better at 
explaining the mechanics of the issue. Read Meltdown first, it's simpler.).
 
It was very enlightening to see that one exploit used the "in-kernel eBPF JIT 
interpreter". This one also looks very practical to exploit, and it is "network 
related" so of some interest here.  The Project Zero post doesn't describe the 
exploit itself, but reading the Spectre paper gives one context on how Spectre 
works.
 
Unlike Meltdown, Spectre really depends on the attacker being able to force 
certain instruction sequences to get executed in some address space, such that 
the effect can be observed in another address space where the attacker's 
observer resides.
 
What this means is that to read data from the kernel, Spectre needs to force a 
specific code sequence to be executed, with a branch mispredicted, *in the 
kernel*.
 
That's where the eBPF JIT comes into play, apparently. Because the eBPF JIT 
allows *kernel code* to be constructed from the attackers userspace code. 
Hmmm... sounds like the user can change the kernel binary code and get it 
executed!
 
So this is a relatively practical thing to do, and it gives full access to 
anything in the kernel address space, from a userspace program.
 
Now it's easy to disable the JIT feature. Just a packet processing performance 
hit.
 
But I bet designing the JIT so it won't generate Spectre-exploitable code would 
be tricky indeed.
 
Especially since the Spectre-exploitable code is highly processor architecture 
specific, unlike Meltdown, which appears to be Intel-only.___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

[dpr...@deepplum.com]

I don't disagree about using containers being useful as one of many security 
mechanisms. They are useful against certain attack vectors, but depend on two 
things: 1) kernel correctness, and 2) putting all functionality in separate 
userspace processes to satisfy the "principle of least privilege".
 
-Original Message-
From: "Dave Taht" <dave.t...@gmail.com>
Sent: Thursday, January 4, 2018 5:04pm
To: "dpr...@deepplum.com" <dpr...@deepplum.com>
Cc: "Joel Wirāmu Pauling" <j...@aenertia.net>, "Jonathan Morton" 
<chromati...@gmail.com>, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than 
x86?



On Thu, Jan 4, 2018 at 2:02 PM, dpr...@deepplum.com <dpr...@deepplum.com> wrote:
> Containers and kernel namespaces, and so forth are MEANINGLESS against the
> Meltdown and Sceptre problems. It's a hardware bug that lets any userspace
> process access anything the kernel can address.

Just to be clear, I was merely agreeing with joel that containers had
matured enough to be potentially usuable for some level of process
isolation and firewalling, not that it applied to coping with MeltRe.
>
>
>
> -Original Message-
> From: "Joel Wirāmu Pauling" <j...@aenertia.net>
> Sent: Thursday, January 4, 2018 4:52pm
> To: "Dave Taht" <dave.t...@gmail.com>
> Cc: "Jonathan Morton" <chromati...@gmail.com>,
> cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches
> than x86?
>
> Well as I've argued before Lede ideally should be using to Kernel Namespaces
> (poor mans containers) for at a minimum the firewall and per-interface
> routing instances.
>
> The stuff I am running at home is mostly on cheap Atom board, so it's a
> matter of squeezing out unneeded cruft on the platform. Also I don't want to
> be admining centos/rhel servers at home.
>
> On 5 January 2018 at 10:47, Dave Taht <dave.t...@gmail.com> wrote:
>>
>> On Thu, Jan 4, 2018 at 1:44 PM, Joel Wirāmu Pauling <j...@aenertia.net>
>> wrote:
>> >
>> >
>> > On 5 January 2018 at 01:09, Jonathan Morton <chromati...@gmail.com>
>> > wrote:
>> >>
>> >>
>> >>
>> >> I don't think we need to worry about it too much in a router context.
>> >> Virtual server folks, OTOH...
>> >>
>> >> - Jonathan Morton
>> >>
>> > Disagree - The Router is pretty much synonymous with NFV
>> >
>> > ; I run my lede instances at home on hypervisors - and this is
>> > definitely
>> > the norm in Datacentres now. We need to work through this quite
>> > carefully.
>>
>> Yes, the NFV case is serious and what I concluded we had most to worry
>> about - before starting to worry about the lower end router chips
>> themselves. But I wasn't aware that people were actually trying to run
>> lede in that, I'd kind of expected
>> a more server-like distro to be used there. Why lede in a NFV? Ease of
>> configuration? Reduced attack surface? (hah)
>>
>> The only x86 chip I use (aside from simulations) is the AMD one in the
>> apu2, which I don't know enough about as per speculation...
>>
>> --
>>
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

[dpr...@deepplum.com]

I don't disagree that anyone who can run code in the hypervisor itself can 
attack the guest instances.
 
But that has nothing to do with KALSR or Meltdown or Sceptre. That's just bad 
security design - the rule is "the principle of least privilege", which comes 
from the 1970's work on secure operating systems.
 
I should point out here that I was one of the researchers that helped develop 
the original multi-level security systems then. Those "colored books" come from 
us.
 
-Original Message-
From: "Joel Wirāmu Pauling" <j...@aenertia.net>
Sent: Thursday, January 4, 2018 5:00pm
To: "dpr...@deepplum.com" <dpr...@deepplum.com>
Cc: "Jonathan Morton" <chromati...@gmail.com>, 
cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than 
x86?




SRIOV ports and Vendor NIC optimizations wrt Latencies.


Whilst these heavy hitting NVF appliances tend to be large and span multiple 
compute hosts (and therefore are the only tenannts on those computes) - this 
isn't always the case. 


It's a problem in that if you can get onto the hypervisor even as an 
unprivileged user you can read out guest stores. .... Big Problem. 


On 5 January 2018 at 10:57, [ dpr...@deepplum.com ]( mailto:dpr...@deepplum.com 
) <[ dpr...@deepplum.com ]( mailto:dpr...@deepplum.com )> wrote:

Hmm... protection datacentres tend to require lower latencies than can be 
achieved running on hypervisors.
 
Which doesn't mean that some datacenters don't do that.
 
As far as NFV is concerned, Meltdown only breaks security if a userspace 
application is running on a machine where another user has data running through 
kernel address space. NFV environments don't tend to run NFV in userspace under 
an OS that has kernel data in the page tables that are reachable from CR3.
 
The key issue in Meltdown is that CR3 is not changed between userspace and 
kernelspace. Which means that the memory access pipeline in userspace can use a 
kernelspace address (what Intel calls a "linear" address) without a check that 
the pagetables enable userspace access. The check happens after the speculative 
execution of the memory access.
 
I repeat this, because many pseudo-experts who love to be quoted in the press 
as saying "be afraid, be very afraid" are saying a lot of nonsense about 
Meltdown and Sceptre. It seems to be an echo chamber effect - the papers were 
released yesterday afternoon, but in a rush to get "quoted", all the 
wannabe-quoted people are saying things that are just plain NOT TRUE.
 
 
-Original Message-
From: "Joel Wirāmu Pauling" <[ j...@aenertia.net ]( mailto:j...@aenertia.net )>
Sent: Thursday, January 4, 2018 4:44pm
To: "Jonathan Morton" <[ chromati...@gmail.com ]( mailto:chromati...@gmail.com 
)>
Cc: [ cerowrt-devel@lists.bufferbloat.net ]( 
mailto:cerowrt-devel@lists.bufferbloat.net )
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than 
x86?








On 5 January 2018 at 01:09, Jonathan Morton <[ chromati...@gmail.com ]( 
mailto:chromati...@gmail.com )> wrote:


 I don't think we need to worry about it too much in a router context.  Virtual 
server folks, OTOH...



  - Jonathan Morton



​Disagree - The Router is pretty much synonymous with NFV​ 
​; I run my lede instances at home on hypervisors - and this is definitely the 
norm in Datacentres now. We need to work through this quite carefully. ​___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

[dpr...@deepplum.com]

Containers and kernel namespaces, and so forth are MEANINGLESS against the 
Meltdown and Sceptre problems. It's a hardware bug that lets any userspace 
process access anything the kernel can address.
 
-Original Message-
From: "Joel Wirāmu Pauling" 
Sent: Thursday, January 4, 2018 4:52pm
To: "Dave Taht" 
Cc: "Jonathan Morton" , 
cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than 
x86?




Well as I've argued before Lede ideally should be using to Kernel Namespaces 
(poor mans containers) for at a minimum the firewall and per-interface routing 
instances.


The stuff I am running at home is mostly on cheap Atom board, so it's a matter 
of squeezing out unneeded cruft on the platform. Also I don't want to be 
admining centos/rhel servers at home.


On 5 January 2018 at 10:47, Dave Taht <[ dave.t...@gmail.com ]( 
mailto:dave.t...@gmail.com )> wrote:


On Thu, Jan 4, 2018 at 1:44 PM, Joel Wirāmu Pauling <[ j...@aenertia.net ]( 
mailto:j...@aenertia.net )> wrote:
 >
 >
 > On 5 January 2018 at 01:09, Jonathan Morton <[ chromati...@gmail.com ]( 
 > mailto:chromati...@gmail.com )> wrote:
 >>
 >>
 >>
 >> I don't think we need to worry about it too much in a router context.
 >> Virtual server folks, OTOH...
 >>
 >>  - Jonathan Morton
 >>
 > Disagree - The Router is pretty much synonymous with NFV
 >
 > ; I run my lede instances at home on hypervisors - and this is definitely
 > the norm in Datacentres now. We need to work through this quite carefully.

Yes, the NFV case is serious and what I concluded we had most to worry
 about - before starting to worry about the lower end router chips
 themselves. But I wasn't aware that people were actually trying to run
 lede in that, I'd kind of expected
 a more server-like distro to be used there. Why lede in a NFV? Ease of
 configuration? Reduced attack surface? (hah)

 The only x86 chip I use (aside from simulations) is the AMD one in the
 apu2, which I don't know enough about as per speculation...



 --

 Dave Täht
 CEO, TekLibre, LLC
[ http://www.teklibre.com ]( http://www.teklibre.com )
 Tel: 1-669-226-2619___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than x86?

[dpr...@deepplum.com]

Hmm... protection datacentres tend to require lower latencies than can be 
achieved running on hypervisors.
 
Which doesn't mean that some datacenters don't do that.
 
As far as NFV is concerned, Meltdown only breaks security if a userspace 
application is running on a machine where another user has data running through 
kernel address space. NFV environments don't tend to run NFV in userspace under 
an OS that has kernel data in the page tables that are reachable from CR3.
 
The key issue in Meltdown is that CR3 is not changed between userspace and 
kernelspace. Which means that the memory access pipeline in userspace can use a 
kernelspace address (what Intel calls a "linear" address) without a check that 
the pagetables enable userspace access. The check happens after the speculative 
execution of the memory access.
 
I repeat this, because many pseudo-experts who love to be quoted in the press 
as saying "be afraid, be very afraid" are saying a lot of nonsense about 
Meltdown and Sceptre. It seems to be an echo chamber effect - the papers were 
released yesterday afternoon, but in a rush to get "quoted", all the 
wannabe-quoted people are saying things that are just plain NOT TRUE.
 
 
-Original Message-
From: "Joel Wirāmu Pauling" 
Sent: Thursday, January 4, 2018 4:44pm
To: "Jonathan Morton" 
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] KASLR: Do we have to worry about other arches than 
x86?






On 5 January 2018 at 01:09, Jonathan Morton <[ chromati...@gmail.com ]( 
mailto:chromati...@gmail.com )> wrote:


 I don't think we need to worry about it too much in a router context.  Virtual 
server folks, OTOH...



  - Jonathan Morton



​Disagree - The Router is pretty much synonymous with NFV​ 
​; I run my lede instances at home on hypervisors - and this is definitely the 
norm in Datacentres now. We need to work through this quite carefully. ​___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel