Net2WG/Notes/20060727

Present: Arsalan (A), Om (O), Rodrigo (R), Sukun (S)

Note: Sukun

R: Arsalan is writing a draft of data link layer abstraction.

O: Have you read paper sent?

All: No.

Arsalan talked about data link layer abstraction briefly.

A: Berkeley SP uses correlation values, which is between 55 and 110. Then it scales down to 0 to 100. The best measure of link is PRR. So Berkeley SP gives the probability for a packet to get through the link.

R: Link estimator may exchange information with neighbors.

A: Yes, it does.

O: How about the interface? What kind of interface two (boomerang and Berkeley) implementations have?

A: Same. There is a field: quality. There can be different fields in the neighbor table (for internal use?), but upper layer should be able to access one field. Joe favors that there should be no policy in link layer. Neighbor management is a shim layer on top of link layer. There can be many policies, and one bad protocol can break down all.

R: Still, we need a mechanism for upper layer to control neighbor table, like pin and unpin.

A: What would be functionalities needed to be exposed to upper layer?

O: For example, Decay, Black-listing links.

R: Upper layer can find new information: the link is not as good as link layer says. Black-listing is one way to report it.

O, R: But, black-listing turned out not very good.

R: SP and net2 link estimator have different ways.

R: What would be best way to decide which one in the neighbor table?

A: We can put the most obvious policy and let people put their code if needed.

R: What would the interface look like?

A: … (I could not follow)

R: So, when a new message not in neighbor table comes in, it is reported to upper layer.

A: It can be done by upper layer, or by some policy in link estimator. Both would not be difficult to implement. Question is which is better?

A: Different from Boomerang SP, Berkeley SP has link handle (abstract address), which allows different link address, either 16bit or 32 bit.

R: Make insert() the only one which can process neighbor without knowing handle? Pre-populate entry?

A: We actually do pre-population.

O, R: If insert fails, upper layer can have wrong handle.

A: Upper layer should use the handle only when insert succeeds.

O, R: What about using link address at insert?

O: I don’t like the overhead of pre-population to link estimator.

O: Would there be a routing which is not based on link quality?

R: Gradient routing.

R: How to make neighbor table extensible?

R: Currently common header is used.

A: Attribute can be good in the future.

R: Make two duplicate fields, or some magical way to share fields?

A: There is a name space overlap. Different routing layer can have different address. (can’t share network address field?)

R: If we can’t share fields, Kamin’s argument may be right: small separate tables are better than one big table.