* Re: [Cerowrt-devel] I wish we had a good definition of mesh
2022-03-02 2:47 [Cerowrt-devel] I wish we had a good definition of mesh Dave Taht
@ 2022-03-03 23:34 ` David P. Reed
0 siblings, 0 replies; 2+ messages in thread
From: David P. Reed @ 2022-03-03 23:34 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 5465 bytes --]
I have avoided using the term "mesh networks" for a reason. It's way too broad already. This also goes for "ad hoc networking" (which was supposedly what MANET was about, but the instigators didn't think very clearly about what the possibilities were - they focused on what "tactical warfighters" might use in the field only.)
Getting to the particulars quickly is far better than creating some kind of "umbrella" term that can be distorted and confused. Here's two problems with "mesh" as used by others.
1) it is often assumed that the nodes of a mesh are standardized and all the same. To be this focuses on the wrong problem - it's like talking about 10baseT networks as if they are distinct and necessary. Or 802.11. While I can imagine that in some ways it might be simpler to design a uniformly identical set of mesh hardware, the "layers on top" of such a platform at NOT uniform in their requirements. So why stultify what is only one of many underlying solutions.
2) It is often assumed that the "network is intelligent" unto itself. Often this leads to a design that puts a "control plane" into the mesh. There are reasons to have mesh node *protocols* coordinate, but only those things that are truly necessary. And those can't be predicted at design time, not at all.
That's why this "constellation project" seems to be of limited value. It reminds me of the ARPA BCR crypto based network security project. It was the *sole* investment in network security by ARPA at the time when Vint was the program manager. It wasn't a bad concept (but all the solution space was narrowed to NSA's beliefs at the time that the only crypto that could be used for security was a link layer protection with a sealed black box to which keys had to be periodically distributed. End-to-end security (which required software encryption and much more decentralized key distribution, among other things) was actually *ruled out* by ARPA as valuable. So BBN built the BCR boxes, spec'ed how to install them on, say, the Internet links, and may have even pointed out that inside routers the data was en clair, so this required all routers to be guarded to the level needed to protect the most critical communications. I've never understood deeply why my work and Steve Kent's and Roger Needham's and Mike Schroeder's work on end-to-end security in the context of the TCP protocol and UDP was not supported. Steve and I offered to include a complete solution for TCP that he had done with me involved a little bit, and we were told to stop working on it. (partly for national security reasons, but actually since it offended NSA's rules of thumb).
As a *research* project, learning to use lasers among LEO satellites seems appropriate, but this is NOT proposed as research. It seems like DoD thinks the problem is solved already. I am very sure it is NOT solved. It's like a grand project from the security sector a few years ago where I tried to help - the so-called National Cyber Range and its test platform (hardware and opearting environment). Again, what should have started with R&D, but was instead put out for bid prematurely as if a working system could be built and demonstrated. The idea being proposed by the teams was the idea of using lots of virtual machines in a cloud to simulate any and all government IT uses and any and all attacks. Now Virtual Machines are not real hardware, so simulating seucrity vulnerabilities of real hardware in them is either a bear of a research problem yet to be solved, or you have to define the problems of real life (like Microsoft Windows running on real laptops throughout the world in DoD, Dept of State, and even just the gear in the pentagon) as not existing except to the extent that you can build models inside a cloud.
Anyway, that's a distraction. The USG wastes a hell of a lot of money with these kinds of boondoggles.
Anyway, if you have a bunch of satellites up there with lasers and are willing to plan to throw the first prototype away, you'll get really good results from smart engineers.
I suspect this project will explain why Iridium, the first space "mesh", might want to be viewed as what constitutes a "mesh", and to choose a new name entirely.
My term for what would be far more interesting (except it isn't focused on hardware at all) is a "near earth Internet". That is, a set of protocols and operating methods that don't specify the hardware at all, but which can incorporate in a scalable way a huge variety of hardware on the earth and in LEO and even on non-orbital space vehicles, assuming distances on the order of "light milliseconds" are achieved among the nodes.
But hey, that's what they did at Guifi and Porto. Mix and match and make something that is robustly independent of the underlying hardware.
Instead, yet another boondoggle. Let it be called a "mesh" because that sounds futuristic.
On Tuesday, March 1, 2022 9:47pm, "Dave Taht" <dave.taht@gmail.com> said:
> https://spacenews.com/lockheed-martin-northrop-grumman-york-space-selected-to-build-dods-internet-in-space-constellation/
>
> --
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
[-- Attachment #2: Type: text/html, Size: 8050 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread