Transcript global scale event notification

global scale event notification
Bob Briscoe, BT Research
Sep 2004
Acknowledgements: Jon Crowcroft (Uni Cam)
Jane Tateson, Andrea Soppera, Trevor Burbridge (BT)
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
my point
• the Internet of things
depends on widespread event notification handlers
event notification handler
messaging services?
?
UDP
TCP
IP
…
comm
s state
…
TCP
IP
?
UDP
• 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
conceptual model
• the hard comms problem
• synch info models with real world
 care in the community, home,
automotive, supply chain,
Internet zero, sensor nets
visual
model
colour
photography
property of
Legoland
3D asset
model
edge detection
phenomenon
edge
model
thermal
imaging
•
•
•
•
transducers
synchronising comms
distributed processing
cumulative layering
thermal
model
asset
register
comms modes
asynchronous 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.”
communication modes
one shot
call-back
server
client
request
requestreply
reply
updates
time
source
channel
listeners
subscribe
publish
publishsubscribe
notify
updates
new
subscribe
comms modes
publish-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
decomposition
req-rep
sense
sense
event
phenomenon
store
store
subscriptions
subscriptions
request
store
store
last
lastevent
event
pub-sub
listener
listener
client
reply
client
group formation and forwarding
source
source
host 1
relay 1
join
routing group
host 1
multicast
forwarding
duplicate
relay 2
duplicate
host 2
host 3
host 4
members
host 2
host 3
host 4
listeners
initiator
deploy
aggregation
behaviour
host 1
install
e.g. COUNT,
MIN, MAX,
SUM, AVEhost 2
(TinyDB)
listener
host 1
concast
forwarding
aggregate
install
aggregate
host 4
host 3
potential
sources
host 2
host 4
host 3
sources
channelisation problem [Adler01]
• each group’s channel requires stored resource
– either distributed group routing tables
everywhere in network between
event sources and group interest
• 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
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
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
attempts at solutions
global scale
event notification
Business Solution
Watchcast Application
Managed GAP
Generic Announcement Protocol
Generic Announcement Protocol (GAP)
multicast
IP
<ath:URL=http://www.hosting.org/AThID?set=farm$31425>
Announcement Thread ID
version
Payload
Business Solution
Watchcast Application
Managed GAP
index-based event notification
Index channels
202
100
8
7
4
Generic Announcement Protocol (GAP)
multicast
IP
Application channels
1240
9021
7873
2
2
80
Payload
Payload
Payload
1683
163
1290
101
4
4
5
21
4
3
Payload
Payload
Payload
987
92
3
6
Payload
Payload
101
34
1240
2
102
6
1683
4
987
3
9021
2
163
54
92
6
102
6
7873
80
1290
21
efficient & flexible
Business Solution
Watchcast Application
Managed GAP
index-based event messaging
indexer
Generic Announcement Protocol (GAP)
multicast
IP
event1
sender
zero cost for
extra watches
event3
sender
event2
sender
potential receivers
multipoint request-reply
joins (routing)
data (forwarding)
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]
CS,i Pi
A0,i K0,j
Mi
A0,i+1 K0,j+1
Mi+1
...
A0,m K0,n Mm
time
CS,i
CS,i+T0,K
CS,i +T0,K+T0,G
• strong crypto
but light processing & msg overhead
straw man proposal
• design goals
• zero rcv
• zero config
stored symmetric seed
wipe then update by
touch
hard-coded
multicast
group
address
key server
copy of seed
phenomenon
tamperresistant
one hop to mains power
threshold transition
beacon repetition
threshold transition
K1...Ki
pseudo-random
key sequence
from symmetric
seed
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)
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)
• [email protected]
• questions?
global scale event notification
spare slides
Business Solution
Watchcast Application
Managed GAP
Generic Announcement Protocol (GAP)
IP Multicast - recap
multicast
IP
receiver initiated
Data sent to group
Data replicated by routers
receivers join group
IP address within an allocated range
represents a ‘group’ not a host
energy constraint reverses rules
battery net
mains Internet
• 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
group formation and forwarding
source
source
host 1
relay 1
join
routing group
host 1
multicast
forwarding
duplicate
relay 2
duplicate
host 2
host 3
host 4
host 2
members
host 3
host 4
listeners
initiator
deploy
aggregation
behaviour
host 1
install
e.g. COUNT,
MIN, MAX,
SUM, AVEhost 2
(TinyDB)
listener
host 1
concast
forwarding
aggregate
install
aggregate
host 4
host 3
potential
sources
host 2
host 4
host 3
sources
see also stocast [Nekovee]
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
D = doubling time
• TCP/IP cost:
– 200B code (cf. TinyOS 3.5kB, mote 8kB)
– memory smaller, cheaper, energy efficient O(2t/D)
n = no. of
– processing costs energy
connectable
– headers cost bandwidth esp. IPv6 (header compression helps)
nodes
• potential benefit: O(n2) [Metcalfe]
– avoid constraining new uses by locality
connectivity creation
motivating 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?
connectivity creation
connectivity 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?
proximity awareness
location
models
in
cyber
space
?
XML
capability description
*%+4/s9d
JINI
ASCII
TCP
IPv6
802.11
?
?
?
Jwdz
SLP
XDR
eh?
no-net
RS432
• more advantages
• coverage
• augmented reality