0032: Message Timing

Status

Summary

Explain how timing of agent messages can be communicated and constrained.

Motivation

Many timing considerations influence asynchronous messaging delivery. We need a standard way to talk about them.

Tutorial

This RFC introduces a decorator to communicate about timing of messages. It is compatible with, but independent from, conventions around date and time fields in messages.

Timing attributes of messages can be described with the ~timing decorator. It offers a number of optional subfields:

"~timing": {
  "in_time":  "2019-01-23 18:03:27.123Z",
  "out_time": "2019-01-23 18:03:27.123Z",
  "stale_time": "2019-01-24 18:25Z",
  "expires_time": "2019-01-25 18:25Z",
  "delay_milli": 12345,
  "wait_until_time": "2019-01-24 00:00Z"
}

The meaning of these fields is:

All information in these fields should be considered best-effort. That is, the sender makes a best effort to communicate accurately, and the receiver makes a best effort to use the information intelligently. In this respect, these values are like timestamps in email headers--they are generally useful, but not expected to be perfect. Receivers are not required to honor them exactly.

Timing in Routing

Most usage of the ~timing decorator is likely to focus on application-oriented messages processed at the edge. in_time and out_time, for example, are mainly useful so Bob can know how long Alice took to ponder her response to his love letter. In onion routing, where one edge agent prepares all layers of the forward wrapping, it makes no sense to apply them to forward messages. However, if a relay is composing new forward messages dynamically, these fields could be used to measure the delay imposed by that relay. All the other fields have meaning in routing.

Timing and Threads

When a message is a reply, then in_time on an application-focused message is useful. However, out_time and all other fields are meaningful regardless of whether threading is active.

Reference