During the execution of the Reowolf project over the past years, we have discovered a deep and interesting technique, that we would like to share with the wider community. Over the course of the past months, we assembled a small team (comprising Dalia Papuc, Benjamin Lion, Hans-Dieter Hiep) and intensively worked together to create a prototype and write an article about our discovery. This blog post summarizes what we’ve done in the past and what we have accomplished.

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!