Net2WG/Notes/20060427

Participants: Kyle, Ohm, Arsalan (left halfway through), Rodrigo, Sukun, Phil (took notes), Joe (joined a little late)

Rodrigo: Question of mapping network-level to data-link addresses. Ohm and I decided that using am_addr_t for both is OK.

Phil: I am totally confused.

Rodrigo: Currently link-layer addresses are am_addr_t. You have to use AMSend. But there can be potentially different kinds of addresses, and different kinds of addresses. The step that SP uses is to not use actual am_addr_ts, (no link addresses at all), instead exposes link handlers, abstract identifiers that are private to the node. So that totally separates what link you're talking to. So you say "Send to neighbor #5" and SP then maps this to an actual link address. Is that part clear?

Phil: Yes.

Rodrigo: So one idea we had was to use a similar abstract identifier for collection, to get the benefits. But we decided to not do that for now. Instead, we'll stick with am_addr_t. The reason is that we're not actually implementing a link abstraction, and doing so would require a lot of work which might just be thrown away once we do the enhanced link layer. So instead we use am_addr_t.

Phil: That makes sense. I was thrown by the original statement about link-layer and network-layer names.

Ohm: How do you I look up the link-layer address of sending node?

Phil: AMPacket.address().

Rodrigo: So this is a data-link address, not a network address? I use it to send to a node one-hop?

Phil: Yes.

Ohm: One thing that I've been oscillating on is piggyback or self-generation.

Rodrigo: So let me put this into context. What we're thinking of piggybacking is the reverse link estimation. This is important so you can prune asymmetric links. The first option are to put this in the beacons. The advantage is that we can totally decouple the two pieces. But it

Phil: Are we talking about piggybacking on beacons or on data packets?

Rodrigo: Beacons. The question is a bit more general: if you have a link estimator that is doing this, but for some reason all the clients are sending big messages, then you could piggyback without too big an overhead.

Phil: So Alec's paper makes a pretty compelling case for why you need a minimum traffic rate, in order to prevent the table from churning.

Rodrigo: So the link estimator needs this table, and needs to have some kind of periodic traffic. It can either generate this traffic, or it can use the traffic from other sources. Ben Greenstein proposed the idea of instituting a min-rate policy. So if I don't see packets in N seconds, I generate a packet.

Ohm: Or you can use a cancel approach: I say "send in X" and then if I send a packet I can cancel it.

Sukun: If link estimator is below the routing layer, then it will see a subset of the traffic.

Rodrigo: The assumption is that the link estimator will see only traffic explicitly wired to it. The other option to piggybacking is to just generate packets periodically.

Phil: We can just combine the beacons and the reverse link info, right?

Rodrigo: Yes. One option is to piggyback when you can, and to send periodic beacons if you can't. So in the common case, it would just be piggybacking. But if I haven't sent someting on node X in 45 seconds, I send a beacon. That sort of idea.

Ohm: Let's do that.

Phil: I think it will need to be a footer, due to how the programming interfaces work.

Ohm + Rodrigo: Yes.

Rodrigo: And I assume we can use a bit, in the sequence number or something. So the way it goes, the network layer asks for a length and a pointer, you return the maximum, then you can append whatever you want at the end.

Ohm: In this case, I think it will work.

Rodrigo: So in terms of the whole collection thing, I think that the interfaces between the modules are close to stable. As for the tree building, the only thing missing is the selection of the parent. It will initially be similar to MintRoute. One issue with that is loops, but there aren't

Joe: Loops are a good thing. You don't want to continually go in a loop. But a loop in which you get path diversity is actually is good.

Rodrigo: You're saying a loop gives a second chance.

Joe: We detect loops of up to 10-12 hops. We keep the state in the nodes. You can say, "I've seen this packet."

Ohm: You assume a protocol that uses alternative paths.

Joe: Yes.

Rodrigo: You can try to detect loops to send on alternate paths.

Joe: All I'm saying is that outlawing loops altogether is a bad idea. The approach "I've found a loop, drop the packet," is not OK.

Rodrigo: I think the question is whether you prevent loops completely.

Joe: But you can't.

Rodrigo: DSDV does so. DSDV, even with inconsistency, does not form loops.

Joe: There's always the opportunity to just before you create a loop, to prevent the loop. Either way, you're detecting a loop.

Rodrigo: So I get your point about the diversity. You can cast it as detecting the loop as detecting it before you form it, or when you encounter a loop.

Joe: MultiHopLQI keeps a history, and detects loops using that.

Phil: And this works in the base where you have a low load, but it won't work when you queues are full. But generally the low load is the expected case, so it covers the base case, but can fall down.

Rodrigo: I think Joe's point is that we need to consider path diversity, and that doing so is very important.

• Discussed membership application *

• Forgot to take notes on end of call. Summarized. *

General consensus that collection should include a control byte, which has information such as ECN and provides avenues for future expansion.