How golf is (and isn’t) like packet data

I am using an analogy to help you to understand a crucial new idea: the ΔQ calculus. This enables us to “keep score” of the “game” of packet data. So for a moment, if you can, forget about telecoms networks. Think instead about… golf.

The essence of the game of golf is the relationship between the movement of a ball and a target hole. The player hits the ball with a club, and the ball goes from the tee to location to location, on down along the fairway.

It then (usually) plops into the hole at the far end, and the score is adjusted.

Balls can get lost

But there is another potential outcome: the ball can also get lost in the bottom of a pond, or fall outside of the course. There is a real possibility of the physical ball you started with never reaching its target, and there are special rules to deal with this exception case.

We grab another ball from our pocket, pretend it’s the same ball, and adjust the score differently. (If you thought sand and water hazards were bad, try crocodiles. I don’t know what the rules say if you lose the golfer, not the ball.)

Keeping score

The game’s score is derived from the number of times the ball is hit. It is easy for a human to observe every ball, and keep track of the score. For each hole there are “good” scores (below par), and “bad” scores (above par), and we aim to optimise the overall score against a competitor over 9 or 18 holes.

Individual hits of the ball don’t count for anything per se; you don’t get a great score by merely whacking the ball as far as possible at each turn. Neither do you win by getting a single hole-in-one whilst making a mess of every other hole.

The score for any one hole is subordinate to a higher goal of winning the round, and that is subordinate to yet higher goals, such as reducing one’s handicap or winning a tournament.

Packets and performance

The parallel between golf and telecoms is that we have packets that are copied over a distance, and sometimes get erased on the way. We don’t care about individual packets, but about whole populations of them. The timeliness with which information is copied defines the network’s performance.

There is then a “score” which is the acceptability of each individual customer’s experience. We have a language of “performance hazards” to classify the risk and incidence of bad experiences.

This “score” in turn result in higher-order goals of interest to the network operator, like customer churn and position in the market “tournament”. So there are relationships between what happens to the packets; the hazards; the user “scores”; the end business “scores”; and a measure of “success”. We would like to model and manage these relationships to maximise “success”.

Both are chancy games

In the game of golf, it’s no secret that there’s a lot of randomness involved. Some might even say that the whole thing is invented by the devil to taunt us with capricious acts of fate.

Packets in networks also encounter a lot of randomness on their journey, since there are queues, as well as other sources of variability, like different routes to take, or virtualised computing resources that you have to wait for.

The essence of the problem domain is how to model this randomness, and relate the randomness of what happens to the packets (“golf balls”) to the variability of the user experience (“score and handicap”).

Metrics of golfing success

In the game of golf we have two sets of metrics. The first set is about the objectiveworld: the dimensions of the course (“425 yards”), and the movement of the ball through it, including the scenario of losing the ball (or the will to play). The second set is about the abstract game: the resulting score for the hole and course, and consequent handicap or tournament rank.

These game rules are subjective values that we impose on the concrete world: to the best of my knowledge, there are no university physics departments building experiments to divine the fundamental nature of golf handicaps. We could invent other golf-like games with different rules.

The ball movement is a continuous process:  an analogue thing that exists in the real world, and is based on distance and direction. In contrast, the score for a hole is a discrete process: just a natural number (1, 2, 3, …).

Metrics of network success

Likewise in packet networks, we have two sets of metrics: packet delay (continuous, based on time), with the additional possibility of loss; and some discrete network-dependent quality of experience.

This QoE metric could be characterised as simply as a yes/no answer to “was the experience acceptable?”. It could also be a richer characterisation of an application outcome against a benchmark. Examples might include the number of video buffering events per hour, the audio quality score of a phone call, or the load time of a Web page.

So in both golf and networking there are “rules of the game” that relate the continuous to the discrete domains.

The critical differences

Unlike golf, you can’t go around tracking every packet. You also can’t go around asking every user “how was it for you, darling?” after every click. (That won’t stop a Big Data consultancy from selling such a system to you.) This lack of observability of the “ball” and resulting “score” is what makes network performance engineering hard.

Also, unlike golf, when we lose a packet we don’t just take a penalty and adjust a score. We can re-send the packet, but it’s a different packet that happens to contain the same payload. Furthermore, losing packets is a vital and good thing: without it packet networking cannot work, as queues could grow arbitrarily long.

So golf and networking share some similarities, but as always, the analogy between packets and physical objects has its limits. The golfer can also give up in frustration, or get fed up with the rain, and go straight to the 19^th hole. Networks can’t turn to gin and tonic when stressed.

How to “keep score” of packets?

To summarise golf thus far:

• We have metrics to capture the physical reality of golf, and the resulting scores.
• We have a set of rules to relate these two domains.
• We have arithmetic and geometry to allow us to calculate “how would my score change if the ball moved over there”.

We want to create similar metrics of network performance and user experience for packet data. We want to be able to relate these, and ask “what if?” type questions. So how can we do this?

∆Q is a model of the “rules of the game” of packet networking. It fixes the core problems we face:

• How to create high-fidelity metrics that capture both the objective reality andthe subjective QoE sense we derive from it?
• How to relate these objective and subjective domains rigorously and robustly?
• How to perform algebra on these metrics, and hence answer “what if?” engineering questions?

To achieve this, we need a new trick in how we “keep score”.

A unified stochastic model

In your standard probability theory, you have a random variable, like “how far will this ball go when I hit it with this club?”. You whack balls, and you get varying distances, and you can represent those as a probability measure. But what if the ball sometimes disappears?

In golf, it’s pretty clear what to do when the ball is lost (you get another one!), and there are rules to deal with how to adjust the score. Yet in networking this loss is all handled as a special case, outside the normal ‘rules’ of existing mathematics, with no standard way of doing so.

(An example of this struggle is in my article on IPX, and how it fails to adequately specify a working phone call due to mis-specifying loss requirements.)

So the way we have been “keeping score” of loss in packet networks is as if it were a separate game with a separate metric. What we need is a way of unifying the randomness of delay with that of loss in a single stochastic model.

A new science of performance

∆Q is a new branch of mathematics sits under probability theory, and unifies terminating events (standard probability) with non-terminating ones. This is a major conceptual advance. It’s not every day that a new and valuable fundamental algebra appears in an established domain.

In golf, there are some things you can’t change, like gravity. There are some that you can change, like the par for the course. In networking there are some things that are set by an external reality that we can’t change, like the speed of light, and others that we have control over, like packet routing and scheduling.

For the first time, the ∆Q calculus lets us separate out those things under our control from immutable constraints. It lets us take control over the trade-offs that must exist. It enables engineering of performance as a first-class activity, not an afterthought.

All this benefit comes from a simple idea: the turning of two distinct things into a whole in one.