Re: [homenet] Homenet market gap analysis...

[Ted Lemon <[e-mail]>]

Tim, it’s pretty clear that in the case of constrained networks, there needs to be subnetting.   Homenet is uniquely positioned to make that possible—if you have a regular router that doesn’t support something like HNCP, there’s no way to make it work.

In the case of a multi-premise homenet, either you have to bond the two homenets together, which we don’t currently support, or you need end-to-end to work, which means IPv6, and you need to make sure that only authorized hosts can talk to devices.

Toke and I have been discussing the endpoint roaming problem.   In L2, it’s all handled by the layer 2, so it’s transparent, which doesn’t necessarily mean that it’s any better than the less-transparent way it would need to be handled at L3.   I think we should do a comparison between these two approaches.

Mapping names to addresses can be done with service discovery; please see the simple homenet naming architecture document for a discussion of this, and also RFC6763.   We will be doing some work on this at hackathon if you want to see it in action.

Node identity can be managed with DNSSD Service Registration Protocol, which allows a host to claim and defend a name using public key cryptography.   Bear in mind that there are privace implications to this, and so it isn’t always the right thing to do.   Your printer should probably do it.   Your phone, perhaps not.   Private service discovery is being seriously discussed in the DNSSD working group.   Because private service discovery necessarily uses public key encryption, unique identifiers aren’t a problem; claiming a unique name remains a problem, but not a very big problem, because the name doesn’t change after pairing.

IoT meshes are out of scope for homenet.   I agree that there are some interesting problems to contemplate when using them. :)


> On Mar 13, 2019, at 6:45 PM, Tim Coote <[e-mail]> wrote:
> 
> Ted
> 
>> On 13 Mar 2019, at 18:35, Ted Lemon <[e-mail]> wrote:
>> 
>> In Bangkok I gave a talk about what Homenet gets right, what new solutions have emerged in the market since homenet started, and what is better about those solutions, as well as what homenet still adds.   I’ve written up a document that discusses this in a bit more depth, and would appreciate feedback.   It’s not very long, and should be a pretty easy read—it would be great if we could start talking about this before the meeting, so that when we get to the meeting we can have an informed discussion and maybe decide on a way forward if that seems warranted.
>> 
>> https://tools.ietf.org/html/draft-lemon-homenet-review-00
>> 
> 
> Some points/questions. Pls excuse my hamfisted articulation/miss an obvious point, I’m no network specialist.
> 
> - IoT isolation for L2: a common scenario is that the IoT network has a vastly different performance profile to other in-home networks. I don’t think that this works well for Flat L2
> - for some IoT scenarios, the scope of a home isn’t one premises, eg wanting to control a camera in one house from a controller in another. There is no general IPv4 solution to this as protocols such as STUN/ICE are too slow, in human reaction time terms, to use to set up the control link.
> - how is an endpoint reconnected if it’s moving about and getting renumbered? Is this done via some naming service?
> - how are human understandable names mapped to addresses, automatically? Is this service discovery?
> - node identity: if a node is moving about and/or has multiple addresses at the same time, how does a human understand that it’s the same thing. For s/w this is quite easy, although non-standard. Is this an application layer concern?
> - a point wrt meshes: although these potentially provide resilience, they can also provide confusion as the end to end service can move up and down over various timescales. I have experienced some very expensive support situations that were caused by (IoT) mesh networks breaking the principle of ‘fail-fast’. In these situations, as the world changes, L2 networks adopt a ’string of pearls’ topology, but do not report the changes. Ultimately there is a network partition, which breaks things in interesting ways from an engineering point of view and confusing ways from the point of view of users.
> 
> I hope that this is useful.
> 
> tc
> 
>