[net2-wg] August 17 meeting notes

[Philip Levis]

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: confusion between system and network
completely obfuscating all lower level details is not necessarily
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 **

R: Arsalan, put together a sketch of interfaces for next time?

A: Yea, sure.