[Tinyos-host-mote-wg] Discussion

[Ben Greenstein]

On Apr 11, 2005 5:30 PM, Philip Levis <pal at cs.berkeley.edu> wrote:
> Based on the discussion today, I think we concluded that there are two
> problems we need to solve:
> 
> 1) Detection of supported data formats from the UART: 15.4 packet vs.
> mica2 packet, etc. The general consensus here was to have a layer of
> dispatch at the UART level. That also allows simple out-of-AM-band
> protocols like ping, without binding them into an implementation.

as david gay suggested, in the context of ppp, this means, in part,
creating an ncp for AM.

> 
> 2) High performance data transfer. This is where all of the
> connection-oriented/windowing/acknowledgement discussion came from. The
> general consensus here was that it would be desirable to see if we can
> push PPP in this direction, and also that the final protocol should
> place as few requirements as possible: if you don't want to keep track
> of windowing, etc., you should just be able to state that the window is
> one packet.

Two comments. First, for most applications, "high performace" can be
defined as providing mote-to-pc throughput that is at least on the
same order as the effective reception rate of a mote's radio. For
mica2, this means O(10kbps), for telos and micaz this means
O(100kbps).

Second (and not addressed in our last meeting), interrupt timing on
the mote can lead to lost bytes transmitted over serial and
corrupted/lost frames. As the transmission rate is increased, such
errors become much more likely. Hence, if our goal is high performance
(which i assume implicitly means fast  *and* somewhat reliable), then
i think it is as important to consider system-wide interrupt timing
relationships (e.g., synchronizing and coordinating with the radio and
other interrupt-generating subsystems) as it is to consider and debate
the specific reliability properties of our protocol.

> 
> On the notion of connection-based versus connectionless protocols. The
> distinction lies in how much state you can assume the other side
> maintains. In a connectionless protocol, you need to include additional
> state in every packet, state which in a connection-oriented protocol
> would be maintained as part of the connection.

Yes. Another way to look at this problem is identify what information
each device needs to know about its peer:
- whether or not the peer is alive
- sequence numbers for sliding window reliability over serial
- device characterizations (e.g., micaz or mica2)
- protocol characterizations (e.g. no compressed headers)
Given these requirements, I am wholeheartedly in favor making the
datalink layer (the sum of hdlc and ppp) connection-oriented.

> 
> Phil
> 
> -------
> 
> "We shall not cease from exploration
> And the end of all our exploring
> Will be to arrive where we started
> And know the place for the first time."
> 
> - T. S. Eliot,  'Little Gidding'
> 
> _______________________________________________
> Tinyos-host-mote-wg mailing list
> Tinyos-host-mote-wg at mail.millennium.berkeley.edu
> http://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-host-mote-wg
>