Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

> PIE [...] lends itself better for implementation in existing hardware,
> or hardware with small modification.

Could one of you please explain why?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> On Thu, 14 Mar 2019, Toke Høiland-Jørgensen wrote:
>
>> You're right that packet accelerators complicate things a bit. I'm not 
>> entirely convinced that the "doesn't lend itself to FQ-CoDel and the 
>> rest of the mechanisms the bufferbloat movement has gravitated towards" 
>> actually *has* to be true, but it's harder to do a proof of concept 
>> since the barrier to entry for hardware development is higher. So I 
>> doubt anything is likely to happen here unless someone with the 
>> resources to do hardware development steps up.
>
> The people with hardware experience want to do PIE, because it lends
> itself better for implementation in existing hardware, or hardware
> with small modification.
>
> Sometimes it's better to accept non-perfect more easily implementable
> solutions that solves most of the problem space, instead of aiming for
> the "perfect one" and getting nothing.

Absolutely, I'm all for that. But even something that is as
retrofitable[0] as PIE is not getting implemented... So then what to do?
This makes it difficult to motivate spending more resources on doing
more work in this area... :/

-Toke

[0] "Retrofitable" is totally a word...

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

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/ 
 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  wrote:
> 
> On 14 Mar 2019, at 00:40, Ted Lemon  wrote:
> 
> 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.
> 
> 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.
> 
> 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.
> 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.
> 
> 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.
> 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.
> 
> IoT meshes are out of scope for homenet.   I agree that there are some 
> interesting problems to contemplate when using them. :)
> 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.
> 
> On Mar 13, 2019, at 6:45 PM, Tim Coote  wrote:
> 
> Ted
> 
> On 13 Mar 2019, at 18:35, 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.
> 
> https://tools.ietf.org/html/draft-lemon-homenet-review-00 
> 

Re: [homenet] homenet: what now? ... next?

[Mikael Abrahamsson]

On Thu, 14 Mar 2019, Toke Høiland-Jørgensen wrote:

You're right that packet accelerators complicate things a bit. I'm not 
entirely convinced that the "doesn't lend itself to FQ-CoDel and the 
rest of the mechanisms the bufferbloat movement has gravitated towards" 
actually *has* to be true, but it's harder to do a proof of concept 
since the barrier to entry for hardware development is higher. So I 
doubt anything is likely to happen here unless someone with the 
resources to do hardware development steps up.


The people with hardware experience want to do PIE, because it lends 
itself better for implementation in existing hardware, or hardware with 
small modification.


Sometimes it's better to accept non-perfect more easily implementable 
solutions that solves most of the problem space, instead of aiming for the 
"perfect one" and getting nothing.


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> On Wed, 13 Mar 2019, Toke Høiland-Jørgensen wrote:
>
>> Since you seem to be pretty up to date on the ISP-level CPE offerings, 
>> just out of curiosity: Do any of these fancy ARM boxes include actual 
>> fixes for bufferbloat? :)
>
> Short answer, no.
>
> Bufferbloat isn't on the radar of any product managers I have talked
> to. Cable Labs is the only organisation that seems to do anything
> about this that I have seen.

Right, yeah, that's what I thought. :/

> I have made statements previously in that context of most newer higer
> end devices having packet accelerators which doesn't lend itself to
> FQ_CODEL and the rest of the mechanisms the bufferbloat movement has
> gravitated towards, but I still feel what I said wasn't really
> accepted and "taken in".

Well, for my part I have mentally filed this under "vendors don't care",
which has been my impression the whole time (with a few exceptions).
It's terribly frustrating, but it's not like there's anything I can
really do about it, so I've more or less resigned myself to this.

You're right that packet accelerators complicate things a bit. I'm not
entirely convinced that the "doesn't lend itself to FQ-CoDel and the
rest of the mechanisms the bufferbloat movement has gravitated towards"
actually *has* to be true, but it's harder to do a proof of concept
since the barrier to entry for hardware development is higher. So I
doubt anything is likely to happen here unless someone with the
resources to do hardware development steps up.

But anyway, thanks for confirming by suspicions :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Mikael Abrahamsson]

On Wed, 13 Mar 2019, Toke Høiland-Jørgensen wrote:

Since you seem to be pretty up to date on the ISP-level CPE offerings, 
just out of curiosity: Do any of these fancy ARM boxes include actual 
fixes for bufferbloat? :)


Short answer, no.

Bufferbloat isn't on the radar of any product managers I have talked to. 
Cable Labs is the only organisation that seems to do anything about this 
that I have seen.


I have made statements previously in that context of most newer higer end 
devices having packet accelerators which doesn't lend itself to FQ_CODEL 
and the rest of the mechanisms the bufferbloat movement has gravitated 
towards, but I still feel what I said wasn't really accepted and "taken 
in".


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet