Sunday, May 15, 2011

Internet for Formula One

In this article, Ferrari Chairman Luca di Montezemolo discusses some views on the future of Formula One. I believe these views are complementary to classical internet engineering, in which viral media are as common place as networks and their computers.

As it happens, I met Luca di Montezemolo and Piero Ferrari in 1988 at American Service Center in Arlington, Virginia -- where I was working with Bill Story and Mark Hustler as the junior mechanic in the Ferrari service department. Since then I've been to school, where I met the internet, and dove into Software and Systems Engineering head first.

Ferrari remains, for me, an icon of engineering excellence on par with the National Aeronautics and Space Administration (NASA). Each of Ferrari's machines are composed as a whole system in a remarkable way that compares with the most elegant (e.g. Atlas V and Centaur) of our (USA) space flight craft.

As I understand it, the phenomenon that is Ferrari has been created by a team of exceedingly passionate and stubborn people who would not take "it can't be done" for an answer -- not unlike the Atlas Centaur story.

In overview, the killer app for Formula One is a public multicast network for live track telemetry.

A multicast network is able to employ the internet backbone as a broadcast medium. It won't reach the last mile to many data product consumers. It can distribute track telemetry data to producers of data products in statistics and visualization. Data product service networks are exemplified by Amazon EC2.

Given the multicast foundation, a sustainable ecosystem emerges. Services to give me a TCP stream at home, and services to put 3D live telemetry on my mobile, desktop, and PS3. The production of these telemetry data collection and visualization products is an art appropriate to a large, open world of products.

In detail, internet engineering for important media begins with a protocol specification that all producers and consumers share in order to interoperate. The specification is successful when it is complete enough to provide interoperability without proprietary extensions or adaptations. A specification is "viral" when it is published publicly -- as for example via the Internet Drafts process which is highly accessible in an open variety of ways.

As we know well, examples include the internet itself, the web, and many media defined in the Internet Draft and Requests for Comment documents.

In this ideal telemetry data network, a multicast communication channel is broadcast to all telemetry data consumers listening to a network address and port number.

Multicast network addresses are Internet Protocol address numbers, for example "", and must be employed sparingly. Each network address has a fixed quantity of about 60,000 port numbers.

Therefore a track could be a network address, allocated and published dynamically, and have many port numbers for data products.

Each telemetry stream on a network port number could be specific to a car or data type.

When these telemetry data streams are not encrypted, their utility as public media (re publicity & viralness) is maximized. A publishing of public keys and the signing of telemetry data packets is necessary to the integrity of the telemetry data streams.

The network address and port number and data type are published out of band (not in multicast). HTTP is a good match, here. Public utility is maximized when there is a single way of doing this, a directory, and this is done in a well defined way for both producers and consumers of the directory (via specification).

The directory would need to control telemetry data producers with access control in order to deliver reliable and relevant information to consumers. The directory is a utilitarian component of the ecosystem, and would not need an attractive or appealing user interface as it would be transparent to data product consumers.

Next the content of data on the multicast network would need to be specified in a collection of formats for all telemetry data types.

The typical solution found across media and industry is a variation on the tagged data format. A byte identifies the format of subsequent bytes. This family of formats may be exemplified by the ASN.1 and its transfer formats.

How many kinds of data can be produced by track telemetry systems? What are they? How many update frequencies do they have? Across the internet?

Typically once per second is a practical limit. A single modest computer at the track could collect and serve this stream to the internet. Redundancy adds these pairings of internet connection & server.

In conclusion, excellence in commerce and engineering marries vision with sustainability and efficiency. Superior sustainability for long term stability is necessarily derived from an extraordinary degree of openness. The import is to partner with the world in an open way, inviting the world to partner with you. This is viral media.

One argument against may be the preservation of brand, for example that of "Formula One". However, the brand is identified in the product consumer user interface and would be protected in conventional ways.

Additional arguments against may be development cost or time to market. These issues may be countered with the benefits of open partnership community, and long term stability.

Implementations get caught up in tools, and projects fall prey to their features or limitations -- in terms of architectural principles and the long term stability of network resources. An open solution lends structure to the problem by publishing practical and complete specifications, and adhering to them in a precise way.