1. 4/11/06Tuesday Seminar1 The State of Service Discovery Jeff Pang

2. 4/11/06Tuesday Seminar2 Service Discovery (SD) NETWORK Find me a printer I am a printer

3. 4/11/06Tuesday Seminar3 Overview Purpose of Talk: –Induce some cooperative brainstorming about contemporary SD problems :) Outline: –Local Area SD –Wide Area SD –Possible future directions for SD

4. 4/11/06Tuesday Seminar4 Local Area SD History: –AppleTalk, Novel IPX, NetBIOS/SMB Current over-IP Protocols: –Service Location Protocol (SLP) [IETF, 1999] –Jini [Sun, 1999] –UPnP [Microsoft et al., 1999] –ZeroConf (a.k.a Rendezvous, mDNS, Bonjour, includes SLP) [Apple et al., 1999] Most use the same mechanisms: –Service advertisement/query –No infrastructure/configuration required –Optional directory server(s) for scalability

5. 4/11/06Tuesday Seminar5 LAN SD Primitives Two modes of operation: –Search vs. Publish/Subscribe Service Request: search for a service –E.G., use an LDAP search filter in SLP Service Advertisement: advertise the availability of a service –E.G., iTunes playlists (DAAP) over Rendezvous Jini Primitives

6. 4/11/06Tuesday Seminar6 LAN SD Self-Configuration IP Addressing: –“Local-link”: Pick a random address from 169.254/16 and ARP to check for collisions Naming: –Multicast DNS: Pick “Your Name.local” as name and multicast name lookups to the local-link Discovery: –Service Requests multicast/broadcast –Use IP multicast groups to limit publish/subscribe

7. 4/11/06Tuesday Seminar7 LAN SD Scalability Self-Configuration breaks when: –Multiple subnets: not all hosts on same local-link –Lots of hosts/services: multicast advertisement/search is too chatty to be scalable General Solution: –Employ a Directory Server(s) at which services register and requests are routed –Effectively becomes dynamic LDAP –Requires infrastructure

8. 4/11/06Tuesday Seminar8 Recent Work IETF working groups –Autoconf in MANETs –Autoconf in “mobile networks” User-Relative-Naming [Ford, et al. 2005] –Owners assign own names to devices –Construct a consistent namespace for each user –Uses signed device logs to resolve conflicts

9. 4/11/06Tuesday Seminar9 Wide Area SD Some research, long ago: –Intentional Naming System [MIT, 99] –Secure Service Discovery Service [Berkeley, 99] –Network Sensitive Service Discovery [CMU, 03] Focus on: –Mobility (decouple name/location) –Scalability

10. 4/11/06Tuesday Seminar10 Scalability in WAN SD Solution 1: Induce some hierarchy (INS) –Service descriptions/queries form a tree –e.g., [city, building, room], [device-type, data-type] –Partition namespace among a spanning tree of resolvers Solution 2: Lossy Aggregation (SDS) –Aggregate service attributes using Bloom Filters –Trade-off query routing overhead for storage

11. 4/11/06Tuesday Seminar11 Recent Work Most work in dynamic resource discovery: –SWORD [Berkeley, 04], Xenosearch [UCL, 03], Network Coordinates [GNP,Vivaldi,Meridian,etc.] –e.g., distributed search for particular nodes WAN Service Discovery in the real world?

12. 4/11/06Tuesday Seminar12 Take Aways Key Benefits: –Local Area SD: Auto-configuration Because there are no sys admins –Wide Area SD: Fuzzy search interface Because the search space is too big for global advertisement, too unknown for direct queries Key Limitations: –Local Area SD: Scalability Primary usage pattern is browse/select –Wide Area SD: Massive infrastructure Without Google, how would we discover anything? :)

13. 4/11/06Tuesday Seminar13 Possible Future Directions “Local-link” isn’t always physically local –e.g., my desktop at home, laptop at office, cell phone on me –“virtual local-link”? Number of “services” on local-link growing –Most Apple programs advertise as services –Most service query results are junk –Preference sensitive service discovery? Mobility and context aren’t considered –Still can’t “print to closest printer” on a laptop –Context sensitive service discovery? iTunes “services”

14. 4/11/06Tuesday Seminar14 Context-Sensitive SD Ideas Keep browse/select interface, but rank results for scalability –In terms of user/application-information overload –In terms of service discovery traffic (e.g., incremental results) Try similar approach to IR folks: –Instead of ranking by Pr[result|query] –Compute Pr[result|query,context,history] Challenges: –Mobility: environment “context” may be ephemeral –Scalability: can’t rely on Google, need a distributed approach for autoconf environments –Privacy: context and history can reveal sensitive info; much pervasive computing work in this area (but do people really care? i.e., again, Google)

15. 4/11/06Tuesday Seminar15 That’s all! Questions?