# Letter to Shepherd

Dear Doug,

Thank you and the other reviewers for the many valuable comments! We appreciate your effort shepherding our paper.

We will revise the paper to address all issues raised in the PC summary. Moreover, we will try to address the remaining points from each reviewer. Here we summarize the major changes we’re proposing. We are also including point-to-point responses to all of the comments in the attached document. The document groups reviewer comments into similar concerns, and at the end of each grouping, we describe the changes we intend to make in the paper to address the concern.

Given the proposed additions, we would like to kindly ask for an additional page.

We will send our first draft to you by Aug 22. Does this work for you?

Best,
David

## Summary of Main Changes

### Clarify Orchestrators' Architecture

* We will update the Introduction and Background & Motivation sections to clearly describe and explain that orchestrators are logically centralized and standalone services, and that they're likely distributed as reviewers pointed out
* We originally intend “centralized” to mean that orchestrators are logically centralized and standalone. However, given reviewers' comments, we agree that “centralized” is confusing in this context, and we'll change to use "standalone".

### Clarify Actual Differences in Unum's Design

* We will update the Introduction and Design sections to highlight and clarify Unum's design differences compared with standalone orchestrators. Specifically, we will emphasize that Unum moves orchestration to an application-level library that is built on top of existing serverless services and runs in-situ with functions.

### Articulate Unum's benefits

* We will revise and clarify all claims about Unum's benefits, including flexibility, performance and costs
* We will revise the Introduction and Background & Motivation sections to clearly explain how Unum's design improves flexibility, performance and costs.

### New Details on Retry Failed Work
* We will explain in the Design section how Unum retries failed functions as long as the FaaS engine provides a way for applications to catch exceptions and regain control, such as Lambda's failure destination or automatic retries. We will detail how Unum restarts failed functions on AWS and Google Cloud in the Implementation section.

### New Discussion on Access Control and Rate Limting
* We will add a discussion on how existing orchestrators, such as Step Functions, work with separate services, such as AWS IAM, to enforce access control, and how Unum can implement similar access control by setting the permissions on the entry function of workflows.
* We will also discuss how Unum can implement rate limiting by changing the concurrency limit on the entry function of workflows.

### Expand ExCamera Evaluation as a Case Study with Additional Discussion on Monetary Costs
* The new section will expand on architectural differences between ExCamera, gg, Unum and Step Functions
* The new section will additionally compare and discuss monetary costs of running applications in relation to the architectural differences.