Thinking further on this discussion in the light of having my entire
network out for 48 hours plus my main work machine suffering a drive
failure, I think I have found the hole in our thinking:
Traditionally we have considered the network to be merely a special case of
the Internet. But that is a mistake. The network has management
requirements. The Internetwork does not by definition.
On Mon, Dec 15, 2014 at 2:26 AM, Masataka Ohta <
mohta(_at_)necom830(_dot_)hpcl(_dot_)titech(_dot_)ac(_dot_)jp> wrote:
Joe Touch wrote:
I had thought that part of the meeting would be to address the tension
between these two issues, but I have also since learned it has become
"how do we evolve the Internet to accept whatever middleboxes want to
do" - i.e., precisely the latter of your examples.
That's called "anarchy", and the results only serve to increase entropy.
No. What people want to do with their middleboxen is to control their
NETWORK.
One of the pathologies here is that folk are insisting on a model where
there are no networks, every device is connected to the Internetwork.
Another pathology is that my ISP is selling me an Internet Service but has
the mistaken belief that my machines are part of their network when in fact
I have a home network and I am paying them to provide a pipe to the
Internetwork.
The question of whether ISPs should run middleboxen is completely separate
from the question of whether local networks should run them.
With 80-100 devices in my house I have an absolute requirement for
centralized management. What concerns me is the anarchy on my network in
which any device connected to my network can BRING THE STUPID NETWORK DOWN.
Consider the tools we leave the home user to deal with network issues.
There is no visibility into the local network. None, zilch, zip, nada. The
network analysis tools don't even ship on Windows by default and they
aren't at all useful because there is no model of what the local network
should look like to compare against and identify anomalies.
So when you have a network issue, the first thing you discover is that you
have to download the network debugging tool while the toaster oven is
DoS-ing your network. Which mental midget thought that the network monitor
was less important than the 8th desktop theme? Probably the same mental
midget who thought that the 32 and 64 bit versions of powershell should
have separate permissions and not tell you which is running.
Another somewhat subtle problem with local networking is that there is a
confusion between IP and ethernet. Some local network protocols still use
MAC addresses and broadcast addresses. And this turns the local network
into the loser-network. Because there is really no way to predict whether a
bridge will actually bridge the packets or not.
At the moment, the only way to bring order to my network is to middlebox it
into subnets. Today my home network is an outlier but it won't be for very
long.
I use Windows, Linux and Mac on a daily basis and the network management
tools all suck. It should be possible to bring up a map of the local
network showing all the bridges, the connections between them and the
traffic loads with one click. It should then be possible to drill down and
identify which machines have services running, which machines are talking
to the external Internet, etc. etc. And there should be a replay button
that lets me roll back the past hour or so of network activity just like I
have on my DVR.
Now it would be really easy to write a bunch of JSON Web services that
would enable such a console to be provided. In fact I have been working on
something of the sort.
But there is an architectural step we need to take. I really could not care
less as to what the packet layer data format is. It can be IPv4, IPv6,
RS232, RS485, Infineon, Bluetooth, Telepathic relay, Z-wave or Zigbee.
What I do care about is having them all use the DNS as the name service. If
everything in my local network will check in with the local directory
service to say what it is and to ping it from time to time to say it is
still up, I have a chance of working out what is going on in my network.
It is a really obvious requirement for a network stack. But it is one we
have consistently overlooked because it is not a part of an internetwork
stack.