Some food for thought for you... certainly on Heroku and Im guessing for many other cloud platforms, HTTP is definitely the first class transport, and using straight TCP is either more difficult or unsupported.
Putting the added overhead of wrapping up/unwrapping the protobuf RPC in an HTTP  wrapper, would there be any blockers you can think of that would prevent Akka from running on top of a remoting and clustering layer that did just that and wrapped the protobuf in HTTP and had netty pipelines that did the proper encoding/decoding such that everything else would function normally???

For TCP, we have an internal private alpha version of what we call TCPRouter, which we could use to test akka remoting/clustering via TCP.  There are both command line tools and soon a java api to control the routing...so here is pseudocode of how it works.

https://github.com/JacobVorreuter/heroku-routing 

Lets say we have an app deployed to heroku, that has one process type called 'akka' and we wanted to do a 32 node test.

Pseudocode

for(1 to 32) {
  i => 
      val route = heroku routes:create // route is something like tcp://routes.heroku.com:12345 
      heroku routes:attach route "akka." + i
}

heroku scale akka=32

The akka app should then use the api to read attached routes for the app, and use that to seed the gossip protocol.

Note that we arent very close to actually releasing this feature, but it will do for akka internal testing.

There is a REST api sitting behind all of the commands in the command line tooling.

We also have a java client wrapper for it, https://github.com/heroku/heroku.jar .  (BTW we will include a Spray-can based connector once spray supports SSL clients). So for instance, an akka app could use the api to self scale based on load.

There isnt a java wrapper for the routing api yet, since it isnt public, but it would be trivial to hit the REST api directly from an akka app to get the gossip seed.

So without TCP routing we still couldn't even do a true HTTP based cluster app on Heroku, because without TCP routing, the individual nodes are not directly addressable, so all HTTP traffic flows through our routing layer and is non-sticky load balanced across nodes.

However, with TCP routing, we can also use the tcp-route to talk over HTTP.  So for instance....take an app with 2 web nodes (play 2 with akka 'http-remoting' enabled) and 2 akka nodes.

We could do something like

attach tcp routes to the 2 web processes and the 2 akka processes. Lets assume they are all speaking akka "http-remoting". they also grab the gossip seed via api.

Now all the nodes are directly accessible for http based gossip/remoting/clustering, and the play web frontend is publicly accessible through http://my-app-name.herokuapp.com  with traffic flowing through the normal path of our erlang routing/load balancing mesh.