IETF
roll@jabber.ietf.org
Friday, May 13, 2016< ^ >
mcr/credil has set the subject to: IETF96 ROLL WG meeting
Room Configuration
Room Occupants

GMT+0
[07:06:58] simonduq joins the room
[07:07:09] <simonduq> hello, sorry for the delay
[07:07:16] <simonduq> great that you bring this topic up
[07:07:36] <simonduq> I think it's one of the most important under-specified things in RPL
[07:08:05] <simonduq> haven't figured out yet how much it should remain unspecified and up to other protocols or up to the implementation
[07:08:25] <simonduq> but if you guys think there is room for standardization I think there is a need
[07:08:29] <simonduq> so, what Contiki does
[07:08:36] <simonduq> is it has something we call "link probing"
[07:08:54] <simonduq> with the sole goal of keeping link-layer estimates up-to-date
[07:09:04] <simonduq> and it is driven by RPL
[07:10:01] <simonduq> i.e. you probe your preferred parent the most often to check its sanity, very often the second best to make sure the estimate is fresh (we have a freshness indicator) when we need it, and also now and then every single neighbor to discover good neighbors that once were bad
[07:10:21] <simonduq> note that the focus is on link-layer, and RPL-specific, that is why we do not use NUD for this purpose
[07:10:50] <simonduq> a Contiki probe can be configured to be either a unicast DIS (then we get a DIO back) or a unicast DIO
[07:10:59] <simonduq> what does Riot do?
[07:11:20] <simonduq> what do you do Michael? (sorry I don't know the name of your implementation :/)
[07:11:31] <simonduq> do you guys see a need for standardization?
[07:14:29] <simonduq> (I did not answer on the biderctionality part, but the idea is that as we base estimates on received ACK we're sure the down link is not completely dead. In my experience if you stick to great uplinks, the downlinks are never terrible)
[13:28:44] <mcr/soho> simonduq, my implementation is called unstrung; I do nothing at present, but would like to.  What are your probes?  You say they are RPL specific, so does that mean unicast DIS?   I'm curious why NUD wouldn't work, except maybe that you wouldn't see the NUD packets...
[14:09:27] <simonduq> we use RPL unicast DIO or DIS
[14:10:49] <simonduq> NUD would work. But one thing is we want to make sure the probing is dictated by RPL. Prioritizing the relevant parents. And for instance, when the current parent degrades, we speed up probing on the best candidate to make sure we switch to something robust
[14:13:50] <mcr/soho> I don't think we to standardize this, but I think it would be nice to have a description of what you do.
[15:00:54] simonduq leaves the room
[17:02:27] mcr/soho leaves the room
[17:02:27] mcr leaves the room
[17:04:40] mcr/soho joins the room
[17:05:24] mcr joins the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!