Present: Phil, Razvan, Om, Steve, Jorge, Mike, Martin, David Moss Scribe: Steve DH
Om: What is BLS?
Jorge: A location service for protocols (on top of BVR). Maintains mappings from cordinates to node IDs. Maintains then at beacons in the network, so you send a packet by doing a lookup and then sending.
Om: State of the software?
Jorge: written in T1, not ported.
Phil: The implementations are only in contrib, should we move it into core.
Jorge: Yes, we should port them and move them into core.
Steve: What's the interface, would it be integrated with S4?
Jorge: Yes, there could be an common interface that everyone uses.
Phil: it would be a little wierd to have JUST BLS and not S4 or BVR.
Jorge: sure, I would rather port S4.
Om: you would have to be responsible for maintaining it.
Om: also, it has to be possible to coexists with other protocols. Okay, we're done with BLS for now. We're not going to provide a lot of implementation advice, but happy to talk about interfaces.
Om: Also, what about a CTP refactoring? What's the major concern? Might be useful to understand what David is doing.
David: refactoring, not a lot of code size reduction. Increase in functionality for increased modularity. Massaged some of the interfaces, logic cleanup. Thought we might be interested, maybe we can step in and start to reduce code size.
Phil: this sounds like a good idea, the current code base has been churning for two years and is probably not minimimal. Something on my plate is to streamline the forwarding path.
Om: Talking about a long-standing bug where send will return busy, with or without timesync.
Phil: there's a narrow case when CTP has a packet and you get a busy.
Om: It tries to send a packet when it hasn't received a senddone.
Phil: Might happen when a new packet comes in from the app while forwarding.
David: it's in the rincon contrib directory in tos/lib/net called IndustrialCTP now.
Phil: can I modifiy it?
David: yes, that's fine if we want to keep it out of mainline from now.
Om: What app-specific things are you interested in?
David: modified CTP to slow down when on a low-power MAC. Also, the whole network was routing through a single node which increases the duty cycle. Increase the ETX as a function of the battery level to do some load-leveling.
Phil: Interesting, it's a node state thing, not link state, does involve changing what you advertise.
Om: there are similar discussions happening in ROLL.
David: I removed one node which was doing a lot of routing, and the neighbors keep hitting him.
Phil: the link just becomes infinitely costly.
Om: we'll have to look into this and keep in touch.
Om: another thing is our teleconference. I don't have long-distance teleconference, so this is a problem for me. A problem for anyone else?
Phil: Post sensys, CTP is a done deal. Do we want to do some things like reliable transport?
Om: TENET does this with reverse path forwarding by having each node maintain reverse paths.
David: I have the gateway flood a message every hour or so, and allows nodes to realize that they have no connection to the gateway.
Om: can we run CTP underneath BLIP? What are the issues there for using transport layers.
Steve: there's a lot of 6lowpan/ip specific code in here.
Phil: there's a tension between overmodularity and functionality.
Steve: agreed, the key separation is between transport and point-to-point routing. Maybe also some routing interfaces.
David: keep the CTP stuff in rincon?
Phil: if we're doing a lot of refactoring, keep it out of core.