Breaking News.

I am now retired, with an emeritus professor title.  I won't be bringing any new students into my group, although I am happy to talk about research related to what we did while I was active.  In my post-Cornell life, I'm working at Microsoft in a product area, Frontier Tuning -- an exciting direction for Microsoft itself, and for me too.  Unfortunately, because Frontier Tuning is a product, I cannot talk about my work or share details beyond what you can read in the public materials describing the technology and its many features. 

Graduate Studies in Computer Science at Cornell

True, I'm no longer active at Cornell, but the department remains just as outstanding in systems, distributed systems, databases, embedded applications and a wide range of related topics.  If systems research is your passion, Alex, Andrew, Hakim, Lorenzo, Rachee, Rachit and Robbert would all be fantastic advisors with active groups.

My advice on applying to graduate school is this. 

1. You need to tell your story effectively.
2. You need independent supporting data (material that isn't somehow controlled by you).
3. You need to identify some people you would love to work with.  Reading about what they are working on lately really does help.
4. They need to have capacity to take on new advisees, need to have funding to pay them (stipend but also insurance, tuition, university contribution to the union and fees), and you need to look like a strong fit for the positions that are open.  You could be amazing on topic A, but if the only open position involves working on topic B, or in a style you aren't good at, you won't get admitted even with your brilliance on topic A.  And this of course is frustrating because often you cannot know the answers on any of these questions, and just have to hope there will be a fit (and apply to enough programs to achieve a fault tolerant plan).
5. You need to follow the application procedure itself, as documented on the Cornell graduate school web site.

At the MS and PhD level (and Cornell has very few MS students, so PhD is the larger program by far), you are hoping to get a full time, paid job working on cutting edge research questions.  Like any job, you apply through a screening committee -- a company would do this, and graduate school does too.  Then the screening committee shares your application to individual professors.  And at Cornell, actually forming committee -- making your advisor official -- normally doesn't occur until you have been in the department for several months (and sometimes longer).  So your application will be read by a group of faculty and students and not all are in your areas of interest, shown to many faculty who could become advisors, and you may have a zoom interview (or many) before any form of admissions decision is finalized.

There are no shortcuts.  Unlike some academic models where the professor in a group decides admissions, it simply does not work that way at Cornell.  You must follow this standard process.  If the cost of applying is a burden, request a fee waiver -- but follow that standard process no matter what.  Reaching out to individual professors at an early stage won't help much, because the odds are that the individual you email to isn't even on the screening and admissions committee! 

This means that beyond your statement of purpose and your CV and grades, you need this committee to understand the goals and general vision you bring to graduate studies -- not the actual topic you plan to work on (very few students arrive knowing that or even sure of who they will work with!), but a sort of path you hope to follow.  Normally you would be able to identify three or four specific faculty you might work with, and your statement of purpose will not be so much about you personally but rather about the skills and experience you gained that qualify you to work with them, and how you would advance their current projects.

Make sure your letter writers are researchers themselves, or at least very plugged in and aware of what PhD research is like at a cutting edge program.  They need to talk about you as a future researcher, which means helping define new topics, carrying out the work and bringing really innovative insights to it, and delivering great solutions that are also experimentally validated.  The work is hard and you also have to juggle: taking some courses, doing some TA work.  Everyone has that mix -- and these letters are supposed to convince the committee that you have what it takes.

Beyond all this is a question of funding.  In the US the funding levels in computer systems have been variable but generally speaking, are down relative to AI areas or core AI.  So money is tight and in a tight market, being the best qualified candidate isn't helpful if there are no actual jobs open.  The admissions committee will have canvased the faculty to learn about needs: who has funding, what skills are needed, etc.  So in this concept of applying for a job, you are applying for one of those specific jobs -- even though no job opening is really posted except for what you will find on the individual web sites of the faculty in your area.  You won't be admitted even if you walk on water if the professors you are hoping to work with don't have any capacity for new students.  So don't be overly narrow: your goal is to have the committee match you to two or three faculty who need new students, and for everyone in that process including those professors to feel that you sound like a great bet.

Having a fellowship and hence not needing funding is very helpful in many ways, but isn't a factor for those admissions decisions.  They all center on merit.   But being from a famous undergraduate program or having your name on a published paper isn't actually a requirement: we define merit in a more hollistic way that tries to think about the whole person, not a list of achievements.  So don't feel that it is hopeless simply because you graduated from a smaller school and don't have any publications to brag about -- it really isn't hopeless at all!  Just tell your story, in a suscinct and professional way (professional writing is drier than personal emails).  And your intrinisic value will shine through and carry things along!

One last remark: Everyone in this process is getting really tired of AI slop.  They will notice if you use AI to write your essays or if that undergraduate paper was AI-assisted in some heavy sense.  AI to fix grammar is fine.  AI as a research topic is excellent.  But we do not admit AIs into our graduate program.  If you can't make your case without an AI writing the materials, you won't be a success at Cornell, and we won't admit you.  So factor that into your planning!

Good luck!  Perhaps we will meet when you apply to do an internship at Microsoft in SYSML for Frontier Tuning!

 Recent Research (full publications list). 

• Cascade, Vortex.  This pair of systems jointly represent the last big research focus for my group.  The effort split between work on Vortex (which is newer), Cascade itself (more mature) and Derecho (older, mature).  Derecho deserves a longer writeup so it is described below.  Cascade centers on the observation that data movement is a huge overhead in modern AI and ML applications.  How can we run these systems at "peak possible speed" if we have this data movement barrier?    Cutting to the chase, Cascade is often 5x, 10x, and sometimes 20x or 100x faster than other platforms when running identical AI logic!  We gain these huge speedups through a few innovations.
  
  Vortex extends Cascade to include a bunch of specialized features in support of RAG LLM systems where vector databases are a major component (these need to support approximate search).  We haven't published anything on Vortex yet.
  
  We maintain a full project web site here, and our GitHub site is here.  Several slide decks are here.  I'll limit myself to a summary on this page, but you can find links to some papers at the bottom of the Cascade project page and also on our publications list.
  
  One is to offer ways to move the user's AI or ML code into our storage server, so that the code runs right where data is located and can access objects via pointers with no copying needed.  A second idea is to use a mixture of scheduling and planned placement for computing (and for objects created during computation), so that when a computation is needed, the data it requires is collocated at the node where we schedule the AI program to run.  This pays off because the models used by AI programs (ML training results in big parameter vectors called model objects) can be enormous.  The win is even larger for applications doing computer vision, because photos and videos are huge, too. 
  
  One puzzle seen with this example is that it departs from the widely prevalent cloud computing model in so many ways.  Yet there are reasons to believe that applications of this inevitably depart from cloud computing as we do it today.  For example,  in settings where the AI or ML will access sensitive data, it is often important to do that "close" to where the data is gathered and then to either discard the data after computing without ever storing it, or store it only where the user "lives".  The European focus on privacy could mandate this architecture... and the cloud isn't very well-prepared for it today.  Cascade could offer an answer.  A second consideration centers on the wide-area internet link needed to upload data from a camera to a service on a cloud: often, uploads of this kind can be the slowest step. 
  
  We solve these problems by running Cascade directly on hardware close to the edge: a cluster of computers that might sit right in a hospital computing center, or on a factory floor, or in an airplane servicing center.  Then we can also leverage shared memory to reduce data movement between the user's logic and the Cascade data storage layer, and leverage hardware accelerated communication for node-to-node communication.  That last idea uses Derecho, discussed below.  And we do a lot of work on scheduling, to ensure that compute and storage tend to be collocated on the same nodes.
  
  When people talk about storage, it is common for them to mean "in a scalable file system".  Cascade is very flexible in this sense.  It can be used as a file system through POSIX file system APIs, but can also be used as a key-value storage layer (like MemCached), or treated like a pub-sub system (similar to Kafka).  In fact our APIs are often identical to standard tools in those different areas.  Use whichever storage abstraction layer you prefer!
  
  When configured this way edge cameras can be connected directly to the same machines where the user's AI logic is running.  But we also want Cascade to look very transparent to the AI designer: platforms like PyTorch, Tensor Flow, Julia, Apache Spark/Databricks, MXNET and so forth are very popular, and we want to be fully compatible with them.  That leads to the view that Cascade should have a second hosting option, as a service on a normal cloud, able to run the user's AI and ML through a function (lambda) model, or in containers.  In work we hope to do during 2024, we'll connect these two options into a single service that would be perceived as a cloud service and yet might manage resources right on the cloud edge.
  
  Slides containing a good summary of our vision are here and a slide deck from a recent talk on consistency models in AI is here.
  
  Now that I've retired from Cornell, I am no longer taking new students on these projects.
   
  
• Derecho. Derecho is a mature system.  We maintain a full project web site here, and our GitHub site is here.  I'll limit myself to a summary on this page.
  
  Derecho looks at ways of leveraging remote DMA (RDMA) technologies to move large data objects at wire speeds, and modern storage technologies to persist data.  Recently we ported Derecho to run over DPDK too (a pure software solution... not quite as fast, but we still set records), and we support normal TCP as well (slowest of all).   Learn more from our ACM TOCS paper here and our two DSN papers, here and here.  A paper on optimizations for small objects based on a methodology called Spindle is here. 
  
  Our newest work on Derecho centers on an implementation of the Collective Communication Library (MapReduce/AllReduce) APIs, sometimes called the CCLs.  Weijia Song completed a Derecho CCL (DCCL) and it substantially outperforms alternatives, notably beating the Open MPI CCL "in its own home stadium", namely on clusters configured as HPC systems!  We get as much as a 2x speedup for AllReduce, for example.  Weijia has not yet written the work up, but you can already use it in the most current Derecho release.  We plan to do a deep integration of DCCL into Cascade soon.
  
  Same comment applies here: if you are a student with a distributed systems, networking or "low level" focus, the Derecho work could be a great opportunity for you to pursue your passion while being relevant to the modern AI-centric world.  And we have lots of opportunities for pushing the work forward.  Some center on a mix of PL, verification and theory, while others are very practical.  Again, reach out to Ken.
  
  
• Derecho Secure Audit Log / BlockChain.  Edward Tremel is extending Derecho to include a novel BFT layer over the object store.  It could be used much like a permissioned BlockChain.  Details soon... but I should note that Edward leads on this and is now a faculty member at University of Augusta.  We are collaborating on this work, but he is the person with the real vision on where to take it.
  
• Using all of this technology for IoT applications, notably in the smart power grid, healthcare, and industrial settings (IIoT).  My group generally has application areas in mind, and in recent years the bulk electric power grid has been a rich source of ideas.  We've also been branching out and thinking about other kinds of environments that are rich in sensors and actuators, such as healthcare and industrial automation (sometimes called "digital twin" systems).   PhD students Alicia Yang, Tiancheng Yuan and Yifan Wang are leading this work, in collaboration with Siemens Corporate Research and in a smart farming setting (a dairy).

Teaching:  

Now that I have retired, I am no longer teaching and in fact the courses I was teaching in 2024 and 2025 are being revamped, so you will need to focus on their web sites to learn about the current versions.

Video links: 

• I keep some videos and pptx files about our work here.
• SOSP '15 History Day talk on fault-tolerance and consistency, the CATOCS controversy, and the modern-day CAP conjecture.  My video is here and an accompanying essay is here. 
• Robbert van Renesse and me discussing how we got into this area of research: here.

Cloud Computing Textbook (last revised in 2012):   

Guide to Reliable Distributed Systems: Building High-Assurance Applications and Cloud-Hosted Services.    Click here to get to slides from the last offering of my course on this topic.  You can use any of those slides for your own classes without needing special permission from me. The bad news is that the material evolves at a breathtaking pace, which is why I keep revising the slides. Natually, this also means that the book is already out of date. I don't have the time to revise it, right now.

Older work. I've really worked in Cloud Computing for most of my career, although it obviously wasn't called cloud computing in the early days. As a result, our papers in this area date back to 1985.

Some examples of mission-critical systems on which my software was used in the past include the New York Stock Exchange and Swiss Exchange, the French Air Traffic Control system, the AEGIS warship and a wide range of applications in settings like factory process control and telephony. In fact, every stock quote or trade on the NYSE from 1995 until early 2006 was reported to the overhead trading consoles through software I personally implemented - a cool (but also scary) image, for me at least! During the ten years this system was running, many computers crashed during the trading day, and many network problems have occurred - but the design we developed and implemented has managed to reconfigure itself automatically and kept the overall system up, without exception. They didn't have a single trading disruption during the entire period. As far as I know, the other organizations listed above have similar stories to report.

Today, these kinds of ideas are gaining "mainstream" status. For example, IBM's Websphere 6.0 product includes a multicast layer used to replicate data and other runtime state for high-availability web service applications and web sites. Although IBM developed its own implementation of this technology, we've been told by the developers that the architecture was based on Cornell's Horus and Ensemble systems, described more fully below. The CORBA architecture includes a fault-tolerance mechanism based on some of the same ideas. And we've also worked with Microsoft on the technology at the core of the next generation of that company's clustering product. So, you'll find Cornell's research not just on these web pages, but also on web sites worldwide and in some of the world's most ambitious data centers and high availability computing systems.

In fact we still have very active dialogs with many of these companies: Cisco, IBM, Intel, Microsoft, Amazon, and others. An example of a more recent dialog is this: a few years ago worked with Cisco to invent a new continuous availability option for their core Internet routers, the CRS-1 series. You can read about this work here.

My group often works with vendors and industry researchers. We maintain a very active dialog with the US government and military on research challenges emerging from a future generation communication systems now being planned by organizations like the Air Force and the Navy. We've even worked on new ways of controlling the electric power grid, but not in time to head off the big blackout in 2003! Looking to the future, we are focused on needs arising in financial systems, large-scale military systems, and even health-care networks. (In this connection, I should perhaps mention that although we do get research support from the government and the US military, none of our research is classified or even sensitive, and all of it focuses on widely used commercial standards and platforms. Most of our software is released for free, under open source licenses.)

I'm just one of many members of a group in this area at Cornell. My closest colleagues and co-leaders of the group are Robbert van Renesse and Hakim Weatherspoon. But the systems group is very strong and broad right now, and the three of us have great relationships and collaborations with many other systems faculty here at Cornell (both in the systems area within CS, but also folks in ECE where we have great ties, MAE, IS, and down in New York City, where a few faculty are members of our fast-growing New York City Technology "outpost" on Roosveldt Island.

Four generations of reliable distributed systems research! Overall, our group has developed three generations of technology and is now working on a fourth generation system: The Isis Toolkit, developed mostly during 1987-1993, the Horus system, developed starting in 1990 until around 1995, the Ensemble system, 1995-1999. Right now we're developing a number of new systems including Isis2, Gradient, and the reliable TCP solution mentioned above, and working with others to integrate those solutions into settings where reliability, security, consistency and scalability are make-or-break requirements. Older Research web pages: Live Objects, Quicksilver, Maelstrom, Ricochet and Tempest projects Ensemble project Horus project Isis Toolkit (really old stuff!  This is from the very first version of Isis). A collection of papers on Isis, edited by myself with Robbert van Renesse, may still be available -- it was called Reliable Distributed Computing with the Isis Toolkit and was in the IEEE Press Computer Science series.

Photo credit: Dave Burbank