We submitted an article to the PLDI 2022 conference, but unfortunately the article was rejected. The version we submitted can be accessed in full below.

We found the reviews very helpful for improving our article (and project!) over time. For full disclosure, here are a couple of the reviews we received.

Review 1

Overall merit: Reject

Reviewer expertise: Some familiarity

Paper summary: The paper presents a formal protocol specification language in the spirit of synchronous languages like Esterel. The protocol designer describes sets of possible inputs and outputs produced by each component at every logical clock cycle. The behavior of the system is determined by the intersection of traces of system components. The main advantage of such formalisms is compositional semantics, which comes at a cost: similar to other synchronous languages, one can express behaviors in Reowolf that cannot be easily implemented, e.g., a pair of components whose output in each cycle depends on the other component’s output; hence the Reowolf runtime must perform a form of constraint solving to determine the set of inputs and outputs at each step.

Comments for authors:

This looks like an interesting formalism that may in the future have practical applications in networking and distributed systems. However, more work is needed to realize this potential, most importantly: (1) support for real distributed systems with complex failure modes, (2) evaluation using a range of real applications, (3) presenting the language and the system in a way that would make its benefits accessible to networking researchers and practitioners.

As it stands, it is not clear that Reowolf solves real problems in networking, or at least the paper does not make it clear that it does. In particular, it does not explain what types of distributed applications can be implemented using Reowolf. What does the API look like? How does one define a protocol and interact with it in practice? Moreover, Reowolf’s implementation is on top of a consensus protocol with a centralized leader. It does not seem to handle reconfigurations, member failures (transient or permanent), partitioning, i.e., all the things that make networks and distributed systems difficult to program. Overall I have the impression that this is a potentially useful language for programming local component-based systems or possibly even electronic circuits, but not necessarily asynchronous networks, at least not as a general replacement for socket-based programming.

The paper does not present any real applications or performance results, which makes it even harder to evaluate the practicality of the proposed solution.

A comment on related work: the oracle problem in Reowolf reminds me of the constructive causality semantics in Esterel. Can you explain how your approach compares to Esterel and other synchronous languages? As far as I understand their solution is to restrict the set of programs to ones that can be efficiently implemented in a sequential language (without constraint solving or look-ahead).

Review 2

Overall merit: weak reject

Reviewer expertise: Some familiarity

Paper summary: This paper proposes Protocol Description Language (PDL), a language to describe sessions between different parties in a network. The design goal of PDL as stated is to provide a high-level and compositional alternative to BSD sockets. The language is given a pair of idealistic semantics that relies on oracles, and a realistic/implementable semantics that operationally constructs these oracles for a subset of PDL programs. The final contribution of the paper is to implement the realistic semantics on top of a distributed runtime instead of a shared-memory one.

Comments for authors:

While I like the idea of a high-level language to describe protocols, my main concerns with this paper is in terms of presentation. I had a hard time following the motivation and understanding what the contributions of the paper are.

• First, in the introduction Reowolf is presented as an alternative to BSD sockets. Reading that I expected the rest of the paper to present some sort of higher-level API to sockets, or a way to translate high-level Reowolf protocols to low-level socket implementations. As far as I can tell, the paper really presents a formalization and its more of a vision on how networked protocols should be programmed rather than an actual alternative. Maybe I misunderstood, but it is important to clarify whether someone can use Reowolf as an alternative to sockets in their real-world application.
• The paper mentions that Reowolf is heavily inspired from Reo, but there is very little context about Reo in the paper, other than a small paragraph that mentions that Reowolf is sequential as the only difference. I think it would help the readers if the delta with Reo is more thoroughly addressed. Do the two languages share the same syntax? Are there programs that you can write in one but not the other? Is Reowolf somehow enabling the implementation of the realistic semantics/distributed semantics?
• For language design papers, I really appreciate seeing some examples that demonstrate 1. why this language is better than existing solutions if any, 2. how that language simplifies (some aspects of) the problem, e.g., is it much easier to express the same protocol in this language rather than with sockets? Is it easier to verify programs? Or maybe, is compilation to efficient implementations simplified? The paper mentions that protocols written in PDL are more suitable for verification and proofs of security properties are tractable, yet no proof technique or an example proof is shown as evidence to this claim.