Re: Time to kill layer 2

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Apr 14, 2016 at 4:23 PM, Brian E Carpenter
<[e-mail]> wrote:
> On 15/04/2016 04:54, Ted Lemon wrote:
>> You should read the homenet naming and service discovery architecture
>> document. :)
>>
>> On Thu, Apr 14, 2016 at 12:54 PM, Christopher Morrow <
>> [e-mail]> wrote:
>>
>>>
>>> On Thu, Apr 14, 2016 at 12:32 PM, Phillip Hallam-Baker <
>>> [e-mail]> wrote:
>>>
>>>> Going to unicast should help. Multicast configuration really doesn't
>>>> work on a network with as many hubs and devices as mine has.
>>>>
>>>
>>> multicast would work, if all the hubs/devices did multicast properly,
>>> right? :)
>
> Really stupid devices do multicast properly because they are genuinely
> transparent to layer 2. The annoying devices are the ones that pretend
> to be layer 2 + layer 3 devices but are actually half-baked layer violation
> devices. (To be specific, I have recently been burned by a layer 2/3 switch
> that does not perform correct MLD snooping. And I agree that you have to be
> in the 1% to diagnose that.)

As a general rule, any time a network device attempts anything
heuristic, it is going to get things wrong. The heuristic becomes a
source of error. Which was why so many of the early NATs were so
comically bad. They would attempt to patch up protocols like FTP, make
a hash of it and break things.

Sure, Homenet might solve some of these problems. But the reason for
my 'screed' is that listening to folk in Buenos Aires, I think a lot
of you are trying to build a network for yourselves and not a network
that works for someone like Jeremy Clarkson.

One of the rather more frustrating recent developments has been an
understanding of 'usability' that comes down to 'don't give the user
any information that might confuse them'. Windows and OSX both suffer
from their own particular flavors of this approach. In networking it
is the hub that is dropping the packets and not saying why or even
mentioning the fact that it did so.


>>> it's not clear that unicast works, if the problem you are trying to solve
>>> is service-discovery... absent some registry of 'services' for your clients
>>> to use, of course (which is the point of the mdns thingy).
>
> It seems to me that doing everything unicast makes life harder for no
> reason. I don't know how we could make the Anima signaling work without
> multicast, but we are restricting it strictly to link-local multicast.

As another general rule, all protocols that rely on superfluous
communication are bad protocols.

Before talking on a network, a device should authenticate. Is the
device going to authenticate with every other device on the network?
Does anyone imagine that to be scalable? I have over a hundred devices
on my network and in ten years time, I think that will be considered
small. If we are serious about IoT then every socket, every
lightswitch is a network device, thats another couple of hundred right
there.

Recourse to multicast is the network equivalent of suck it and see
programming. Instead of having a concept of fault tolerant network
control with failover, every device on the network is constantly
yammering to the network as a whole just to tell people its there.
When people do that, we call in a psychologist.

In process control, networks are much quieter because the plant
managers want to be able to tell why every packet on their network
appeared. Noisy protocols that talk for the sake of talk are severely
frowned on.