Re: [homenet] Next Steps for Routing Protocol

Dave,

At Nest, we have different OS platforms we use depending on the constraints
of the hardware.

For things like the Nest Learning Thermostat, where there is a graphics
subsystem and such, we use a $POSIX variant commonly found in larger
embedded systems.  It has not much flash and even less memory.  We cut a
lot of things out to make everything we need to fit, and we feel
significant volatile and non-volatile memory pressure on this platform.

For things like the Nest Protect, which are much smaller, we use a
library-oriented $RTOS variant.  The current Nest Protect device, for
example, executes code from 512 kB of flash, using 64 kB of RAM.  It has a
very lightweight IPv6 stack, over which we have implemented all our
communications protocols and our application logic.  We are under truly
extraordinary memory pressures on this platform, of the sort that I believe
only somebody with experience working in the C64 demoware scene can fully
appreciate. (Seriously, you can't even. Don't try.)

I'm hoping future evolutions both in these product lines might have
incrementally more resources, in which it may be possible to demand space
for Comms Engineering to insert HNCP, when it's finally deployable.
Assuming HNCP can be made to work. Lot of ifs. However, whatever happens,
we eventually will need something that does what HNCP does, and I like HNCP
itself better than I like the idea of rolling something proprietary.

Does that help explain matters?

On Sat, Nov 15, 2014 at 8:46 AM, Dave Taht <dave.taht@gmail.com> wrote:

> On Sat, Nov 15, 2014 at 7:55 AM, Juliusz Chroboczek
> <jch@pps.univ-paris-diderot.fr> wrote:
> >> This included technical discussion around a partially unanticipated
>
> I have always felt that we needed to have something that could route
> packets as best as possible based on conditions (and in particular
> transport configuration information) across many disparate link layers
> - homeplug, MoCa, 802.11, 802.11ad, 802.14, 6lowpan, VPNs, and sharks
> with lasers. (
> https://twitter.com/RalfMuehlen/status/533414954167070720/photo/1
> ).
>
> While full compliance with rfc2549 is not required, wires as we knew
> them are going the way of the dodo, and already have, in most homes
> and small businesses.
>
> >> requirement for HNCP to support a stub network with a gateway that
> >> doesn't have sufficient resources to run a routing protocol.
>
> Could someone describe what sort of resources these gateways (nest, I
> assume) actually have? - What OS they run, how much ram and flash is
> on them, is there virtual memory, etc?
>
> Are there devices in this category that can be hacked on? I am
> reminded of the dnssec debate put to rest by merely producing a proof
> of concept on an ancient cpe... I mean, babel, for example, is like,
> 61k, on mips with the sole dependency on libc. Other daemons, like
> pimd are in the same size category.
>
> >
> > Mark,
> >
> > Could you please spell out the requirements for a stub-only
> > implementation?  Do you expect the stub router to hold the full routing
> > table, or just two routes (connected network and default route)?
> >
> > Is there interest in a stub-only implementation of Babel?  Should it be
> > a standalone daemon, or should it be integrated in the HNCP daemon?
> >
> > -- Juliusz
> >
> > _______________________________________________
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
>
>
>
> --
> Dave Täht
>
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering