[net2-wg] Call notes (March 30, 2006)

[Sukun Kim]

Henri (H), Om (O), Phil (P), Rodrigo (R), Sukun(S)

P: What is the situation of Arsalan?

R: No one not in the last conference call replied. Not enough negative ones.

P: Closing will be the end of tomorrow (Friday).

R: Then we can conclude the result.

R: We can talk more about link layer, and tinynode

P: Let’s start with tinynode

(There were lots of questions and answers. I summarized them)
H: As a brief overview, the company does consulting, develops wireless devices. We put tinyos-1.x last year, now we are moving to T2. Platform is in a quite standard format. Microcontroller is Msp430.
Radio is 860MHz FSK-radio from a company in US. It is a packet-oriented radio with 16 byte FIFO for reading and writing. So, we don’t need deal with each byte. Range is several hundred meters to 1km in a test with 0dBm external antenna. It went over 2Km with a small hill between two nodes. But to get longer range, bit rate needs be decreased. Power draw is (? I missed) in sending, 20mA in receiving.
The node had small antenna on board. It has many peripherals: SMA external antenna connector. There are external interfaces for expansion board, GPRS, adaptor, serial over internet. Price is around $100~200 for small quantity. I am not sure this could run in US due to 860MHz radio frequency. It could run at 916MHz. But they don’t want to launch a product with different frequency unless there is enough demand of market.

P: Early Berkeley mote ran at 916MHz. it was really bad, sometimes due to environmental effect, etc. If this can do what you say, it is pretty outstanding. This can be a back-hole(?) network: it can be used for jumping to adjacent network patch.

H: Tinynode means new network stack for this radio, and one more platform.

P: It’s not a platform push (more of a chip?)



R: Could we talk about link layer?

P: There are a bunch of things in SP. It is a first flash, there are compelling ideas, and the paper supports that. If you look at the paper, some factors were not fully evaluated. Jonathan and I were talking about how to use the urgent bit. Unless we have a clear description, it is hard to use it. I case of Trickle, when I am reaching my transmit time, submit with urgent bit, and hope it goes soon.

H: Routing layer has no idea about link delay.

P: The bigger issue is that once you submit a packet, it can’t be relinquished in tinyos-1.x. In T2, there is a cancel.
With send-before, we can tell until when to send, when we submit a packet. With send-after, we can tell “send after this delay”. Which is more important: send before this time, or send after this time? And is it a useful primitive?

O: For Send-before, it can’t guarantee that packet is sent before the deadline anyway.

P: There is a tension between software and hardware. There is no way to do it. One way link layer can tell is it can’t do that. It is a soft real time: I’ll try my best.

R: What to do when it can’t send before deadline: send, or drop? Different applications have different requirements.

O: I think there would be some expectations. General expectation would be that when it can’t, then drop it.  This would be more natural.

R: When we can’t, we can ask whether still send or drop.

P: We can drop the packet and submit it again.

R: There is a little difference. You don’t have to re-queue it.

P: Trickle is based on time rather than urgent. Urgent say it’s ok to use more resources.
If urgent bit is set, spend some more energy. Time can’t carry that information.

R: So time attribute and urgent bit?

H: Why can’t time deliver urgent bit? But there can be a case: what if time is 10ms, but don’t want to pay for long preamble.

P: If I can piggy back on other’s traffic, then do it. Other wise, don’t want spend energy to send a packet.

O: Cases make sense. Are there other examples?

P: People saying it would be useful, but I can’t find real situations.

R: In specifying time, what if we say “send it by tomorrow”. And determining urgency by time can be affected by the duty cycle, radio speed, etc.

H: Time attribute is possible, but people usually just send without quantifying it. It can be used for special cases, but in common case, would not.

P: Control traffic like deluge may use time.

R: These are almost orthogonal: extra energy and time latency. 4 combinations of them are possible.

P: Could two quadrants cover 99%?

R: We can fill that matrix, and see what happens. Maybe time + urgent, and no time + no urgent can cover large space like 99%.

S: Straw has data packet and control packet. Both needs time deadline, but data is not urgent and control is urgent.

O: The dead line is at higher layer. It can’t be done at the link level. If there is no way to do that, it may not be useful.

R: In Straw, loss of control packet does not trigger retransmission, so it does not need time deadline.

S: Yes. Then data packet is no time + urgent, control packet is time + no urgent.

R: Time need to get to e2e, then we can use elapsed time. Given time deadline, at each node subtract delay, and remaining time can be used for new time deadline.

P: Middle node can spend all the remaining time. Each node can have remaining time / distance as time. Then there are Cross-layer issues. Is it worthy all this complexity?

O: I think time is finer granularity of urgent. You want to set up timer at lower layer. That would be a key difference.

P: Make link-layer smarter, then it would enhance the behavior of protocols

R: What are the necessary functions needed to support them? If we can show that link layer can be smarter and efficient by having these information.

O: I don’t think these will make link layer more efficient

P: Protocols behavior nicely under different situations

H: Time improves portability of link layer to different hardware.

O: In which sense is it more portable?

H: Time is more common than urgent in behavior. Meaning of urgent may not be consistent on different platforms.

P: In the Internet, even thought there are 100Mbps, 1Gbps, 10Gbps links, they all work together by using same time, latency.

The meeting is cancelled next week due to SenSys.



Sukun Kim
Contact Information and more -
http://www.cs.berkeley.edu/~binetude

-------------- next part --------------
A non-text attachment was scrubbed...
Name: binetude.vcf
Type: text/x-vcard
Size: 367 bytes
Desc: Card for Sukun Kim <binetude at EECS.Berkeley.EDU>
Url : http://mail.millennium.berkeley.edu/pipermail/net2-wg/attachments/20060330/b1b7d3f0/binetude.vcf