Net2WG/Notes/20070208
Net2WG 20070208 Meeting Note
Agenda
*Finalize the name for Link Quality estimation/discovery protocol *Discussion on TEP124
Participants
Om (O), Rodrigo (R), Sukun (S) (alphabetical), Note: Sukun
Note
R: In terms of precision, if we don’t invert, I have more resolution. If quality is small, ETX will get very large quickly.
O: You can not represent 0. But, hopefully we’re going to have 0.
R: Inverting seems to be a waste.
O: How about multiplying by 100.
R: 100 is too much for 8 bits. It would make sense to take a log, but it goes too far.
O: So current form is good.
R: Precision wise, it is good.
O: Next thing is the name.
R: This thing is doing two things, sequence number and neighbor information. It allows you to estimate and exchange estimation. Link quality should be a part of the name. Link estimate exchange.
O: LEEP?
R: Yes. For discovery take place, we need to have anything with packet at the source.
O: If there is any neighbor discovery protocol, it would be AM.
R: Link information exchange seems good.
O: Link quality exchange, it seems like somebody else is providing link quality information.
O: LEEP is probably the best.
R: I like it.
O: Do you mind going back to TEP?
R: Good.
O: Link quality can be a little bit ambiguous.
R: I think we can say that this is an approximation.
O: The losses are uncorrelated.
R: Trying to measure quality asymmetrically.
O: It has to be roughly linear, but I don’t want to put that. Isn’t it a good thing? It is imposing too much?
O: Maybe we can say it should be linear? It may be implied by ‘probability’.
R: And then people have to work to comfort that. It is practically linear. The section it matters is slightly non-linear.
O: Yes, it is subtle.
R: Inbound link quality. May be we can say link estimation entry. N is neighbor and Q is quality. In 2.1, it might be good to say we can represent link quality with one number.
O: I will add uncorrelated loss.
O: It turns out sequence number is an important part of the protocol.
R: ‘must’ have to be in the transmission side.
O: Yes, I think so. The receiving side might not even care about what it is.
R: There is another detail. To avoid duplicate sequence number. Retransmission needs to have different sequence numbers?
R: The sequence should be incremented by 1, even if LEEP may have retransmitted.
R: We don’t say here, and say in the reference implementation.
O: Duplicates don’t matter here.
R: If you have an assumption, if every single have different sequence number, we don’t exactly know what the link quality is.
O: It is my concern not to talk about sequence number.
O: We can say it may be used to estimate link quality by counting missing sequence number.
R: And also saying other method can be used to estimate link quality. Make sure putting sequence number for protocol without LQI.
R: In summary, all outgoing packet must have sequence number, which increments per every single transmission (including retransmission), and receiving node may use it or decide not to use it for link estimation. However, all nodes should put sequence number for other protocol who uses sequence number.
R: With 8 bits, you can sort of be certain.
O: Wraps around in 2 seconds.
R: Suppose transmitting fast, 127 packets are missing… If you are in the same half of the circle, it will be fine.
R: What about using extra 4 bits? It is important thing is to say remaining reserved bit should be 0.
O: Why do we need to set it 0?
R: In the future, when they are used, they would be indistinguishable from some random value.
O: I would say ‘reserved’ and must be set to 0. I was thinking 0 means deactivate some feature.
O: In case we have a negative logic, it would not help.
R: The idea is resolving 0000, so that in the future when the reserved field is used, 000 would not mean anything.
R: We can say, if you like to experiment with 4 bits, you can do. If those experiments are good, they can be part of next specification.
O: Next is entry.
R: Entries tell how many entries are, right?
O: Yes.
R: It can be said that the maximum number of entry is such that it fits within the frame.
R: There is a ‘must’ condition on the maximum number of entry.
O: The size of packet will specify the end of payload.
R: I think it is important to say the maximum number of entry.
O: It looks at the maximum size of frame, size of header, length of payload.
R: So the user says getpayload, then you give the maximum payload size. Then the user send the size, and you put what is available in left space.
