Net2WG/Notes/20060817
Contents
Net2WG/Notes/20060817 Meeting Notes
Agenda
* Link layer abstraction * TEP 123
Participants
* Rodrigo, Berkeley * Arsalan, Berkeley * Phil, Stanford * Ning, Crossbow
Action Items
* Arsalan will send out a first cut at interfaces for a link layer abstraction * Phil will get the ball rolling on 123 implementation * Rodrigo and Om will get the ball rolling on TEP 124 * Ning will take a look at collection and TEP 123
Discussion Notes
Rodrigo: Been discussing LL for a while now, might be useful to start codifying things. We've talked through a bunch of protocols and come up with requirements. But we also want to consider the high-level goals. E.g., unifying abstraction?
Arsalan: I don't know the answer to the first question. Is the goal to still get the link layer to work over multiple MACs. It would seem to me to still be yes. We want to separate the network layer from lower layers. I still see it as being the abstraction maintianing functionality such as neighbor information and message transmission information.
Rodrigo: I would agree that it is an important goal to abstract different link layers from different network protocols.
Phil: There's a confusion between separation in terms of networking and interms of code. In terms of code is solely for ease of use and programming. Butler Lampson, generalization for its own sake is a mistake. Analogy: file descriptors. you have read and write, depending on the kind of fd you have different options. You can't call seek on a socket. It's for the general case, it makes sense to keep things separate. Following the T2 mantra of HIL HAL etc, completely obfuscating lower level details isnt' always advantageous.
Arsalan; Right, what if I want to access link-specific features?
What if I want to build an app that uses features which are link
specific? Do I work around? What are some of the features that
you might want to use? The second question is how is it done?
I think that the generalization for the majority of cases is good.
If I write a collection protocol, I might not care. Just here's
the general time I want to send. There might be times when I want
to do dynamic channel hopping, how would I do it with this link
layer?
Phil: I think that's getting at exactly the issue. The abstraction Jonathan and I discussed urgen If the implementations below differ significantly, then you end up wiring
Rodrigo: What are the alternatives? What is the other way of doing things, then? Don't abstract these things, you don't have the layer that you're programming against? You always program against a specific link layer?
Arsalan: It seems like you're suggesting that potentially a different implementation for every different kind of MAC.
Ning: Do we intend to include frequency hopping in this abstraction?
Phil: If L2 doesn't support it, you can't...
Arsalan: I still see the benefits of when you just want simple things. The generalization does help. For me, the difficult part of this link layer is... there are times when the generalization does send. For me, the difficult part is how do you design this in a way so that when people want to use specific features, such as frequency hopping, they can still use this abstraction.
Ning: Frequency hopping can be very useful, though.
Phil: But it's something that has to occur below network layers, as it breaks sharing. One can't prevent another from receiving packets.
Ning: My question is whether we consider frequency hopping a general abstraction, or is it MAC?
Rodrigo: I assume that it would be below the abstraction.
Arsalan: Right, but I think Ning is suggesting network layers using frequency hopping. But how do you resolve the conflicts that ensue?
Rodrigo: I think some level of abstraction is useful. There is some least common denominator that MAC layers must provide. Sockets are a useful abstraction, but they also have the ugly setsockopt.
Phil: I think the issue comes down to being able to observe what the LL does in response to a special request.
Rodrigo: Such as, "how much energy will it cost to send reliable?"
Phil: Let me stop derailing this. I think that the top-level points are perhaps useful to talk about: messsage futures, neighbor table, etc. I am unsure about reliable, how it's implemented, etc.
Arsalan: Wouldn't the argument be that you should have different implementations based on the MAC layers? How would you provide this interface that gives you some sense of what's going on?
Phil: concerns come from discussion with Jonathan Vagueness gets in the way of really good implementations. For example, the tar program actually probes the disk and file system to ask about block and sector sizes for optimal write policies.
Arsalan: If we admit that the best implementations have to use the lower abstraction, then that's an issue.
Rodrigo: So I think there are three categories of functionality. Three goals:
1) Abstract different MAC layers. 2) Provide common functionality that most protocols need. 3) Arbitration, sharing, optimizations.
Rodrigo: But even if you want to work around it, some parts might be useful, such as arbitration.
Arsalan: Yeah, I think that being able to use some parts is good.
Rodrigo: And bypassing abstractions can screw everything else. These also seem like questions that are difficult to solve in the abstract.
Phil: When are things like reliable and urgent useful? When? Why?
Rodrigo: Urgent is useful for giving priority to control traffic over data traffic when the network is overloaded?
Arsalan: That was the main case. Otherwise, in all cases, the network layer was priority scheduling.
Phil: So the point is one network layer being able to give priority to some of its packets over other protocols?
Arsalan: Urgent means "send now" or send within a certain timeout.
Phil: What does it do?
Arsalan: In the implementation, urgent packets go before all non-urgent packets, it does not distinguish whom they came from. The question of what it is supposed to do? That's kind of complex. Is it for a specific protocol, then why don't I just do the scheduling myself at the network layer. The difficulties come up are knowledge of what other protocols are doing. I think something like "send this within this period of time" might be more useful.
Rodrigo: More wood on the fire. Urgent is lost across multiple hops. So if you are routing a packet, is it urgent along the path?
Phil: That would require a bit; it's more than scheduling.
Rodrigo: I think we have lots of questions to answer.
Phil: But just coming up with answers is a good first step.
Rodrigo: The requirements we have subsume all of those main features.
Ning: I think there are two features for urgent. The first is scheduling in the queue. The second is for the receiver to treat it differently.
Arsalan: Right now, its completely transmitter based.
Phil: If we had a receive queue, we would need to pass the information, as it should be at the head of the receive queue.
Rodrigo: It would be nice to see what the TinyNode people say about this too.
Arsalan: We want to keep in mind that there's stuff besides 15.4.
Discssion of TEP 123.
R: You say the packet is uniquely identified by origin, seq no, and ID. Is collect ID really needed?
P: Since collect ID doesn't change over life of packet, why not include it? Doesn't hurt. And also can wrap around seq no's, and it'll have a different collect ID.
R: Routing frame. Address and then ETX. Address should be parent address, not sending node's address.
P: Other collection people should look at this. The critical part I tried to get to was sec. 4 and 5. There should be some additional info in there, with respect to things like ETX. i.e., if you do not have a route, must advertise in ETX form.
R: Another thing. We talked about one tep for both types of collection protocols. But I think this is self contained in this manner.
P: I originally thought about combining as both. But we could do it as separate ones as well.
R: Well, they do share things like assumptions and limitations.
P: Well, for DSDV, loops are a serious problem.
R: For someone implementing this, having both in the document is confusing.
P: Yea, the TEP is tough, but we need to start banging on code again. We should split collection directory into two directories for differing implementations.
(Quick Overview of Collection for Ning)
R: Arsalan, put together a sketch of interfaces for next time?
A: Yea, sure.
