Net2WG/Notes/20070201
Net2WG 20070201 Meeting Note
Agenda
*Link Quality Estimation *CTS Status
Participants
Om (O), Phil (P), Rodrigo (R), Sukun (S) (alphabetical), Note: Sukun
Note
O: For link estimation protocol, ‘sleep’ is confusing.
P: Leave?
R: It sounds good.
R: What about moving the meeting time?
Discussion about round robin
O: You don’t need to put all the neighbors in a single packet.
P: The point is putting a subset.
O: Interpretation might be neighbor table change a lot, round robin works.
R: It needs to specify it is not the whole table.
O: If we get around without round robin,
P: We heard a measurement a while ago, but not recently, what would we do? This is a question of managing the table.
P: If I never share message with someone, does it mean I am not in the table?
O: We don’t know the size of neighbor table, the best assumption is neighbor table is a lot.
R: Anything pertaining assumption is right.
P: What are the tradeoffs: round robin, probabilistic way?
R: Signals eviction.
P: What would it matter if I am told I am evicted. It might be network level question.
O: We cannot infer by protocol, like for interoperability.
P: What would BGP do?
R: We should not specify round robin, because there can be many policies.
O: We don’t worry about this issue.
P: Assumption section at the top, it is great. Protocol can say assumptions.
R: The only other assumption, there can be different packet size. IP has packet size in header itself.
O: Comment on how to compute ETX?
R: If you specify ETX, there are different ways to compute it.
O: How can it be bad, if we not specify, but define it?
R: MintRoute decays link. CTP updates when it receives a packet
O: MintRoute type system with CTP?
O: Current CTP LE works fine, but MintRoute receiver will not.
R: The frame format is not sufficient to guarantee correct implementation.
O: Like if one uses decaying timer, and if one uses periodic timer.
P: There are two sides to this. EETX, it has a constant time assumption. Something above LE, it wants to evict the entry even if it is in the table.
R: If you get CTP transmitter, who send beacons decaying timer, the other MintRoute implementation with the frame, MintRoute will send back bad estimate, it would not work. If there is no assumption about decaying, periodic, CTP works but MintRoute would not for all other implementation. Frame format alone cannot guarantee correct operation.
O: Do we feel comfortable saying this is not compatible with periodic timer? You have to change MintRoute.
R: There is a sequence number, which has a lot of limitations.
R: It needs be said MintRoute can be implemented, but may not be compatible.
O: It would mean precluding MintRoute.
Discussion on Test Data
P: Single node, single hop communication. This is during Deluge. If you look at how bandwidth drops, each CTP gets 1/3 of bandwidth, Deluge gets 1/3 of bandwidth.
R: I agree, if Deluge blasts, CTP tries to retransmit a lot, get new parent, etc.
O: I wonder sampling interval. 5 or 6 parents.
P: Parent? It is sum of all nodes.
R: Are the synchronized?
P: No.
P: My point is that it is really hard to break CTP. Queueing helps a lot. If you look at the retransmit count, CTP tries really hard. One thing we observed is that when you push hard way beyond limit, goodput goes up but network fairness drops. Nodes close to root gets all the bandwidth. Maximum goodput is 55~60 packets/sec.
R: At the basestation?
P: Yes.
R: And unfair.
O: Why would it be?
R: The further from the base station, the less bandwidth.
P: CTP is pretty good.
O: Would it be that periodic timer needs be avoided?
R: It would be not.
