Net2WG/Notes/20080912
Contents
Meeting Notes 09/12/2008
Agenda
* Review TEP 123 and TEP 124 * Find shepherds for them * net2 code inclusion policy * Some new features on the website
Participants
* Phil, Stanford * Om, USC * Mike, JHU * Razvan, JHU
Discussion Notes
Review TEP 123 and TEP 124
Phil: It says CTP tries very-very hard. This is a retransmission timer decision and not a protocol decision. You need to qualified what designed for low-rate means.
Om: This relates to the question we had on mailing list. Even we have a congestion notification mechanism it does not do any congestion control. I think that needs to be there as well.
Phil: That's an implementation detail. CTP could get congestion control. It doesn't. CTP could.
Om: About the C bit: perhaps we don't need this prescription anymore. The actual inference mechanism can be anything.
Phil: All the C bit is doing is to tell the people that I drop a packet. That's all.
Om: But could it allow a different inference mechanism for congestion.
Phil: What do you mean?
Om: Some other way. Queue length for example.
Phil: I'm afraid of vague statements. A drop packet is a very clear indication of what it means. How you respond to that? You don't know. When CTP drops a packet it will set the C bit on the next packet.
Om: About ETX. I think it is incorrect because we are actually doing EETX I believe.
Phil: Section 3 talks about the format of ETX format. Which is times 100.
Om: We rename it in section 3 itself.
Phi: If I recall correctly, a value times 10 is used in LEEP. CTP is always using fixed point values which are the value times 100. That's why is has 16 bits. All the values that CTP is sending should be identical. If you send a data frame the ETX values you send should be the same as in a beacon frame.
Om: Let's check the sources. [...] Ok. It does the proper conversion.
Om: Should we talk so much about LEEP in section 6?
Phil: I think we should. It tells the people how is estimating things. It's not just LEEP. It should include a link to the 4-bit paper.
Om: Right. I was also thinking or referring to 4bitle instead of le here.
Phil: Yeah. We should also have an equivalent of TEP119. An interface TEP rather than a protocol TEP for link estimators.
Om: That's true. I'll do the edits and send it to the list. Let's look at 124 briefly.
Phil: One thing we need to talk is about LEEP being more than link estimation. Is also discovery because of the broadcasts. It would be good to have some qualifying statements about how the estimation is inherently imperfect. It's a bootstrap mechanism and discovery. [...] In the implementation it should also talk about 4bitle.
Find shepherds for them
Om: What are the potential shepherds?
Phil: That's a good question. Jonathan Hui? He haven't call in 3 years or something. He did a lots of protocols.
Om: Yes, he will be great for TEP123.
Phil: TEP124 could be Alec Woo.
Om: I'll ask him.
net2 code inclusion policy
Om: I sent some initial thoughts for discussion.
1. The networking code should work with the standard link layer services. It should not have customized CC2420 stack, for example. 2. Convincing commitment to support the code for a year. 3. TinyOS community should have some interest in that protocol. 4. Should work in at least two radio platforms. 5. Should be able to get at least two people other than the authors to test the code. 6. Should be able to co-exist with other net2 protocols. For example, we should be able to run CTP and DIP together. 7. Should run correctly with LPL/dutycycling, but not necessarily efficiently.
Phil: They are overlapping a bit. Number 1 and 4 for example.
Om: There are also others that overlap.
Phil: One way we could say is that it should not call HAL of HPL function.
Om: Right. That's a good way.
Phil: Is not enough though. They can still turn the radio on and off. 6 is taking care of this though.
Phil: I think requirement 3 is tricky. Too high bar.
Om: That's a very subjective statement.
Phil: I think 5 satisfies number 3. [...]
Mike: I'm looking at 7 about LPL and duty-cycling. Does it really have to be a requirement?
Phil: Yes.
Razvan: What if LPL will go through some changes?
Phil: Changes that makes it semantically different? That's LPL problem.
Razvan: This will get everyone stuck in a position not to move forward thought.
Phil: It's a matter of work not work efficiently.
Some new features on the website
Om: I change a little the workgroup page and add some goals for 2008. Feel free to add to it.
