Geoff Mulligan wrote:
Tim,
I think that you have some misunderstandings.
Undoubtedly. However, this broad claim about my lack of
omniscience doesn't appear to be applicable to the issue
that my e-mail raises.
On Thu, 2007-12-06 at 16:10 -0600, Timothy J. Salo wrote:
Samita Chakrabarti wrote:
... That way, periodic RA will not wake up
all the nodes in the 6lowpan. ...
To the best of my knowledge, 802.15.4 implementations power-down
the radio when the system sleeps. As such, a broadcast packet
does not wake a sleeping 802.15.4 node. Rather, the packet
is simply never received by the sleeping node.
This is not true. A node that sleeps can receive broadcast packets.
- If the broadcast packet is transmitted on some schedule then the
sleeping node can wake up on that schedule and receive the packet.
- If the broadcast packet is transmitted with some sort of long
preamble then the sleeping node can wake up on it's own schedule, over
hear the preamble and stay awake to receive the packet.
- If the broadcast packet is transmitted multiple times the sleeping
node can wake up during one of these transmissions and receive the
packet.
All you have said is that a sleeping node can receive if
it isn't sleeping. I don't think that this sort of "Black is
white, (as long as it changes color)" answer does much to advance
the discussion at hand.
By the way, you missed the most interesting solution to this
problem, namely the "indirect transmission" mechanism
specified in the 802.15.4 specification. See, for example,
section 7.5.6.3 of the 802.15.4-2006 specification. Note
that 802.15.4 also defines "macTransactionPersistenceTime",
a parameter which specifies the maximum time that a coordinator
must hold onto a packet waiting for an RFD to wake. (Also,
I think 802.15.4 specifies a minimum queue length of one!)
These schemes have several problems, some of them serious:
o They don't interoperate. Again, is system-level
interoperability one of our objectives? If it isn't, I
suggest we simply say so.
o They all require a fair amount of energy. In particular,
the second approach burns a lot of energy on the transmit
side (as well as burns channel bandwidth) waiting for all
of the receive nodes to wake. Plus, the unlucky receive
nodes that wake early have to stay awake to receive the
whole preamble. And, this scheme pretty much requires
that all nodes wake pretty regularly. For most processors,
simply waking is a time- and energy-consuming task. Yes,
some newer microprocessors require less time and energy to
wake. But, do we want to hardwire that assumption into
6lowpan?
o All of these schemes cause multicast to exhibit a latency
that is nontrivial and not necessarily bounded. Again, it
seems to me that we need to say _something_ about the
expected behavior of multicast in 6lowpan environments.
Is there a bound on latency (which of course puts an upper
bound on how long nodes can sleep, and therefore how long
they can live)?
This is much like receiving any packet, not just broadcast packets.
If my understanding about this behavior is incorrect, someone
please correct me. I have been meaning to check and see what
the spec says about this, but haven't yet...
There is nothing in the spec on this. As far as I know, there are no
15.4 radios that wake on some sort of reception.
Precisely. My point is that multicast is different in
802.16 networks (which I understand have a wake-from-idle
capability) and 802.15.4 networks (which don't). I don't
think that we should simply assume that the 16ng approach
to using multicast is necessarily directly applicable to
6lowpan. I am suggesting that we actually think about the
issue.
Given that the response to broadcast packets differs in 802.16
networks (where an idle node wakes to process the packet) and
802.15.4 networks (where a sleeping node is never even aware
of the packet), different solutions are probably required.
To reiterate what I have said before, I believe that we must
explicitly specify the behavior we expect of multicast in
6lowpan networks that contain sleeping nodes.
No we don't.
I continue to disagree. For example, is there no bound on
how long multicast may take? Is there an expectation of some
level of reliably reaching every node in the network?
The behavior of multicast in 6lowpan networks _will_ be
different than with traditional media (e.g., latency,
reliability, cost). It would seem prudent to at least
warn application and protocol developers about this.
In particular,
does multicast mean "received by the potentially very small
percentage of the nodes that aren't currently sleeping" or might
it mean "received by every node after they wake up [whenever
day that might be]"?
After we specify the behavior of multicast,
then we can then try to figure out whether we can actually
implement that behavior in a useful way.
In the interim, I suggest a moratorium on simply assuming that
multicast is a potential solution to any of the challenges
we face (e.g., duplicate address detection, router announcements,
neighbor discovery, ...)
NO.
Battery-powered nodes have a fixed amount of energy. They
can spend that energy on infrastructure or overhead activities
(like waking up to listen for repetitive RA multicasts) or they
can spend that energy transmitting useful application information.
I think 6lowpan should minimize the energy cost of simply belonging
to a 6lowpan network. I think that this means eliminating
multicasts that provide no more information than simply "I'm not
dead yet". For that matter, I suggest that we try to eliminate
the need for the basic 6lowpan infrastructure protocols to use
any multicast.
Having said all that, I understand that "perfect" is often the
enemy of "good enough". However, I think it would be beneficial
to at least think about what "perfect" might look before declaring
"good enough".
-tjs
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
