Application Classes

It is unlikely that all devices may be able to support encryption (as corroborated by our experiments). Also not all applications may demand encryption of data transmitted over the network. Hence, we hereby address the concerns of application developers, considering some specific applications.

In general, performance of the encryption algorithm is more critical in real-time applications. We divide real-time (RT) applications into the following classes:

• Soft real-time applications with Constant Bit Rates (CBR). Eg: Audio.
• Soft real-time applications with Varying Bit Rates (VBR). Eg: Video.
• Hard real-time applications. Eg: Real-Time stock quote retrieval, control systems etc.

We consider each of these classes in turn.

Soft Real-Time Applications with Constant Bit Rates (CBR).

A most typical example that falls in this category of applications is that of audio transmitted over the network. Audio data is typically required to be streaming into the audio mixer at the host device at a constant rate of say $C \ bits/sec$. Usually, $14-18 \ kbps$ is sufficient for high-quality audio playout. We also considered the case of PCM (Pulse Coded Mixer) audio, for which $C = 64 \ kbps$.

The analysis for applications in this class is simple: If C is less than R, the maximum sustainable rate of encryption at that device, by a significant amount, then audio data can be always encrypted.

Soft Real-Time Applications with Varying Bit Rates (VBR).

Sometimes, it is difficult to predict the exact rate of data used by the application. A typical example is the case of video data being received over a network in a distributed real-time application. In such case, it is not unusual to employ a buffer to ensure continuous playout of video. We consider some MPEG video traces as representative of applications in this category.

MPEG Video Analysis.

We used CODEC [Codec], a MPEG-2 video decoder for our analysis. We used the traces of a few MPEG videos with characteristics as given below

Name	Length (Secs)	Size (MB)	Rate (Frames/Sec)
PSYCHO	53.97	9.36	30
WALL	25.1	3.58	30
HIGHLANDER	17.13	3.22	30

We then analyzed the time taken for decoding versus the time taken to decrypt the same video trace on each device. We first computed the time taken to decode the entire video trace (assuming the CPU is devoted entirely to decoding), T_D. We then computed the time taken to decrypt the encrypted video trace (assuming the CPU is devoted entirely to decryption), T_E.

If decryption employs only a minor fraction of the resources employed by decoding i.e if $T_E \ll T_D$ for all devices, then we can conclude that video data transmitted over the network in a personal environment can always be encrypted.

The devices considered for the MPEG Video Analysis are the UltraSparc IIi, Pentium-Pro and the Pentium III machines. A PalmPilot was found to simply not accommodate the kind of bandwidth that a MPEG video demands.

Hard Real-Time Applications.

In applications belonging to this category, the main concern is that of the latency of operations. A typical example would be the retrieval of stock quotes in real-time from a web server.

Real-Time Stock Quotes Retrieval.

Let the size of the data transmitted in one instance of retrieval (the analysis remains the same irrespective of whether the data is streaming or not) be D. D could also denote a typical packet size. Let the network latency viz. the time taken for transmission and routing etc be T_N. Let the sum of the time taken for encryption at the server together with the time taken for decryption at the host, i.e, the total time of encryption, be T_E. If $T_E \ll T_N$, then encryption does not affect the real-time performance of the application.

The network latency was computed for 3 cases:

1.

the local intranet,

2.

the internet (www.yahoo.com), and

3.

serial port communication on a PalmPilot.

In our experiments, we used a fixed data size, $D = 1024 \ bits$. For the local intranet, T_N was found using Berkeley sockets and for the internet, the UNIX utility ping was used. An approximate value for T_E was obtained assuming that the server is only as powerful as the host.