[net2-wg] Re: notes for April 27

[Rodrigo Fonseca]

Already also in wiki, at

http://tinyos.stanford.edu:8000/Net2WG/Notes/20060427

Rodrigo


On 4/27/06, Philip Levis <pal at cs.stanford.edu> wrote:
> 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.
>
>
>