global scale event notification

1. global scale event notification Bob Briscoe, BT Research Sep 2004Acknowledgements: Jon Crowcroft (Uni Cam)Jane Tateson, Andrea Soppera, Trevor Burbridge (BT)

2. event notification? • event:(the representation of)some asynchronous occurrence • asynchronous:at a time unpredictable to the observer • occurrence:change in the state of an object

3. my point • the Internet of thingsdepends on widespread event notification handlers • far from consensus on outstanding hard problems • hard to make endpoints reliant only on themselves • too onerous for challenged hardware • but alternatives require unscalable state in comms infrastructure event notification handler messaging services? comms state ? ? UDP TCP … … TCP UDP IP IP

4. visualmodel €7 3D assetmodel colourphotography property ofLegoland edge detection edgemodel co-sensors thermal imaging assetregister thermalmodel • care in the community, home, automotive, supply chain, Internet zero, sensor nets conceptual model • the hard comms problem • synch info models with real world phenomenon • transducers • synchronising comms • distributed processing • cumulative layering

5. comms modesasynchronous communications • iPic Web server [Shrikumar02] • impressive but... • do we continually ask everything physical to report its state? • asynch event notification more applicable for sensors [Shrikumar01] • polling never better: not timely, not efficient • cascade of event notification over polling loses timeliness storing & reporting state can be decomposed “The iPic demo server is connected by a serial link, which is currently experiencing a load up to its full design capacity...Please visit the mirror site below.”

6. call-back updates updates newsubscribe communication modes one shot server client request reply request-reply time source channel listeners subscribe publish publish-subscribe notify

7. decomposition client req-rep request reply storelast event storelast event storesubscriptions storesubscriptions senseevent sensephenomenon client pub-sub listener listener comms modespublish-subscribe • inherently point to multipoint (group communications) • feeds from real world maintain plethora of views of the world • no need for radio listener at source: power hungry • but no control over subscription memory demand

8. source host 1 joinrouting group host 1 multicastforwarding relay 1 duplicate relay 2 duplicate host 2 host 3 host 4 host 2 host 3 host 4 members listeners initiator deployaggregationbehaviour listener host 1 host 1 install concastforwarding aggregate e.g. COUNT, MIN, MAX, SUM, AVE (TinyDB) install aggregate host 2 host 3 host 4 host 2 host 3 host 4 potentialsources sources group formation and forwarding source

9. channelisation problem [Adler01] everywhere in network between event sources and group interest • each group’s channel requires stored resource • either distributed group routing tables • group routing tree created by receiver interest (app or net layer) • each relay stores list of neighbour interest per routing group • near-linear complexity: little inherent topological correlation? • or channel allocations • each group in each ‘cell’ allocated spectrum/timeslot/code/ etc • if aggregate channel resource • must then filter at receiver wasting b/w, interrupts and processing • or filter in network (equivalent to channelisation problem) • or index-based dynamic creation of groups [Soppera:watchcast] • creates an economic limit to pervasive computing

10. the unexpected didn’t happen – I think • if pub-sub, avoid ack  implosion & sender doesn’t know receiver list anyway • nack preferred (SRM/concast etc avoids implosion) • rcvr cannot nack asynch msg • until receives next in sequence (msec or years later) • solutions: • hop by hop ack [Rowstron01:SCRIBE] • e2e index beacon [Soppera:watchcast] • note: hop by hop ack doesn’t imply e2e delivery (cf TCP) • for sensor nets, e2e = across concast & multicast parts

11. open but closable • pub-sub has a nice ‘business model’ • basic model: open publication of data on a channel • limit visibility with crypto or scoping of msg routing • rights can be changed out of band at run-time • can maintain relationship with listeners, which pub-sub hides • doesn’t lock in zero config devices • zero config device’s packet destination is a neutral ‘channel’ • listeners join channel at run-time to complete msg routing config

12. attempts at solutions global scale event notification

13. Business Solution Watchcast Application Managed GAP Generic Announcement Protocol (GAP) multicast IP Generic Announcement Protocol <ath:URL=http://www.hosting.org/AThID?set=farm$31425> Announcement Thread ID version Payload

14. Business Solution Watchcast Application efficient & flexible Managed GAP Generic Announcement Protocol (GAP) multicast IP index-based event notification Index channels Application channels 202 100 1240 9021 7873 8 7 4 2 2 80 101 3 1240 2 4 Payload Payload Payload 102 6 1683 4 1683 163 1290 987 3 4 4 21 5 101 Payload Payload Payload 4 3 9021 2 987 92 163 4 5 3 6 92 6 Payload Payload 102 6 7873 80 1290 21

15. Business Solution Watchcast Application Managed GAP Generic Announcement Protocol (GAP) multicast IP zero cost forextra watches multipointrequest-reply joins (routing) data (forwarding) index-based event messaging event1sender indexer event3sender event2sender potential receivers

16. CS,i Pi ... A0,i K0,j Mi A0,i+1 K0,j+1 Mi+1 A0,m K0,n Mm time CS,i+T0,K CS,i CS,i +T0,K+T0,G SPINS [Perrig01] • implemented on Berkeley motes • group security, not just 1-1 • based on two primitives: • SNEP for message encryption • mTESLA for message authentication • TESLA derives asymmetry from passage of time, not modular exponentiation [Perrig00:TESLA, Briscoe00:FLAMeS] • strong cryptobut light processing & msg overhead

17. design goals • zero rcv • zero config straw man proposal hard-coded multicastgroupaddress stored symmetric seed wipe then update by touch phenomenon key server copy of seed one hop to mains power tamper-resistant EK1(1,event1) threshold transition EK1(1,event1) K1...Kipseudo-random key sequence from symmetric seed beacon repetition EK1(1,event1) EKi(i,eventi) EKi(i,eventi) threshold transition EKi(i,eventi)

18. prerequisites for Internet of things • ubiquitous pub-sub • but also… • group creation facilities capable of 106 group /sec worldwide • infrastructure investment incentives • if p2p infrastructure, solve free-riding • solve privacy without limiting commercial potential all our efforts here now privacy is the gating factor(what you’ve seen is 2-4yrs old)

19. more info • strange links, ad hoc connectivity creation, routing across sensor databases, addressing events, message traffic profiles, unusual congestion control, security in the wild, key establishment without RSA and more…Bob Briscoe,"The Implications of Pervasive Computing on Network Design" BT Technology Journal 22 (3) pp. 170--190 URL: <http://www.btexact.com/publications/bttj/bttjissues/> (July, 2004)(but deliberate journal on-line publication delay) • Bob.Briscoe@bt.com • questions?

21. global scale event notification spare slides

22. receiver initiated Business Solution Watchcast Application Managed GAP Generic Announcement Protocol (GAP) multicast IP IP Multicast - recap Data sent to group Data replicated by routers receivers join group IP address within an allocated rangerepresents a ‘group’ not a host

23. don’t multicast until mains minimise message.links can do better aggregation of multiple messages (directed diffusion) [Estrin00,01] concast cf generic router assist (GRA)(cisco - generalisation of nack aggregation (PGM)) receiver initiated multicast normal rules apply but gateway is proxy source (e.g. for re-transmit) relay doesn’t need meaning encrypt end to end mains Internet energy constraint reverses rules battery net

24. source host 1 joinrouting group host 1 multicastforwarding relay 1 duplicate relay 2 duplicate host 2 host 3 host 4 host 2 host 3 host 4 members listeners initiator deployaggregationbehaviour listener host 1 host 1 install concastforwarding aggregate e.g. COUNT, MIN, MAX, SUM, AVE (TinyDB) install aggregate host 2 host 3 host 4 host 2 host 3 host 4 potentialsources sources group formation and forwarding source see also stocast [Nekovee]

25. connectivity of everything • as a statement of scope • otherwise implications on networking uninteresting • as a statement of recommendation • universally present software: • TCP/IP, event notification?, higher... HTTP, XML parser? • why? if relative cost small, potential benefit is large • TCP/IP cost: • 200B code (cf. TinyOS 3.5kB, mote 8kB) • memory smaller, cheaper, energy efficient O(2t/D) • processing costs energy • headers cost bandwidth esp. IPv6 (header compression helps) • potential benefit: O(n2) [Metcalfe] • avoid constraining new uses by locality D = doubling time n = no. of connectablenodes

26. connectivity creationmotivating force • no grand plan for the model of everything • mini-models required in their own right • re-sell for others to build bigger models • retail then wholesale • or open publication?

27. connectivity creationconnectivity by arrangement? • how did the model’s connectivity arise? • by arrangement: frequencies, formats, codings, protocols, languages • created within another application: discovery and configuration • classic example: • personal digital assistant seeks attractive monitor • love at first byte? straight to layer 7 on the first date? • an alternative • cyberspace as chaperone and matchmaker (pre-connected) • new requirements on cyberspace • proximity model(s) • are you a flatscreened Sony or a 53yr-old divorcee from Hounslow in a rain-coat?

28. locationmodels incyberspace ?XMLcapability description proximity awareness • more advantages • coverage • augmented reality Jwdz *%+4/s9d ? ? ? JINI SLP ASCII XDR TCP eh? IPv6 no-net 802.11 RS432