• Good Design

  • Whether something "should" be on the server or client because of good decomposition

  • Probably not terribly important.

• Library API

  • Do not want to complicate the API and make the developer write more or trickier code

  • Complicating the library is ok, just not the library API

• Latency

  • Depends on what we're doing. Might increase.

• Throughput

  • A net plus (that's why we're doing this)

• Scalability

  • We only want to add servers if we run out of storage capacity.

• Security

  • The client cannot be trusted

  • Obviously we still need some authentication code on the client

• RAM

  • We want servers to reserve as much memory as possible for holding data. If certain tasks use too much memory, then that might not be acceptable.

  • Remember, can't swap data to disk!

• Ratio of application servers to storage servers?

• What will be saturated? CPU? Network? Something else?

  • We want to increase the load of whatever is not being utilized.

• Does it make sense for client machines to contribute their RAM?

• How much RAM does a client actually need?

• What is the cost savings of adding RAM to a client machine compared to buying a new server?

• Again, what is the bottle neck?

• Accessing the data

  • What level of queries will we allow?

  • Simple operations (get, put) probably nothing interesting

  • But what if you need to do something with the data, such as sort?

  • Basically it comes down to "do we need to do computation on this data"?

  • Are we willing to do trade-offs that increase network traffic?

  • Also depends on whether the data needs to be in the same place (sort) or not (sum)

• Self-management

  • Code that manages servers (moving data, crash recovery)

  • How many cycles does this actually need? If not that many, then does it even matter?

  • Probably security issues with this

• Indexing

  • Ask John

  • Who does the indexing? Client can probe index, or the server can

  • Putting it on the client allows it to be more flexible.

• Data replication

  • Probably makes more sense on the server (but I am not sure)

• Map reduce

  • Is this done separately?

  • If not, it's just a question of who's got the spare cycles

• Locking

John's stuff:

• RAMCloud is built on the notion of distribution:there will be many storage servers, and there will also be application servers. Not all of the functionality of the system will run on the storage servers.

• Wherever it can be done efficiently, we should try to offload functionality from the storage servers to the client machines: this will increase the scalability of the storage system.

• The RAMCloud system software can include a component that runs on the client machines, so we can choose whether to implement pieces of functionality on the client or on the servers.

• For example, consider an operation that collects data and sorts it:

  • Of the data will almost certainly come from multiple storage servers.

  • It would probably make sense to do the final merge on the client machine, not on a storage server: the RAMCloud client software identifies the desired data, fetches pieces from various servers, and merges them together into the final sorted result.

  • It might not even make sense for the storage servers to do the initial sorts of the data fragments: just collect raw data and return it for sorting on the client machine.

• What is the right boundary between RAMCloud client software and server software?

• Things that absolutely must be done on servers:

  • Anything that requires trust, such as access control. Particularly in a multi-tenant environment, the client can't be trusted.

  • Locking (if it potentially impacts other client machines).