Net2WG/Notes/20080307 Meeting Notes
Agenda
* Charter
* Low Power
Participants
* Om, USC
* Razvan, JHU
* Phil, Stanford
Next Meeting Agenda
* Low power CTP results
* Deluge lock-up
Discussion Notes
Charter
* Om: I got one comment. So, Razvan, do you think that all of the new protocols emerging will be a distraction? Should we separate them out into other groups?
* Razvan: No, I don't think it's too cluttered.
* Om: Well, we could have an IETF protocol WG.
* Phil: What's the gain?
* Om: Maybe they want to not be constrained in net2, and want a separate WG.
* Phil: There's a difference between "We want to start a new WG" and "You guys need to start a new WG."
* Om: So with that in mind, how do we go about expanding our charter?
* Razvan: Can't we just change a file?
* Om: So how wide should the charter be? Should we just drop collection and dissemination?
* Phil: Sure.
* Om: How about time synchronization? Where would that go?
* Phil: I think it depends on the implementation. We don't know.
* Om: OK, so let's go forward with the change, I'll check with the group and mail David.
TYMO/etc.
* Om: I've been communicating with several developers offline, and there's progress.
Low Power/Duty Cycling
* Razvan: So this guy wants to turn the radio on and off. The thing we want to make sure is that turning the radio on and off doesn't cause the protocol to hang.
* Phil: Right, two problems. First, robustness: doesn't crash. Second: make work with LPL.
* Om: So the first is making sure Deluge doesn't hang when you turn the radio on and off.
* Razvan: Right. So we don't know, it might hang. I need to test it.
* Om: So do you think it is a useful thing for Deluge to work with LPL?
* Razvan: I think it is enough to be able to turn Deluge on and off.
* Om: Well, do you think there are situations where you want to run Deluge on a deployed, low-power network?
* Razvan: Here is the problem. So I'm using Drip. So does Drip work on LPL?
* Phil: Sure, it's just trickle. But there's questions about Deluge's data transmissions, ACKs, etc.
* Razvan: I'm interested in working on this after April.
* Om: So let's talk about CTP. Clearly it needs to work under LPL. The big question there is how to align the control packet rate with LPL. One thing we've done is to get the root to generate a beacon once every 30 seconds, fixed interval.
* Phil: So I think there are three things: fix the trickle timers, examine the retransmit policy on no ack, and whether nodes should buffer before forwarding.
* Om: Well, if we don't have LPL, then we want to send immediately. But if I am using LPL, I want to buffer.
* Phil: I am not concerned with that so much. I am maybe concerned with the latency buffering might bring if I send just one data packet.
* Om: But do we want to favor low power or not low power?
* Phil: Low power. Low power always.
* Razvan: Without LPL, just from normal protocol, how many opportunities do you have to sleep?
* Om: A lot of opportunity, based on what I see in the event logs. But we can't take advantage of all of it. But according to what I see in the event logs, it should be a lot lower.
* Razvan: And the leaves use less, right?
* Om: If there's a question of tweaking the parameters, then we want to look into that. Sacrificing a bit of ETX for a lot of sleep, that's something we might want to do.
* Om: So first thing I will do is fix the trickle timer on the root.
* Phil: Yeah, so beacons first, including resets on changes, before dealing with buffering.
Misc
*
