Progress in science is not linear and is hardly predictable: our discovery was not planned for during the execution of the Reowolf project, but we believe now is a showcase of a number of important aspects of our work. First, we figured that the concept of synchronization is essential and central to our project, and we now have a very clear idea of what synchronization in communication systems means. Second, we found that it is always possible to challenge an established field of study, in our case Information Theory: we’ve studied the fundamental assumptions underlying this field, which potentially opens up new avenues of research and development. Third, and lastly, the outcome of research comes at an unexpected moment: that is what makes doing research such an exciting activity!

In the Reowolf project, we originally set out to replace BSD sockets by Reowolf connectors, for numerous reasons we outlined before. We still believe in pursuing this end, but we’ve learned that doing so effectively requires bringing more convincing arguments to the table. After implementing two prototypes (Reowolf 1.0 and Reowolf 2.0) in which we experimented with many different set-ups and approaches, and writing an article about our approaches, our conclusion was: we need a realistic supporting use-case. Thus, we started looking for a so-called “killer app” that can demonstrate why connectors are superior to sockets.

During our work on the semantics of Reowolf’s Protocol Description Language (PDL), we became aware that all our components are so-called time-sensitive. More generally speaking, for every component that is present in a communication system (whether ‘low-level’, i.e. handling the encoding and decoding of messages communicated over channels, or ‘high-level’, i.e. protocol components that implement e.g. packet-switched networks or communication sessions with transmission control), there is always a (hidden) dependency on time. But, as it became clear to us, this insight is not as obvious as it is now in hindsight.

The fundamental problem with sockets is that sockets abstract away time: the application programmer who writes socket-based applications must manage time entirely by herself. This seems the logical thing to do in asynchronous networks, such as the Internet: what does “time” even mean in such an asynchronous setting? Now that we have realized that all components are time-sensitive and need to synchronize, our motto became: synchronization is necessary before communication is possible. But then, what is easier? Programming with synchronized connectors or programming with asynchronous sockets? Maybe we can demonstrate this point with our killer app! So, without further ado: here is the discovery (the “killer app”) we made:

In this article we describe a novel technique for increasing the effective capacity or increasing the end-to-end privacy and security of communication channels using high-resolution clocks.  Under specific conditions more data may be sent on channels than is traditionally the case, by means of advanced synchronization and packet delivery scheduling algorithms.  This may alleviate the need for capital investment for extending bandwidth for Tier 2 or Tier 3 network operators, who are purchasing Internet Protocol (IP) transit to connect with remote networks.  Alternatively, this technique may be used by end-users of the network to increase the end-to-end confidentiality beyond classical encryption techniques, without the need for adapting the underlying transit networks.

So, let us jump ahead and give the protocol realizing our novel technique a name: Time Modulation Protocol, or TMP in short.  The essence  of TMP is this:  instead of sending  data (a sequence of bits) contained in packets over the Internet from one party to another, we instead ensure  that the two parties have synchronized clocks and transmit data by merely sending a signal and reading off the clock value at the moment of reception of the signal.  No longer data is present in the transmitted message (as a bit sequence), but instead is transmitted at the moment a signal is received: the value of the clock on the receiving side then is the value of the message.  This ensures that the content of the communication can no longer be sniffed by a man-in-the-middle if such an attacker does not know the parameters of the clock synchronization between the parties, but it also ensures that metered links under-report the information content of the message.

We compare two little programs, one based on Reowolf’s time-sensitive Protocol Description Language and the other on the time-insensitive BSD sockets. The purpose of this program is to implement a time-sensitive channel between two parties. One party sends merely a signal to the other party: the signal is meaningless to anyone seeing the traffic between the parties (if unaware of the synchronization between the parties). At the moment the signal arrives, the clock value at the recipient is significant and allows the receiver to interpret the signal as a message.

In a simplified setting of implementing this time-sensitive protocol in PDL, we write the transmitter and receiver components as follows:

primitive void transmitter(boolean msg, out<void> p) {
  if (msg) put(p, ()); // send signal
  sync; // let clock tick
  if (!msg) put(p, ());
  sync;
}
primitive boolean receiver(in<void> p) {
  boolean result = false;
  if (let x = get(p)) result = true; // if signal was received
  sync;
  if (!result) get(p); // signal must be received now
  sync;
  return result;
}

We now let a transmitter component and a receiver component run, one per side of a channel that connects the two components. The semantics of the PDL-program above is as follows: the transmitter wishes to send a true or a false. To send true, it immediately sends a signal over the channel (in the current clock interval). Otherwise, the transmitter lets the clock tick, and sends a signal after the clock has progressed (in the next clock interval). The receiver (that is synchronized with the transmitter) tests whether it has received a signal in the current clock interval and determines the value of the result: if no signal was received, it progresses to the next clock interval and again tests whether it has received a signal. Both the transmitter and the receiver have progressed two clock intervals at the end. Note that there are two error conditions:

• The receiver receives two signals (on both clock intervals).
• The receiver receives no signal (on both clock intervals).

We say that the two components are synchronized if running these two components with some particular clock speed over some channel is reliable: the outcome of the receiver is no error, and the result of the receiver is equal to the input of the transmitter. Indeed, to establish the synchronization between two parties in the first place, we could be running this simplified protocol and tweak the synchronization parameters (e.g. delay-adjusted clock precision) until the two components behave reliably!

Now, the runtime of Reowolf guarantees that an underlying synchronization algorithm exists which guarantees that this transmission is reliable. Imagine implementing such a synchronization algorithm manually using sockets! Writing a program using sockets requires significantly more effort: the programmer must manage the clock synchronization entirely herself, which is error-prone.

More details about the mathematics of synchronization and time-sensitive communication can be found in the article we wrote (see below). In that article we also present more detail about the Time Modulation Protocol, which is essentially a sophisticated version of the simple program above.

The source files of our prototype based on sockets is available in this public GitHub repository. The article we’ve written over the past months, giving more details on our discovery, is available below:

In the coming week, we prepare and submit a condensed version (adapted to the particular audience of the publication venue) of the article to the FSEN 2023 conference for multiple reasons:

• We believe our discovery is important enough to share widely.
• We want to establish a consensus on the basic set of (mathematical) concepts, on which we can further development of our project.
• We wish to obtain expert feedback from different academic fields of expertise. This allows us to receive critical viewpoints that we, ourselves, may have missed. Science is all about being proven wrong: and we are very much open to criticism.

Research never stops, so we will keep you updated when we’ve made more progress!

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.

Programming Internet applications has essentially remained unchanged since the1980s. The Berkeley Software Distribution (BSD) implementation allows applications to create sockets for communication over the Internet, e.g. Transmission Control Protocol over Internet Protocol (TCP/IP), that either listen for incoming connections or are connected outward, resulting in a bi-directional, reliable channel between two peers on the outer edges of the network. Applications consequently control the stream of data into the sending side of a channel, to be received in order by the other side of the channel. Although applications of the 1980s were process-driven, performing send and receive operations by cooperating with an operating system responsible for scheduling application processes. More recently, applications have become event-driven, allowing for more fine-grained scheduling decisions by applications themselves. However, the essence of programming Internet applications remains based on controlling a channel be-tween two peers in a network…

Full article available on CWI’s Institutional Repository.