Net2WG/Notes/20070125

Net2 Meeting notes (January 25, 2007)

Agenda:

* CTP status and plan to wrap it up
* CTP interoperability

Present: Phil, Sukun, Rodrigo, Om

Scribe: Om

Start: 9:18 PST

Phil: One student here got CTP to work in motelab. He saw 2.2-2.5 transmissions per link. It was something like 10% of the nodes contributing 90% of the retransmissions. There was one node that had 200 transmissions/successful transmission. This node was obviously disconnected.

Is it meaningful to include disconnected node? The answer is yes because this happens in the real world. Want to make sure the protocol does not fail if something like this happens.

Om: Good to understand how the protocol behaves when something like that happens.

Phil: Overall the results are pretty positive.

Phil: Lets say there is one entry in the link estimator table. How can a link fail? Is it possible that the link estimator breaks the link? What is the cutoff beyond which we should not use a node?

Om: The link estimator uses a threshold for entry eviction.

Om: Related to the question Phil asked, here is another question: When does the node stop transmissions?

Rodrigo: When try to update the route and if the link to the node does not pass a certain link quality threshold, then the new node does not become a parent. Right now the code makes the link pass all the time.

Phil: In the case of that one node doing many retransmissions, strange thing could have been happening in the network. Asymmetric link?

Rodrigo: Could be interaction between link estimator and router thresholds.

Phil: Will meet with the Sun folks a week after SIGCOMM.

Phil: We need to describe the link estimation protocol and we need to say that beacon frames are sent on top of link estimation protocol.

Rodrigo: If we allow AM id sharing by many components, what are the implications?

Phil: Probably no implication. We just say these are the values in the packets - they are sequence numbers?

Om: Should link estimator have an AM id?

Rodrigo: Lets say we have an AM id. Then we need a dispatcher to figure out the beacon frame.

Rodrigo: If it does not have an AM id, it has to be below AM. Otherwise not clean.

Phil: How so? All it is defining a protocol - header and footer. This can be on any AM id.

Phil: Lets say we design a protocol using http. But we can run it on a different port. We could do something similar.

Rodrigo: Does more broadcast make the link estimator better? If we put more traffic through the estimator, is it better?

Phil: If the table is being shared.

Phil: If the link estimator has an AM id, then it becomes a separate protocol, can't be used by multiple protocols. If link estimator protocol does not have an AM id, the answer is also no.

Rodrigo: The answer is no in both cases. Might need a bit/dispatch below AM.

Phil: CTP will either say, I am on top of link estimation header/footer or here is my link estimation header/foot.

Phil: Even with a perfect radio chip, you still have to give estimate to the other nodes.

Rodrigo: Current link estimator does two things - estimate and share. The sharing part is always needed. The first you could not need.

Om: AM or not AM?

Rodrigo: Lets list advantages/disadvantages

Phil: If the data link layer does accounting in terms of protocol ID, it can cause problem. If link estimator protocol, for example, has its own protocol ID, then if we have fair queueing, packets from all the apps sending through link estimator will be put in the same bin. This can be a major disadvantage of assigning a protocol ID to link estimation protocol.

Om: Can't this be a special protocol that is fair queued?

Phil: in the Internet, there is a single VPN tunnel instead of hundreds of connections inside it. One could treat the single tunnel as many connections and queue appropriately.

Rodrigo: Each protocol can specify if it is using link estimator or not. I prefer not having a single AM id and dispatching above it.

Om: Fair queueing the only example we should consider?

Phil: Current T2 does fair queueing in a per pkt basis so is an important example to consider.

Rodrigo: Can we put a flag in the AM packet?

Phil: It is not practical to say it is in all AM packets. Right now, there is just one AM type byte.

Phil: Having data link layer doing link estimator is a reasonable thing to do. But putting this on current AM is not feasible.

Om: But source id eventually got included.

Phil: The original did not have source id. Some data link protocols have them and some protocols don't. Potential to have duplicate source ids. Practical consideration overwhelmed the original consideration.

Om: Disadvantages are overwhelming?

Phil: Could always have a protocol with a designated AM later if that becomes necessary.

Om: Seems link estimator without a designated AM type is a better option.

Phil: Lets try to write up the TEP.

Om: Will make a first cut.

End: 10:08 PST