Net2WG/Notes/20080512

December 5 2008 - 11:00 PST

Agenda

* CTP+LPL status review
* Shepherd for TEP 124
* Plans for IP stack

Participants

* Razvan Musaloiu-E. (RM)
* Mike
* Omprakash Gnawali (OG) 
* Phil Levis (PAL)
* Steve Dawson-Haggerty (SDH)

CTP + LPL

OG: tried latest versions [CTP + LPL] without success

PAL: Define without success?

OG: Can get data, duty cycle are 20-30%

RM: Varying data rate doesn't change duty cycle

OG: Good to sumarize these experiences

       ETH- Good results with a few changes to LPL: keep track of wakeup time for
            neighbors
       Uhland (?) also used it with very good results.
       Sumarize: worked well at some point, requires tweaking LPL
  

SDH: This belongs in the link layer, not in CTP

RM: Did the ETH guys modify LPL?

PAL: Yes

RM: What if we buffered messages for a long time and burst packets

          together to amortize the wakeup cost.
  <discussion about the length of receive check intervals>
  

SDH: it's about 15-20ms

RM: False positives, 802.11 interference, everything contributes to a ~5%

          base duty cycle
  

PAL: so why do these modifications help?

RM: what about LPP for probing?

PAL: needs to work for lots of different network layers.

OG: LPP for deluge?

RM: <explaination of LPP>

PAL: how does broadcast work?

RM: you just need to wait for a probe interval and reply to all

  the probes
  

RM: resilient to false positives

PAL: probe collisions?

RM: Haven't looked at that

PAL: there's no reason there shouldn't be both in the tree.

RM: it's much easier to get good performance with CTP.

PAL: John is a cc2420 maintainer, just put it in there.

OG: What is LPP not useful for?

RM: The checks in LPL can go much lower then LPP. Right now it's

          about 20ms, but Prabal says it can go lower.  It needs some
          lower level tricks to go lower.
  

OG: the fundamental limitation is you need to send a packet and wait

          for an ack.
   software architecture: you need a bunch of tweaks for 30% DC.
          Phil: can you revive this [how to set DC] in core?  There are
          multiple places where this is done.

TEP for shepherding

TEP123 (CTP) will be shepherded by J. Hui

TEP124 (LEEP) needs a shepherd. Maybe Alec Woo?

           What about Dutchy (?) on the Double Cost paper at HotEmNets
           (from Emory)
  

OG: do you buy this "Dutchy" story? It's similar to 4bitle

       Anyways, hopefully we have a shephard.  [SDH: missed the name]
  

RM: quick comment about TEP123: last paragraph of section 2.

          CTP offers some way of aggregating small packets using the
          intercept interface.
  

PAL: this is more like Jumbo ethernet frames where L3 deals with the

         packing.  But, CTP can't do this.
  

OG: this functionality really isn't in CTP.

6lowpan

OG: Steve will replace the current 6lowpan implementation.

SDH: We need to make some changes to the messaging layer, etc.

PAL: Can we also send AM messages? We need to have a migration path.

SDH: I __guess__ we could do that...

PAL: Will talk to core about cvs access.

RM: Can I modify tos.py?

PAL: email tinyos-devel to see if anyone depends on it.