Net2WG/Notes/20070928
Contents
Net2WG/Notes/20070928 Meeting Notes
Agenda
* 4B link estimator * Link layer interface
Participants
* Om, USC * Mike, JHU * Arsalan, Berkeley * Phil, Stanford (notetaker) * Rodrigo, Berkeley * Kyle, MIT
Action Items
* Measure CTP efficiency when default white bit (0) is used
Discussion Notes
Four Bit Estimator
Om: We need to produce TutorNet graph. We need white bit implementation for CC1000. Anything else?
Phil: We should test CTP with the default white bit implementation that always returns 0.
Om: Yes, we should run that code. We should chat in more detail over email.
SP/Enhanced Link Layer
Om: We started discussing this last week. Argument last week was that there are some features that are very useful. The best way to proceeed, including Joe's comments, is to examine how the implementation of the link estimator might benefit from SP. For example, the link estimator might become simpler. If Rodrigo could look at routing to see what changes he would have to make, to see if it would become easier, that would be useful.
Om: To proceed on the SP/ELA discussion, I was thinking we look at the 3 components of CTP: estimation, routing, and forwarding, and just understand how the implementation of those three modules would change based on the enhancements. Would it become easier, simpler, less error prone? I mention these three because Joe commented that SP is more relevant for network protocols. What do you think?
Kyle joins
Arsalan: That was the view I raised last week. We tried that exercise about a year ago. It led to the first rendition of the draft proposal. But the thing is, I was looking at that interface the other day, and it looks really bloated. We always knew this, but SP is for protocols, not apps. So the more I keep looking at it, SP just synthesized the basic features of what lots of protocols need. I think that the decoupling of link estimation from network protocols is important. The ease with which it enables users to implement systems is really critical. We talked last time, the only features there should be are those which are system-wide things. The Policy Manager part of the system is really critical. It would give you a way to interface with an energy manager. I think it is a good idea to start with a diverse set of network protocols. What are the bare bones things that a link layer needs to support. Let's stray away from complete and bloated approach.
Rodrigo joins
Om: That makes sense. Which protocols to look at. We could just look at what we have right now. There are the three parts of CTP.
Phil: What are the key mechanisms?
Om: What about the parallel tables? That's important.
Arsalan: I think the idea of merging the two is problematic. If you nail the link estimation problem, then that makes sense. You don't want different network protocols to be fighting over which links should be in the table. What's important is whether different protocols interpret semantic information in the same way. If two different protocols disagree whether a link is valuable, because they use different semantic information, then we shouldn't push all of that down.
Rodrigo: One question is whether each user of table has a say in what links are in the table. A second question is whether users can extend the table: this raises issues of sparseness.
Arsalan: What is the benefit of putting it in the table?
Rodrigo: The benefit only comes if two protocols want the same field, and they both agree on its meaning.
Arsalan: Right. The easiest way to do this is to add a higher layer. Additional information can index against the link table. Some information is useful across protocols, like sleep cycle. But I haven't really seen a coherent Policy Manager appear. I'm trying to avoid pushing everything down.
Rodrigo: In that line, CTP kind of takes that approach is using a second table, and uses a synchronization mechanism, through callbacks. The CTP table is strictly a subset.
Om: And that seems to work, at least for the routing protocol.
Rodrigo: It's more natural for them to be decoupled.
Kyle: They're decoupled, but they are also tied. Like with the pin bit.
Rodrigo: Well, I see the pin bit as close to the API for synchronization.
Kyle: Because the routing table is not going to use all of the links in the link table, but wants them to stay there because it might use them in the future.
Phil: Maybe you just make sure the link table is at least the size of the sum of all of the pins.
Rodrigo: What I think comes out of this is that an alternative to an extensible table is a mechanism to have a surrogate table that is synchronized with the main table. I personally like this approach more than an extensible table. There hasn't been a lot of evidence that sharing is profitable.
Om: The Boomerang implementation doesn't actually support extension, but rather surrogate tables. You have calls like evicted().
Phil: I think SP's key insights of a pending set of requests and a shared link table are really powerful. The trickier part is the detailed parts: urgent bit, wakeup latency, etc.
Arsalan: When we started, we took the wrong approach: we took the union, rather than the intersection. We want it to be simpler. Now it's one thing to say that you have the mechanism, and the network protocol pulls the strings, but that kind of information goes through that abstraction.
Phil: Part of it is the abstraction. Hints are tough, because if you don't know what it does, it can be hard to use. For example, the Urgent bit.
Arsalan: Right, you don't know what to do with it. So in the draft, we shifted the Urgent bit to a deadline. You tell the link layer that you need a packet go out by a time. Then at that point, I can give my requirement. You need the information passed to be more concrete.
Om: If we define urgent means "This will be the first outgoing packet," how is that ambiguous.
Phil: TDMA.
Arsalan: Well, what if you have multiple Urgent bits? What order do they go?
Om: But how does the requirement approach fix that?
Arsalan: The link layer knows what to do. Urgent could mean a lot of things.
Om: I don't think there's any use of urgent in Boomerang. I'm grepping.
Arsalan: I think it's either you have no urgent bit, or you put something that's more concrete. The other argument is that if you put the timing in there, then the actual optimization engine can be part of the policy manager.
Phil: I think the policy manager is an implementation question. We should separate it out from now network protocols work.
Arsalan: Here's the problem. It's the same one that comes out with the energy management architecture. It has to do with the set of resources that you have. You tell me you want to run these three things. How can I divide it?
Phil: I think the idea of being able to swap this thing in and out easily is problematic. It can cause conflicts.
Om: But you don't need arbitrary combinations.
Arsalan: That's my argument. But then you're adding complexity to the system designer. My argument is that from a SE argument, it's easier. In terms of having, you raise your risk, it's harder to make it general. You raise a new source of potential bugs, it's the policy.
Om: It seems like it's a question of the barrier to making the changes.
Phil: The question is whether it's a user programming abstraction, or whether it's part of the system implementation.
Arsalan: So the tradeoff is efficient optimization versus interoperability.
