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

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2019 14:35:34 -0400

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 <https://tools.ietf.org/html/draft-lemon-homenet-review-00>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Mar 2019 21:46:58 +0100 (CET)

On Wed, 13 Mar 2019, Ted Lemon 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.
>

Thanks for doing this, it's a valuable write-up. I agree with what's 
written in the draft, but I missed some parts that would involve 
DHCPv6-PD. I have done this myself and it's very useful to be able to 
stack several routers deep into the home, for instance for L2 isolation of 
devices (I had a real problem involving Spanning Tree that I wanted to 
solve this way, and it worked well). Doing this with non-HOMENET routers 
expands the number of devices one can support.

I especially agree with the statement on wifi roaming between APs does 
require shared L2, and there has been discussions about this and how to 
solve that, and I think it's a requirement for homenet to become a useful 
solution in that space. This would probably require some kind of tunneling 
or vlan encapsuatlion between homenet devices to be controlled somehow. 
There are routing protocols out there that already do this, can perhaps 
be used as inspiration.

Looking at the kind of devices typically available to people, most of them 
are SoCs with 2 NIC ports, one connected to a WAN port and one to a switch 
that then provides multiple ports. This doesn't lend itself very well to 
arbitrary topologies, but it does lend itself well to creating trees. Here 
the service discovery proxies and turning off firewalls/NAT of HOMENET is 
very useful. I also think it's useful for wired devices to have the L3 
isolation that HOMENET design calls for, but we also need to support L2 
domains across APs (multiple probably, as people also like to have 
isolation between different SSIDs).

There is now work in the IETF on IoT onboarding etc, does HOMENET have 
mechanisms that can be used there or the other way around?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 13 Mar 2019 22:27:25 +0100

Mikael Abrahamsson <[email-masked]> writes:

> require shared L2, and there has been discussions about this and how
> to solve that, and I think it's a requirement for homenet to become a
> useful solution in that space. This would probably require some kind
> of tunneling or vlan encapsuatlion between homenet devices to be
> controlled somehow. There are routing protocols out there that already
> do this, can perhaps be used as inspiration.

You don't actually need encapsulation or VLANs if all access points
participate in the routing protocol. You can just announce routes for
each of the clients' IP addresses on roaming. You'll need some mechanism
for discovering those IP addresses of course; one option is something
like l3roamd[0] (which more or less just sniffs the addresses used by
the client), but others are certainly possible. I remember discussing
other approaches with Juliusz at some point, but I guess none of us ever
got around to implementing something.

Either way, I guess this is something homenet could conceivably specify
a solution for if there was sufficient interest... :)

-Toke

[0] https://github.com/freifunk-gluon/l3roamd

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2019 19:01:33 -0400

I suppose a point to be investigated is that however roaming happens,
unless all packets are flooded to all links, the layer 2 switch always
triggers a routing change, whether at layer 2 or layer 3.

So it might be worth doing an analysis of the pros and cons of L2 versus L3
roaming. I know Dave Täht has looked into doing it at L3 at the host, but
that isn’t practical and is in any case out of scope for homenet. What is
easier if it’s done at L2?  At L3?

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 14 Mar 2019 00:07:07 +0100

> easier if it’s done at L2?  At L3?

Yeah; off the top of my head: getting the address to distribute is
easier at L2 (it's built in to the WiFi handshake), and there's only one
of them; but distributing it (them) once you know it may be easier (or
more efficient) at L3. Assuming you already have a decent layer 3
routing protocol available, of course (which is why it makes sense to
solve it in a homenet context) :)

L3 also has the advantage that it can aggregate lots of host routes into
a covering prefix, so fewer routes when no one is roaming; but when
clients do roam, you mostly have to announce host routes anyway, so in
the worst case we get back to "one route per address"... A longer
analysis would probably be needed to assess performance in the worst
case.

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2019 20:40:12 -0400

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 <[email-masked]> wrote:
> 
> Ted
> 
>> On 13 Mar 2019, at 18:35, Ted Lemon <[email-masked]> wrote:
>> 
>> 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
> 
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2019 18:03:23 -0700

On 3/13/19 11:35 AM, Ted Lemon wrote:
> 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.
>

Thanks, Ted. This is really useful.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Mar 2019 09:09:45 -0400

Thanks for clarifying.   I was trying to answer your questions and didn’t get that you were suggesting changes to the document; now that’s more clear.   Regarding “naming interfaces” versus “naming nodes,” you might want to look at https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ <https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/> which specifically addresses that problem, although it doesn’t say it the way you said it.  :)

> On Mar 14, 2019, at 6:19 AM, Tim Coote <[email-masked]> wrote:
> 
> On 14 Mar 2019, at 00:40, Ted Lemon <[email-masked]> wrote:
> 
> Agreed. I thought that from a market gap analysis, that it was worth bringing out this weakness for existing (L2 based) approaches, otherwise there will be a tendency for readers to assume the best.
> 
> I see. The usecase wasn’t missing, it’s covered by the 'internet to leaf’ + ‘leaf to internet’ scenarios. Again, for the casual reader, I think that it’s worth pointing this out. But it’s your document, of course.
> 
> I was thinking more of ‘pet names’, ie human invented and associated, rather than names used for well-known services, how these propagate on movement to new networks etc (eg I call my dad’s spO2 meter oxydad, no matter where it is or where he is).
> 
> What concerns me about dns based approaches is that dns knows nothing about nodes, only interfaces. That’s mostly ok in an world with ~1 address per node, but it quickly becomes difficult as that constraint is broken. This is certainly an issue in enterprise environments. otoh, in some circumstances, it may be confidential that specific addresses are associated with the same host, or service on a host.
> 
> I did get a suggestion that nodes are better managed using handle.net’s model.
> 
> I’ll read your suggestions. Thanks.
> 
> I was really showing how bad things get. I am concerned that all mesh networks will go the same way, leading to very large support costs. IMO, there’s a tendency for computer based systems to avoid the engineering principle of fail fast (give up early and raise an alarm), which gives an impression that all is well until there’s a catastrophic failure. Even the original Ethernet wiring exhibited this with workarounds for signal deterioration and fallback to lower performance.
> 
> https://tools.ietf.org/html/draft-lemon-homenet-review-00 <https://u8538325.ct.sendgrid.net/wf/click?upn=0nhH4OIYFtatOO7tDf-2BEy9JDHc3W7itZDB6jHoUCcMD5Ni9FWgzk-2FsCXhpoGMY1hFnwsJxISnVc9wOuhy-2BQvhIQyW2DIAvJajgsdEWX4Fo0-3D_y-2BfRiPDFCcVWHl-2FL96-2Fm4F33NRr1RuRHxcAJiOFSycOHZDHy3UZfzJA5pdts-2F6aQzbqV7C3uEqqypJ-2Fz-2FT8HnuMEryLIeGd0v9nlar2XZjpXNh8DDttt-2FalKj8YPBBC0zoNXKP7anpsdLEN2xfrQKCTnUOlfJfNNzCnS6bwUJh1tFCMZmeMHBLVAsjNAtC44-2FiWFOPSe-2BcaQZP-2BEm4VI-2Bw-3D-3D>
> 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.
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>