Email FI identification and resolution with model checking

https://doi.org/10.1016/j.jnca.2011.03.027Get rights and content

Abstract

Internet applications, such as Email, VoIP and WWW, have been enhanced with features. However, the introduction and modification of features may result in undesired behaviors, and this effect is known as feature interaction (“FI”). Among other methods, constraint logic programming and model checking have been adopted to address the two main problems in telephony FIs: detection and resolution.

In this paper, we show that model checking is also suitable to detect FIs in more complex domains and we use Email features as an example. Moreover, FI detection may be simultaneously analyzed by model checking tools.

Finally, we analyze the implementation performance against a number of parties and message types using the CPAchecker tool. Model checking reveals a superior performance against constraint programming, for the case of FI detection with FI occurrence.

Introduction

Nowadays, many Internet applications have been enhanced with several features. The problem occurs when some of these features, working fine alone, interact. That problem is known as feature interaction, or FI for short. FIs have been observed in several Internet applications, such as Electronic mail (“Email”) (Hall, 2000), World Wide Web (“WWW”) (Weiss, 2003) and Voice over IP (“VoIP”) (Lennox and Schulzrinne, 2000).

Example 1.1, Example 3.3, Example 3.4 depict three Email feature interactions.

Example 1.1

Suppose that Alice subscribes to the feature ForwardMessage, as well as Bob, and each feature is configured to forward messages to each other. When a party receives a message, that message will bounce between the two parties forming a loop cycle. This is an undesirable behavior.

Despite the unexpected results, users must decide if FIs represent undesirable interactions, or not. For example, the WWW Refresh feature forms a loop to itself. However, if the web page depicts a clock, Refresh becomes an acceptable interaction.

The increasing number of FIs, and the inconvenience they are causing, led industry and researchers to meet regularly at the Feature Interactions in Telecommunications and Software Systems conferences, 10 of which have been held from 1992 to 2009.

Three basic problems have been studied (Bouma and Velthuijsen, 1994): avoidance, detection and resolution. Avoidance means to intervene at the protocol or design stages to prevent FIs, before features are executed. Due to the distributive characteristic of Internet, where every node is unaware of features subscribed by other users, avoidance is not considered here. Detection aims at the identification of FIs, with suitable methods. In the resolution, actions are exercised runtime over triggered features, which averts FIs.

In this paper we focus on Email FI detection and resolution, with particular interest on the 10 most widely known features (Hall, 2000).

Calder et al. (2003) showed how programming languages, such as Promela (Calder and Miller, 2001), CSP (Hoare, 1978) and LOTOS (Gorse et al., 2006), may be used to specify features. Methods explored so far in FI detection include simulation (Thomas, 1997), model checking (Plath and Ryan, 2000, Calder and Miller, 2001), theorem proving (Gammelgard and Kristensen, 1994) and prediction (Crespo, 2008).

In this paper we adopt model checking approach. Model checking deals with the verification of temporal properties over program models (Baier and Katoen, 2008). Model checking tools generate an output that indicates if the program is safe or not. If the program is unsafe, the outcome is complemented with a counter-example.

To specify feature specifications, we adopted C language (Kernighan and Ritchie, 1978), because it is the choice language for micro-controller and Unix-based systems. Several model checking tools for C programs have been developed. MOPS (Chen and Wagner, 2002) is a single-threaded model checker that addresses program control-flow. CPAchecker (Beyer and Keremoglu, 2009) is derived from BLAST-nowadays discontinued. SLAM (Ball et al., 2010) is a proprietary tool developed by Microsoft. SATABS (Clarke et al., 2005) only tracks predicates on data that may produce spurious counter examples.

CPAchecker allows users to configure how this tool analyzes program models. It also allows to specify temporal properties for verification in a specification file. Despite CPAchecker being under development, we concluded that it is a promising tool for model checking and program analysis.

For FI resolution, two approaches have been adopted, negotiation and phase.

The negotiation approach requires exterior agents or artificial intelligence techniques (Velthuijsen, 1993), which are hardly integrated in model checking.

There are two kinds of phase approaches, double and single. In the double phase approach, services are executed in an isolated environment (Tsang and Magill, 1997): the distributed characteristic of the Internet makes unsuitable the double phase approach.

In the single phase approach, a feature manager decides which is the service that is executed, based on the information stored in a data structure of a certain type. Different data structures have been reported in the literature and, among them, we refer tables to express a list of feature priorities (Homayoon and Singh, 1998). This approach needs to know party states, which is not possible on the Internet. However, this is required by model checking, therefore, this is the approach we adopted in our work.

Several works have been published in this area. Hall (2000) showed how the growth in the number of features in Email increased FIs. Plath and Ryan (2000) used SMV model checker tool to verify a lift system together with five features and their interactions. They also detected telephony feature interactions. The FIs of phone services were also detected with the model checker's tool SPIN (Calder and Miller, 2001). Both works focus only in the control of services, which is limited in relation to Internet application services. In our work, we focus on Email features, which are more complex than telephony features: message contents may be changed by ciphering features and message parties may be masked by remail servers.

CPAchecker brings the possibility of using C programming language to identify and resolve FIs. This is the motive behind our choice, once C is a familiar programming language. Moreover, in this paper we show that FI resolution and FI detection may be integrated under model checking technique.

Our approach detects and resolves FIs off-line. On-line resolution through feature elimination is described elsewhere (Crespo et al., 2007).

Section snippets

Overview of paper

Section 3 presents a way to detect FIs with CPAchecker, and depicts some definitions needed to reach this detection. Section 4 lists the modifications required to resolve FIs. Finally, Section 5 analyzes the tool performance, considering different numbers of parties and message types.

FI detection

The FI detection is divided according with the type of messages processed:

  • Simple, i.e., without any change in the message. As example we have FM–FM (see Example 1.1), where FM—ForwardMessage resends incoming messages to another party.

  • Ciphered, i.e., the feature changes the message contents. As example we have the DM–FM case (see Example 3.3), where DM—DecipherMessage restores the original message if its subscriber owns the public key previously used to key encrypt the message.

  • Server. As example

FI Resolution

Resolution is guided by FIs detected before, see Section 3. There are two approaches to resolve FIs. The first disables one of the features that interacts, the second modifies the feature's specification. Due to simplicity, we disable features.

To eliminate undesirable behaviors, we adopt the single phase approach (see Section 1.2). We identify two classes for FI resolution, according to the number of parties subscribing to the features: by priority and by tail elimination. Priority elimination

Performance

To analyze the performance of the CPAchecker, the tool was executed with a number of participants between 3 and 11. The tool was tested on a PC running Linux core 2.6.32 with a Intel Core2 duo Centrino and 2 GB of RAM memory. Because model checking tools scan all parties for feature subscription, in our tests only A and B parties subscribe to features.

Figure 6 only depicts VS–RM processing time. The results for DM–FM and VS–RM cases are similar.

The observation of execution times leads to the

Conclusions

In this paper we demonstrate that model checking is powerful enough to identify, and to resolve, complex Email features.

The improvement of the adopted model checker tool, CPAchecker, mainly at the specification file, could increase the analysis automation and application of our approach to other Internet applications.

Acknowledgments

We gratefully acknowledge the members of the Communications and Services research group, at the University of Stirling/Scotland, for the insights that have made this paper possible. In particular, we thank Prof. Kenneth Turner for all support.

This work was partially supported by FCT (INESC-ID multiannual funding) through the PIDDAC Program funds, and project PTDC/EEA-ELC/66472/2006.

References (25)

  • M. Calder et al.

    Feature interaction: a critical review and considered forecast

    Computer Networks

    (2003)
  • R. Crespo et al.

    Distributed resolution of feature interactions for internet applications

    Special Issue of Computer Networks on Feature Interactions in Emerging Application Domains

    (2007)
  • C. Baier et al.

    Principles of model checking

    (2008)
  • T. Ball et al.

    SLAM2: static driver verification with under 4% false alarms

  • Beyer D, Keremoglu M. CPAchecker: a tool for configurable software verification. Technical Report, SFU-CS-2009-02,...
  • D. Beyer et al.

    Predicate abstraction with adjustable-block encoding

  • L. Bouma et al.
  • M. Calder et al.

    Using SPIN for feature interaction analysis—a case study

  • H. Chen et al.

    MOPS: an infrastructure for examining security properties of software

  • E. Clarke et al.

    Satabs: sta-based predicate abstraction for ANSI-C

  • Crespo R. Detecting and resolving email feature interactions through constraints. IET Software; 2011 (accepted for...
  • R. Crespo

    Predicting feature interactions by using inconsistency models

    Computer Networks

    (2008)
  • Cited by (0)

    1

    Fax: +351 213186988.

    View full text