[net2-wg] meeting notes 1/25/2007

[Omprakash Gnawali]

January 25, 2007

Present: Phil, Sukun, Rodrigo, 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


- om_p