Net2WG/Notes/20090522
Contents
Meeting Notes for 5/22/2009
Agenda
* Message buffer and link layer interfaces * Release roadmap
Participants
* Phil, Stanford * Jorge, UCB * Steve, UCB * Razvan, JHU * Mike, JHU * Om, USC
Action Items
* clean up tos/lib/net/blip (Steve) * msg buffer use cases (Om)
Discussion Notes
Message buffers
Phil - Core WG discussed msg buffers and interfaces. Two proposals. One by Miklos and another by Jan. Two issues - memory layout and interfaces. For memory layout, there are three approaches - have a blob of memory and figure out where to put header, footer, etc. dynamically. Another approach is to have a circular buffer and put headers/footers/payload in the blob and a separate blob for metadata. Third approach is to use scatter/gather.
Om - Why separate blob for metadata.
Phil - Might have to shift things around if receiving lots of packets.
Jorge - Pros and cons?
Phil - There were extensive discussions on the list.
Om - Any discussion on scatter/gather beyond those two emails on -devel?
Phil - Don't think so.
Steve - Blip uses scatter/gather extensively.
Phil - With circular buffer, when an application decides to send a pkt with a payload, the data is put in some offset. When you add a header, you prepend, and you add a footer, you append. Header grows to the left, footer grows to the right. Thus you have a complete packet. If the header grows beyond the left edge, the header circles around. Need memmove to align it.
Phil - With scatter/gather, no pre-determined order necessary.
Steve - Also gives more freedom in buffer allocation policy.
Phil - There are some interface-related issues - should we have a single send interface and multiple pkt interface? Or have multiple send interfaces? example of the first approach - format a pkt and call a generic send on the formatted pkt.
Steve - What is the current thought?
Phil - Lets come up with use cases.
Om - The current approach seems like a combination of these two.
Phil - In a way. AMsend uses AMpacket to store the parameters when the packet is in the queue.
Steve - It would be possible to tell how much payload is available with this two phase approach.
Phil - There is one concern with this two-phase approach - it would be possible to write format and send interface to two different components. That would make debugging hard.
Om - Isn't this concern the same with the current interfaces as well? It is currently possible to wire packet and send to different components.
Phil - True, the new interfaces might make it more commonplace.
Steve - Another alternative might be a send interface parameterized by message type.
Phil - Why not have format and send in the same call.
Phil - Lets coordinate with Miklos/Vlado.
Om - About memory layout - do the pointers persist across calls with circular buffer? Some programmers might store this pointer across calls.
Phil - With circular buffers, the pointers would not be preserved and it sounds like a bad habit.
Om - Agree about the bad habit part, but that might be a habit.
Razvan - Should a node be capable 16-bit address and 64-bit addresses during compile or run time?
Phil - Messaging abstraction should not prevent a node from receiving 64-bit address and send it with 16-bit address format during run time.
Phil - How does a node know to send 16-bit? That is out of scope but if it decides to send in 16-bit it, should be able to do that.
Razvan - 16/64-bit issue looks like different interfaces.
Om - Once Vlado and Miklos get in touch with me, I'll get everyone involved.
Blip and BLS Release roadmap
Om: Wanted to touch base on blip and bls. What is the plan for the next release?
Phil: Well, there are 2 options: a 2.1.1 with some additions, or a 2.2 with the new message abstraction.
Stephen: I don't know what's been done outside my own little world. I am happy that we're having this message buffer discussion and doing it right. I want to see that done in a way that we're all happy. I want to switch blip to it and it should all work.
Om: How much work is left to make blip releasable?
Stephen: I think it's releasable. One thing I've been thinking about is porting the Contiki TCP stack so there's another option. What do people think?
Phil: What's the motivation?
Stephen: It's more tested. We could write a little wrapper over blip. I know a lot of people want TCP.
Phil: I think you should stick with your own. Any difficulty in debugging your own stack is small compared to debugging someone else's stack.
Stephen: Right, we'd like a well tested stack. This is on my todo list. Why don't we say that once the message buffer thing is resolved, then we'll look into getting blip on other link layers.
Om: What is the status of the code in the repository?
Stephen: I checked that in when I was more optimistic about message buffers being resolved. Is it confusing?
Om: I don't know if it's confusing, but if it doesn't compile then you we don't want it in there.
Stephen: It requires two radio files, so I'll remove it for now.
Om: Sure, and put a README pointing to contrib, so people know where to find it until we figure out messages.
Om: What platforms were you thinking?
Stephen: micaz's, telosb, epic
Om: probably no need to worry about CC1000
Phil: lets look into IRIS.
Stephen: some constants related to lqi. need to look into this.
Phil: should try with two radio chips.
Om: And for bls, what kind of timeline are you imagining?
Jorge: I haven't started yet. I think that porting will take 2 weeks, the complete work will take 4 weeks. I think by the end of June I should have the complete thing ported, with a test application and a tutorial as well.
Om: What platforms are you thinking?
Jorge: Telos/mica, while back mica2dots.
Om: That's a good set of platforms. No need to worry about other platforms for now.
Om: Could you create a directory, tos/lib/net/bls?
Jorge: Will try.
