Like in a Petri dish, I keep observing how the iPhone single-handedly pulls the roadmap of a telco infrastructure. Both iPhone and AT&T wireless infrastructure are expanding at torrid pace and beyond the wildest imagination (to an outside observer like me at least). The reaction is amplified by Apple’s single-track mind to perfect a user experience and their exclusive deal with a carrier - in short, a monoculture. No ounce of pull force gets lost. The 1-2 jolt that has developed from Apple to AT&T is a new baseline for textbooks.

A recent report confirms that AT&T has done good in its intent to improve its 3G download/upload throughput. Improvements stem from the roll-out of HSPA 7.2 (besides the sheer new capacity thrown at the problem). Broad technology advances in beamforming, multiple-input multiple-output communications (MIMO) and orthogonal frequency division multiplexing hint that there’s quite a headroom for further scale-outs over the next 3-5 years.

I’ve sampled the AT&T improvements directly using the excellent, free Xtreme Speedtest application. For extra credit, I can go multi-platform and run this same application at the same place and time on both my iPhone/AT&T and Droid/Verizon. The speed of a web browsing session would otherwise be highly subjective and dominated by the browser’s own effectiveness.

In a previous blog, I described the “wheel of innovation” looping over the following steps:

1. New infrastructure build-outs
2. Leading to faster/broader connectivity
3. Making it a breeding ground for new applications
4. Some of them reaching viral spread, network effect, etc. resulting in larger addressable markets
5. Thus creating demand for more/different infrastructure

(loop back to 1.)

We have gone from step 5 to steps 1 to 2 (even though I have no basis to comment on coverage – I will steer clear of blue vs. red maps…) Now that the infrastructure shortcomings are beyond us, along with troubling rumors of usage tarifs, I’m eager to see a new breed of applications (steps 3 and 4).

In a subsequent post, I will share my wish list on what iPhone and smartphones in general can and should pull through in software infrastructure.

This week, slashdot called my attention to EFF’s effort to level set the community on web tracking — how unique (and traceable) does my browser make me look when I visit a web site?  This new EFF site returns my overall score along with the break down of its factors (like plugin details, screen size, system fonts, cookie handling). For instance, it tells me that the Safari fingerprint generated off of my Mac is still unique among the half-million fingerprints on file at the EFF.

This is a great example of crowd-sourcing at work. The more participants, the better the study. EFF’s work gets a huge boost from being slashdotted. Moreover, EFF is no .com and doesn’t  have the halo of big-brother or world domination.

How does one know when the samples have hit a critical mass leading to a reasonably accurate model? It’s a recurring conundrum for both frequentists and Bayesians.

I agree with EFF’s view that a smartphone’s browser is due to show lesser entropy. That kind of browser is less likely to veer from stock config. To witness, my iPhone browser scored 1 in 1,442 uniqueness (10.49-bit entropy) and my Android browser scored 1 in 8,513 uniqueness (13.06-bit entropy). To the previous point, it’s unclear how many smartphones have hit the EFF site altogether.

This smartphone/browser early conclusion should not be generalized to native apps running on a smartphone. These native apps can yield the richest fingerprint features yet. They can draw upon some sophisticated UUID and TPM schema in system software, with the SDKs exposing programmatic access, resulting in stronger software/hardware linkages than their desktop/laptop equivalents. Today, the limiting factors here have to do with policy – e.g., a vendor’s authorization to export off-device the UUID material that is key to its own DRM.

The word generativity jumps at me while I’m reading Jonathan Zittrain’s new book, “The Future of the Internet – and How to Stop it”. Zittrain defines generativity as  a “system’s capacity to produce unanticipated change through contributions from broad and varied audiences”. Internet, PC, wiki/wikipedia best exemplify generativity. It’s “generativity” what I had in mind and tried to say when I wrote about Internet’s virtuous wheel of innovation.

Generativity hits home. It’s the reason why I’m so genuinely interested in the Android platform (I got to carry one such phone alongside my iPhone). It’s why I put my TV set in early retirement and replaced it with an Internet-enabled one equipped with widget SDK – a generative TV in the making, hopefully. I know that I have given and will be giving my 150% in those jobs that have to do with generative artifacts (luckily, I have had a few of those jobs throughout my career).

Generativity is quite a litmus test for new directions in technology. Take cloud computing. Does it mark a new epoch in generativity? Or is this a mere TCO optimizer?

For sure, security, regulations, net-neutrality pose some great challenges to our collective journey in generativity. I look forward to reading the second half of Zittrain’s book and learning about his proposed solutions.

Zittrain came to visit us at eBay and gave an excellent lecture on “Minds for Sale” — an eye opener on both the positive and negative outcomes of long-tail participation in cyberspace.

The Tarte Tatin is an upside apple cake. It used to be my favorite dessert when I lived in France. Yum.

Eating a Tarte Tatin on a lovely summer afternoon while catching up on Google Chrome OS (yeah, I’ve fallen way behind due to my ever demanding day job plus a pile of papers to review out of conference TPC duties).

Google Chrome OS (and other browser OS wannabes) makes me think of an upside cake, just like the Tarte Tatin. Let me explain. In the mid 90s, the Web browser rocketed into the scene. It became the pinnacle of our stack. Fast forward 15 years. With the Google Native Client, one can load and launch native x86 code in the browser without giving up on security (what could possibly be worse than PHP anyway…). Application management is quickly moving to the Cloud (SaaS, PaaS, the-whole-Enchillada-as-a-Service). Likewise, resource management has to play out in the Cloud. Thus, the new-wave browser must underpin both application management and resource management. The browser has become a shim layer buried deep near the bottom of the stack. Voila the upside down cake.

Have we seen other examples of upside down cakes in technology? For sure. Take the Internet. In the 70s, the revolutionary packet networking movement started off as a geeky use case that piggybacked on the very circuit switched network laid out for telephony. This set-up worked well for a long time, until data traffic outweighed voice traffic, in sheer volumes as well as business pull-through. The packet network then moved to the bottom of the pile, with telephony running as an application (VoIP) atop of it, along many others. Voila another upside down cake.

Legend has it that the Tarte Tatin was the lucky byproduct of a bad day in the kitchen. Unlike the Tarte Tatin, there’s little serendipity in what’s happening to the browser and what has happened to the Internet long before. Rather, they are huge R&D undertakings. In my career, I want to see some more of these upside down cakes! Along with chilled passito wine, please, for which I don’t have a geeky metaphor just yet.

Over the last quarters, I spent much time developing the case (ROI, TCO, etc.) for the latest multi-core processors and their yield, measured in transactions/$ and transactions/watt.

Flashback. ‘Twas the end of the 80s and I was a jr. engineer hard at work to get a 4-way 68020 SMP Unix box to perform reasonably well by placing locks in a recalcitrant SVR2.4 kernel. David Cheriton (or was this AST?) quipped that one could either work allnighters for 18 months to figure out all the locks, or else could go to the beach for just as long, come back, and expeditiously plug the CPU du-jour into a uniprocessor with a huge gain over the SMPs with yesteryear’s silicon. This figurated view of Moore’s law hit home. I went on to  find some new challenges (note:  microkernels; no beach).

Fast forward twenty years, and we hit our head on the ceilings of clock frequency and gate density. We have no choice left but run a multi-socket multi-core setup flat out. The superior CPU horsepower and memory hierarchy quickly surface the concurrency shortcomings in our code. The performance line tops off and then turns South.

So, let’s take on concurrency head on. My colleagues recently went to JavaONE and gave a good, well-received run down of their lessons learned in Java concurrency, resulting in some practical patterns and anti-patterns.  Do try them at home!

Sangjin Lee (eBay), Debashis Saha (eBay), Mahesh Somani (eBay), “Robust and Scalable Concurrent Programming: Lessons from the Trenches”. Here’s a before/after flashcard gleaned from their presentation. The full presentation is up for free download here.

There’s another side to this story: The memory wall. It’s just as important to single-out and rework those constructs that get in the way of L2/L3 cache efficiency, like HashMaps and the traversals of linked lists. Furthermore, we like to have a systemic way to manage and leverage any NUMA-ness in our systems.

I list hereafter topics that I’m highly interested in and will be following:

• Post core-spread principles for kernel re-design, like Robert Morris’ Corey that I profiled earlier on; I anticipate that this year’s SOSP will feature quite a few papers in this space;
• Java-only production stacks for which there is (at least) one layer too many between hypervisor, kernel, and JVM, and beg for due simplifications;
• Machine-learning techniques to manage the combinatorial explosion of configuration knobs-and-dials and their inter-dependencies, like Ganapathi’s HotPar09 paper;
• Transactional memory (I read a good article by Drepper on the Feb issue of CACM);
• Access to all hardware counters that can inform tuning (you can’t manage what you can’t measure);
• Share-nothing languages like Scala actors or the re-discovered Erlang (which dates back to  just about the same time of my flashback in the opening).

Some interesting times for sure!!!

With the Security Guidance document, the newly formed Cloud Security Alliance is off to a solid start. I read the white paper with interest. I like to think that many focus areas for the CSA and the Cloud security community at large stem from one simply-stated root cause: Trust ain’t a transitive property.

Among things, the document addresses the concerns on accountability that I had raised on this blog.

Some musings after reading the CSA document:

We have always built systems in observance of least privilege. What’s the actual least privilege for a Cloud provider? Let’s pick a provider of the IaaS persuasion. No root access to guest virtual machines. No root access to virtual load balancers, virtual switches and virtual firewalls. What else can be meaningfully taken out of a provider’s key chain, without compromising on site stability and service availability? Meanwhile, a Cloud user will do well with more than one line of defense. For one, I like what the Overshadow researchers are doing to protect application data in the event of OS compromise. It won’t make data impenetrable. It does make it a whole lot harder to get to, forcing a new round of cat & mouse chase.

The argument that in a Cloud one should know the neighbor bears some fallacies. Knowledge does not imply control. Yet, it’s tempting to blur this line. For example, false security sets in among some engineers using a Cloud - that they have some deterministic control over resource sharing with other neighboring Cloud tenants. Some cubicles away, the procurement/legal colleagues who negotiated that Cloud agreement know all too well that they have no control nor leverage. In this example, Cloud tenants change just like weather does (uhm, may be the “Cloud” moniker isn’t a bad choice after all!).

Naturally, personal identifiable information (PII) is a defining embodiment of data worth securing against foes. This should not detract from other, more nuanced data types. Take business meta-data, for example. The correlation between a Cloud customer’s feature roll-out and the resulting traffic surge (or the lack thereof) goes a long way towards revealing strategy, tactics, and competitive stance. Typically, it leads to information (analytics) that the Cloud customer would want to control and keep close to its vest. Would a Cloud provider’s routine telemetry dole out precious insights on a Cloud customer’s business trajectory, and who would have access to this information at the Cloud provider’s end?

I look forward to seeing CSA’s membership grow. Also, I will be interested to track whether CSA will codify best practices and take a stance on specific technology nuggets like the increasingly popular OAuth.

Increasingly, Internet-scale sites need to do more with less. The rapid commoditization of IaaS/PaaS services is an example of race towards the leanest CapEx/OpEx possible.

This is not without risks. One’s own balancing act of risks vs. rewards can be captured in the spectrum that I show in the picture  below.  For this, I was inspired by some readings I did a while ago on complexity theory and adaptive systems. Beware of being caught at either end!

Ideally, one would want to play near the “edge of chaos”, with the confidence that there is a way and a time to step on the brakes, without ever crossing into chaos.

Some R&D projects fall in the realm of catalysts, in that they thrust towards greater risk/reward operating points. Examples include oversubscribing power, network, DR resources.

Some other R&D projects fall in the realm of “chillers” (which sounds less dire than the traditional inhibitor word). Service level management is an example. It may shape and/or rate limit traffic within a given service level envelope.

Has anyone developed similar taxonomies? Your thoughts?

In my Cloud-related outings, there are a couple of topics that I especially like to expand on (my view) or get hung up on (in all likelihood, my audience’s view ;-):

Accountability (as in: where’s a throat to choke ;-). In general, Cloud providers are not liable for any data loss, IPR loss, downtime, etc. For an enterprise, this is a key departure from outsourcing, hosting, B2B, … which all have some form of indemnification and a clear chain of accountabilities or escalation should things go horribly wrong (i.e., starting from the CIO nearest the boo boo). How will Fortune 500 enterprises overcome the fact that Cloud business rests on reputation only?

Availability: in my opinion, it’s one of two things. Either we think in terms of legacy applications and live by traditional KPI goals like three- or five-nines uptime that are comparable to (say) the dialtone service. Or else we come up with entirely novel application paradigms and stop looking at cloud availability with the glasses of the 1980s. After all, we have already settled for a much lower-quality wireless dialtone and can live with dialtone-less homes whenever power goes off (there was enough extra value for us to compromise on those). What we cannot do – I submit - is to run unchanged legacy applications on-Cloud and pretend to live by some new, lax KPIs.