Pravin Bhagwat et al., IBM TJ Watson
This was pretty cool: a prototype for allowing in-room, short-range, high bandwidth wireless connectivity for mobile devices.
Phil identified some overt recent threats to the end-to-end argument, including various kinds of proxies, firewalls, etc., and lightweight protocols such as WAP (which he calls a "misguided optimization" and he says should stand for "Why Another Protocol?"). More ominous threats, though, involve "carriers moving up the stack": cable and ADSL providers that do port blocking or insert ads or censor content, etc., i.e. instead of acting as "infrastructure pipes" they are interposing functionality that should be left alone at the application level. [Ed. note: one solution is to trust only your app level proxy, giving end-to-proxy-to-end functionality...] As another example, cellular carriers are trying to implement Mobile IP in their networks in ways that make it useless for roaming outside that network, subverting the original purpose of M-IP and requiring the user to implement their own M-IP on top. Phil's main point: the danger in allowing continued violation of the e2e argument is that it's being subverted in the interests of vendors, in ways that don't meet users' needs and in fact make users' lives worse. He proposes that we be watchful and use tools like IP-level encrypted tunneling and lower-level QoS (where available...) to enforce the layering that the e2e principle was intended to respect.
A useful link to an online version of the end-to-end argument paper and others: http://people.qualcomm.com/karn/library.html
There were various speakers, but the most interesting to me was Chris Schmandt, MIT Media Lab, audio message delivery/alerting for the always-connected. "Nomadic radio" necklace can do spatialized sound, has a mike, and is used primarily to notify you of message arrival. "Scalable audio": degrees of audio alert; change in background sound -> pre-cue (possibly in message sender's own voice) -> preview (may be auto-summarized and speech-synthesized) -> user can choose to listen to full body. WHen user makes a decision, system infers from this decision how to handle future messages; e.g. if medium-priority msg is deferred, lower-priority msgs won't even generate an alert. [Ed. note: this seems like a separate problem, plus doing this with only the 1 or 2 bits of info "I want to hear it" or "I don't" doesn't give you enough information to learn anything useful.]
MOCA: like NInja/Jini, but some services are available on client, not just centrally (ex. service lookup). Q: how's this different from caching code/data with leases?
Services vs. applications: services are "more secure". Q: why, and how can you enforce this? Even if you can, why does this imply separation between apps and services?
SDS: multicast, + distributed directory. Scalability? HOw about having the name service broadcast its existence and having services unicast to it?
Short product lifecycles: "Don't write for Palm, CE, etc."
Q: what's the size of the MOCA footprint on your current prototype? What's it run on? How about having a "minimal" interface stub on the (non-Java) device?
MAGNET:
Q for all the "service arch" people: (1) what's the one big innovation that distinguishes you from {Jini, Ninja, Tspaces, e-speak, ...} (2) describe what's in your prototype - footprint, differences from deployed version (qualitative features not code), how many devices/services actually in use?