Passive Testing on Performance Requirements of ...

Passive Testing on Performance Requirements of Network Protocols Xiaoping Che and Stephane Maag Institut Telecom, Telecom SudParis CNRS UMR 5157 9, rue Charles Fourier, 91011, EVRY Cedex, France Email: [email protected], [email protected]

Abstract—Conformance testing of communicating protocols is a crucial step to the validation of systems and formal approaches provide many keys to test efficiently these protocols. The passive testing techniques are approaches that can be applied when the controllability of the system interfaces is unavailable or when the implementation under test cannot be stimulated in runtime. In this paper, we present a novel logic-based passive testing approach in specifying time related protocol properties to be tested on real execution traces. Based on a new algorithm, a prototype is developed and experienced. In order to evaluate and assess our technique, we present experiments through a set of IMS/SIP properties and execution traces. We finally provide relevant verdicts and discussions. Keywords-Passive Testing; Formal Method; Performance requirements; Session Initiation Protocol;

I. I NTRODUCTION In the recent years, many studies on checking the conformance of an Implementation Under Test (IUT) have been performed. Important works are about the record of the observation during run-time and its comparison with the expected behavior defined by either a formal model [13] or as a set of formally specified properties [6], [12] obtained from the requirements of the protocol. The observation is performed through Points of Observation (PO) set on monitored entities composing the System Under Test. These approaches are commonly identified as Passive Testing approaches. Through these techniques, the protocol messages observed in execution traces are generally modelled and analyzed through their control parts [10]. In [11], [7], we proposed a data-centric approach to test a protocol by taking account the control parts of the messages as well as the data values carried by the message parameters contained in an extracted execution trace. Interesting and promising results were obtained while testing the SIP protocol [15] through some of its functional properties. However, many performance related properties (e.g. package latency, loss rate, etc.) were not specifiable by our proposed formalism. In this work, we thus extend our first proposed methodology to present a passive testing approach for communicating protocols based on the formal specification of the time related requirements and their analysis on collected run-time execution traces. In the litterature, this issue has already been tackled. In [5], the authors present an adaptive performance testing

method for stress testing web software systems, by modelling the system with a two layers Queuing Network Model. Besides, in [4], it is proposed a new measurement-domainspecific language with specialized constructs concerning the automation of measurement procedures. Their technique is based on the Model Driven Engineering concepts and Domain Specific Language solutions. Different from their works on modelling the systems, our work is concerning on formalising the performance requirements by formally modelling functional properties of the IUT in taking consideration of the data values and the timing constraints of the messages in the protocol traces. In Section II, The syntax and semantics of our formalism to describe the tested properties as well as the algorithm checking them on real execution traces are presented. Our approach has been implemented and relevant experiments are depicted. They have been performed through an IMS framework to test SIP properties. The distributed architecture of the IMS allows to assess our approach efficiently by tackling several interesting issues in Section III. Finally, we conclude our paper in Section IV. II. F ORMAL A PPROACH A. Basics A communication protocol message is a collection of data fields of multiple domains. In our previous works [7] [11], data domains are defined either as atomic or compound. An atomic domain is defined as a set of numeric or string values. A compound domain is defined as follows. Definition 1. A compound value v of length n > 0, is defined by the set of pairs {(li , vi ) | li ∈ L ∧ vi ∈ Di ∪ {}, i = 1...n}, where L = {l1 , ..., ln } is a predefined set of labels and Di are data domains. A compound domain is then the set of all values with the same set of labels and domains defined as hL, D1 , ..., Dk i. Once given a network protocol P , a compound domain Mp can generally be defined by the set of labels and data domains derived from the message format defined in the protocol specification/requirements. A message of a protocol P is any element m ∈ Mp . Though our approach proposed in [7] has shown interesting issues, it also raised some issues (e.g. the delay of a message) mainly due to the fact we did not consider time

constraints in the tested protocol properties. We introduce here some timing aspects which answer to these issues. For each m ∈ Mp , we add a real number tm ∈ R+ which represents the time when the message m is received or sent by the monitored entity. Example 1. A possible message for the SIP protocol, specified using the previous definition could be

A0 ← A1 ∧ ... ∧ An where A0 is the head of the clause and A1 ∧ ... ∧ An its body, Ai being atoms.

m = {(method, ‘INVITE’), (time, ‘644.294133000’), (status, ), (f rom, ‘[email protected]’), (to, ‘[email protected]’), (cseq, {(num, 7), (method, ‘INVITE’)})}

where A1 , ..., An are atoms, n ≥ 1 and x, y are variables. In our approach, while the variables x and y will be used to formally specify the message of a trace, the quantifiers commonly define “it exists” (∃) and “for all” (∀).

representing an INVITE request from [email protected] to [email protected]. The value of time ‘644.294133 000’ (t0 + 644.294133000) is a relative value since the PO has started its timer (initial value t0 ) when capturing traces. A trace is a sequence of messages of the same domain containing the interactions of a monitored entity in a network, through an interface (the PO), with one or more peers during an indeterminate period of time. The PO also provides the relative time set T ⊂ R+ for all messages m in each trace.

A formula is defined by the following BNF: φ ::= A1 ∧ ... ∧ An | φ → φ | ∀x φ | ∀y>x φ | ∀yx φ | ∃y (’true’), ⊥ (’false’) or ’?’ (’inconclusive’). Due to a lack of space, we let the interested reader to have a look at [7] for more details.

B. Syntax and Semantics of our formalism In [7], [12], we defined a syntax based on Horn clauses to express properties that are checked on extracted traces. We briefly describe it in the following. Formulas in this logic can be defined with the introduction of terms and atoms, as it follows. Definition 3. A term is defined in BNF as term ::= c | x | x.l.l...l where c is a constant in some domain, x is a variable, l represents a label, and x.l.l...l is called a selector variable. Example 2. Let us consider the following message : m = {(method, ‘INVITE’), (time, ‘523.231855000’), (status, ), (f rom, ‘[email protected]’), (to, ‘[email protected]’), (cseq, {(num, 10), (method, ‘INVITE’)})} In this message, the value of method inside cseq can be represented by m.cseq.method by using the selector variable. Definition 4. An atom is defined as A ::= k }| { z | term = term | term 6= p(term, ..., term) term | term < term where p(term, ..., term) is a predicate of label p and arity k. The timed atom is k }| { z a particular atom defined as p(termt , ..., termt ), where termt ∈ T . Example 3. Let us consider the message m of the previous Example. A time constraint on m can be defined as ‘m.time < 550’. The relations between terms and atoms are stated by the definition of clauses. A clause is an expression of the form

C. Time operator In this work, timing aspects are introduced for performance requirements testing. We formalize the performance requirements to formulas by using the syntax above described, and the truth values {>,⊥,?} will be given to evaluate them. We note that most of performance requirements are based on relative conformance requirements. Example 4. The performance requirement “the message response time should be less than 5ms”, is based on the conformance requirement “The SUT receive a response message”. Once a ‘>’ truth value has been given to a performance requirement, without doubt, a ‘Pass’ testing verdict should be returned for both the performance requirement and the relative conformance requirement, which indicates both the performance and conformance requirements have been satisfied. In the Example 4, if a ‘>’ has been given to the performance requirement “the message response time should be less than 5ms”, it means the SUT received a response message and the response time of this message is less than 5ms, the relative conformance requirement is also sufficed. Nevertheless, if a ‘⊥’ or ‘?’ truth value has been returned, we can not distinguish whether it does not satisfy the performance requirement or it does not satisfy the relative conformance requirement. For instance, in Example 4, if a ‘⊥’ has been given to this performance requirement, we can not distinguish whether it is owing to “The message response time is greater than 5ms” or “The SUT did not

receive a response message”. Moreover, once we have a ‘?’ result, it is tough to eradicate it by seeking the real reason. A method is needed for clearly differentiating the nonpositive results. Since the deviation is from the relative conformance requirement, we can simultaneously evaluate it when we test the performance requirement, and then we combine the results. The new operator ‘?’ is defined for this purpose, it is used to combine the results of different formulas. This operator is applied to determine the final result when non-positive results have been returned to the performance requirements. By using the introduced definitions before, we define the performance requirement and the relative conformance requirement by using ‘ϕ’ and ‘ψ’ respectively, where ψ = {(A1 ∧ A2 ∧ ... ∧ An ) | n ∈ N} and ϕ = {ψ ∧ (At1 ∧ ... ∧ Atm ) | m ∈ N} and Ati = p(termt , ..., termt ), termt ∈ T . The final result can be represented by the formula (ϕ) ? (ψ). Therefore, (ϕ) ? (ψ) is evaluated to > iff both ϕ and ψ are >, evaluated to ? iff both are ? and ⊥ otherwise. We note that the truth value of (ϕ) ? (ψ) is approximately (ϕ) ∧ (ψ). The only two exceptions are when ϕ ≡ >, ψ ≡ ? and ϕ ≡ ?, ψ ≡ >, the results are not ‘?’ but ‘⊥’. For interpreting the reason for the exceptions, we have to trace back to the definition of ‘?’, it only occurs when using ‘∀’ and ‘∃’ on finite traces. The ‘?’ denotes “There does not exist a matching message on current finite trace, but we do not know if it will come true in the future traces”. Since for the performance requirements, we are analysing the performance of current traces and not the traces in the future. Therefore, for the current traces, the ‘?’ is equivalent to the ‘⊥’ which denotes ”there does not exist a matching message on current finite trace”.

Table I: Algorithm for the formalism Algorithm sldSolve(K, S, ρ) Input: Set of clauses K (K1 ). Stack S containing the atoms remaining for evaluation. Substitution ρ with the initial bindings. Output: > if the formula has a solution. 1) if S is not empty then 2) A ← pop(S) 3) solved ← ⊥ 4) for (B0 ← B1 ∧ ... ∧ Bq ) ∈ K where B0 matches with A do 5) renameVars(B0 , B1 , ..., Bq ) 6) α←ρ 7) if unify (A0 , B0 , α) then 8) if q > 0 then 9) push({B0 , B1 , ..., Bq }, S) 10) solved ← sldSolve(S,α) 11) pop({B0 , B1 , ..., Bq }, S) 12) else 13) solved ← sldSolve(S,α) 14) push(A,S) 15) return solved 16) if count! = 1 17) then count ← 1, f inal ← solved 18) do sldSolve(K1 , S, ρ) 19) else f inal ← f inal ? solved 20) return f inal

originally intended to deliver Internet services over GPRS connectivity. The IMS aims at facilitating the access to voice or multimedia services in an access independent way, in order to develop the fixed-mobile convergence.

D. Algorithm An algorithm for evaluating the formulas is provided in [12]. The algorithm uses a recursive procedure to evaluate formulas, coupled with a modification of SLD (Selective Linear Definite-clause) resolution algorithm [3] for the evaluation of Horn clauses. We extend this algorithm by integrating the operator ?, as Table I shows, where K represents the formalized performance requirement, K1 represents the relative conformance requirement. In the worst-case, the time complexity for a formula with k quantifiers will be O(2nk ) to analyze the full trace, where n is the number of messages in the trace. Although the complexity in worst case is important, all of our experiments results (as shown in the following section) have been obtained in a relative short time. III. E XPERIMENTS A. Environment 1) IP Multimedia Subsystem services: The IMS (IP Multimedia Subsystem) is a standardized framework for delivering IP multimedia services to users in mobility. It was

Figure 1: Core functions of IMS framework The core of the IMS network consists on the Call Session Control Functions (CSCF), that redirect requests depending on the type of service, the Home Subscriber Server (HSS), a database for the provisioning of users, and the Application Server (AS), where the different services run and interoperate. Most communication with the core network and between the services is done using the Session Initiation

Protocol [15]. Figure 2 shows the core functions of the IMS framework and the protocols used for communication between the different entities. The Session Initiation Protocol (SIP) is an applicationlayer protocol that relies on request and response messages for communication, and it is an essential part for communication within the IMS (IP Multimedia Subsystem) framework. Messages contain a header which provides session, service and routing information, as well as an (optional) body part to complement or extend the header information. Several RFCs have been defined to extend the protocol with to allow messaging, event publishing and notification. These extensions are used by services of the IMS such as the Presence service [1] and the Push to-talk Over Cellular (PoC) service [2]. 2) SIPp: For our experiments, traces were obtained from SIPp [9]. SIPp is an Open Source test tool and traffic generator for the SIP protocol, provided by the Hewlett-Packard company. It includes a few basic user agent scenarios (UAC and UAS) and establishes and releases multiple calls with the INVITE and BYE methods. It can also read custom XML scenario files describing from very simple to complex call flows. It features the dynamic display of statistics about running tests, TCP and UDP over multiple sockets or multiplexed with retransmission management and dynamically adjustable call rates. It also support IPv6, TLS, SIP authentication, conditional scenarios, UDP retransmissions, error robustness, call specific variable, etc. SIPp can be used to test many real SIP equipments like SIP proxies, B2BUAs and SIP media servers. The traces obtained from SIPp contain all communications between the client and the SIP core. Tests were performed using a prototype implementation of the formal approach mentioned above, using the algorithm introduced in previous Section II-D. 3) Architectures: In our experiments, ad-hoc based environment has been implemented and tested, for satisfying the need of variability on the data traffic. The structure of our environment is shown below: two laptops (User Agent

simulate two scenarios for the data traffic: one is the data traffic under normal condition (called normal for short), which means sufficient bandwidth is provided and quite few re-transmissions occur; while the other one is under high data traffic congestion (called high for short), which simulate the condition that numerous users are calling at the same time, where numbers of re-transmission and packet lost occur. Two sets of traces (normal and high) have been collected for the following experiments. B. Formalization of properties and results In this section, conformance and performance properties collected from RFC 3261 are formalized as formulas. They are evaluated through numerous execution traces, and the testing verdicts Pass, Fail, Inconclusive corresponding to >, ⊥ and ’?’ are provided in the following. 1) Property1 : For every request there must be a response, each response should be received within T1 = 0.5s: Property:: This property can be used for a monitoring purpose, which reflects the current traffic condition. Due to the issues related to testing on finite traces for finite executions, a f ail verdict can never be given for this context. However inconclusive verdicts can be provided and conclusions may be drawn from further analysis of the results. As mentioned in the section before, this performance property has to be formalized on the basis of conformance property ‘For every request there must be a response’, which is as follows: ∀x (request(x) ∧ x.method = ‘ACK’ → ∃y>x (nonP rovisional(y) ∧ responds(y, x)))

(1)

where nonP rovisional(x) accepts all non provisional responses (non-final responses, with status ≥ 200) to requests with method different than ACK, which does not require a response. The response time for each request is a crucial indicator for performance, and based on the previous quantifier, the performance property can be formalized as follows (T1 represents the timer for re-transmission): ∀x (request(x) ∧ x.method = ‘ACK’ → ∃y>x (nonP rovisional(y) ∧ responds(y, x) ∧withintime(x, y, T1 )))

(2)

where withintime is defined as withintime(x, y, T1 ) ← y.time < x.time + T1

Figure 2: Ad-hoc environment Client) and a table PC (User Agent Server) have been used in the experiments, and the traffic is collected from the UAS as a PO. In the traces we collected, only the information of Session Layer has been used in our experiments. We

Results in normal conditions:: Initially, we used the normal traces to test the properties, the results are as follows: From the results, we can use the operator ‘?’ for determining the final verdict. The result for ‘f ormula(1) ? f ormula(2)’ is illustrated in the Table IV. As expected, most traces show only ‘Pass’ verdicts for the property evaluation. However, still three inconclusive

Table II: For every request there must Table III: For every request there Table IV: Final verdict for property 1 be a response (normal) must be a response within T1 = 0.5s (normal) (normal) Trace Messages Pass Fail Inconclusive Time(s) Trace No.of messages Pass Fail Inconclusive 1 2 3 4 5

500 1000 1500 2000 2500

150 318 504 674 798

0 0 0 0 0

0 1 1 0 1

0.886 1.581 2.147 2.835 3.469

Trace Messages Pass Fail Inconclusive Time(s) 1 500 150 0 0 1.468 2 1000 318 0 1 1.714 3 1500 504 0 1 2.335 4 2000 674 0 0 2.919 5 2500 798 0 1 3.576

verdicts can be observed from the final results. Thoroughly looking at trace 2, this inconclusive verdict corresponds to the INVITE message, this message is at the end of the trace, which could indicate that the client closed the connection before receiving the corresponding response message. The same phenomenon occurs for trace 3 and 5. Results in high conditions:: After analyzing the traces under normal condition, we step to test the traces under high condition, the results are showed as follows: Non-positive verdicts can be seen from the two Tables V and VI. In Table VI, it means that no responses (y in the formula (2)) have been found till the end of the trace. This reveals a ”Fail” as it is illustrated by ‘f ormula(1) ? f ormula(2)’ in the Table IX. From that table, “Fail” verdicts indicate the messages which received by the SUT have obviously exceeded the expected time ‘T1 ’. More crucially, different from the “0” fail verdict in the normal condition, we can observe numbers of fail verdicts in the high condition with the help of the ‘?’ operator. These results confirm the usage of the operator in testing performance properties. Further tests revealed that different values of T1 result on the number of ”Fail” verdicts illustrated in the Table VIII and Table X. As we increase the value of T1 , the number of ”Fail” verdicts decrease progressively. This indicates that increasing the value of timer will lead to less retransmission. Besides, since in SIP, different value of T1 corresponds to different frequency of re-transmission of a message, varying the value of T1 can be used to detect the frequency of retransmission of specific messages. 2) Property2 : Session Establishment Delay: Property:: This property is used for monitoring the delay of establishing a session. This performance property is based on the establishment of a session which is formalized to the conformance property ‘For each INVITE request there should be a 2xx response, if the session has been successfully established’, as follows: ∀x (request(x) ∧ x.method = ‘INVITE’ → ∃y>x (response(y, x) ∧ y.statusCode = 200))

(3)

and the performance property “Session Establishment Delay” (with Ts = 1.5s) can be expressed as: ∀x (request(x) ∧ x.method = ‘INVITE’ → ∃y>x (response(y, x) ∧ y.statusCode = 200 ∧withintime(x, y, Ts )))

(4)

1 2 3 4 5

500 1000 1500 2000 2500

150 318 504 674 798

0 0 0 0 0

0 1 1 0 1

Results in normal conditions:: Initially, we use the normal trace to test the properties, the results are as follows: From the Table XI, numbers of inconclusive verdicts can be observed. As we penetrating deeply into these verdicts, most of them are caused by the “403 Forbidden” response. For confirming this conclusion, we test the property “For each unsuccessful INVITE request there should be a 403 response”, the result confirms our predication. It returns 10, 18, 36, 53 and 51 ‘Pass’ verdicts for the five traces, which corresponding to the number of inconclusive verdicts in Table XI. Similarly to the previous property, the results for ‘f ormula(3) ? f ormula(4)’ can be illustrated in the Table XII. As described before, most of the inconclusive verdicts are caused by “403” responses, and no “Fail” verdict occurs under this normal condition. Results in high conditions:: For drawing further conclusions, we test this property under high conditions. Table XIV and XV show the results. Finally, as Table XVI shows, the results return several ”Fail” verdicts for each trace. These verdicts indicate the sessions have been successfully established, but exceeded the required time Ts = 1.5s. On the contrary, when we increase the value of Ts to 5s, no ”Fail” verdicts are observed (Table XVII). This denotes that for all the established sessions, the session establishment time is less than 5 seconds. Moreover, these results indicate that we can count the range of session establishment time by varying the Ts . This can be used for the performance monitoring purpose in future works. IV. C ONCLUSION This paper introduces a novel approach to passive performance testing of network protocol implementation, with a particular focus on time related requirements. This approach allows to define relations between messages and message data, and then use such relation in order to define the performance properties that will be evaluated on the trace. The evaluation of the property returns a pass, f ail or inconclusive result, derived, respectively on the given trace. For non-positive verdicts, a ‘?’ operator is introduced to combine the results of two properties in order to obtain a final testing verdict. To verify and test the approach, we design two properties for the evaluation. The approach has

Table V: For every request there must Table VI: For every request there Table VII: Final verdict for property be a response (high) must be a response with in T1 = 0.5s 1 (high) (high) Trace Messages Pass Fail Inconclusive Time(s) Trace No.of messages Pass Fail Inconclusive 1 2 3 4 5

500 1000 1500 2000 2500

33 85 187 427 535

0 0 0 0 0

322 636 872 1014 1308

9.210 26.265 58.896 95.210 179.423

Trace Messages Pass 1 500 20 2 1000 34 3 1500 56 4 2000 101 5 2500 103

1 2 3 4 5

Fail Inconclusive Time(s) 0 335 8.677 0 687 27.116 0 1003 62.928 0 1340 118.699 0 1740 213.171

Table VIII: Pass Verdict table for different time intervals

500 1000 1500 2000 2500

20 34 56 101 103

13 51 131 326 432

322 636 872 1014 1308

Table IX: Final verdict for property 1 (high)

Trace No.of msg Without T1 T1 (0.5s) 2T1 (1s) 4T1 (2s) 8T1 (4s) 16T1 (8s) 32T1 (16s) 1 500 33 20 33 33 33 33 33 2 1000 85 34 57 85 85 85 85 3 1500 187 56 79 174 187 187 187 4 2000 427 101 213 405 427 427 427 5 2500 535 103 184 451 534 535 535

Trace No.of messages 1 500 2 1000 3 1500 4 2000 5 2500

Table X: Fail Verdict table for different time intervals

Pass 20 34 56 101 103

Fail Inconclusive 13 322 51 636 131 872 326 1014 432 1308

Table XI: For each INVITE request there should be a 2xx response (Normal)

Trace No.of msg Without T1 T1 (0.5s) 2T1 (1s) 4T1 (2s) 8T1 (4s) 16T1 (8s) 32T1 (16s) 1 500 0 13 0 0 0 0 0 2 1000 0 51 28 0 0 0 0 3 1500 0 131 108 13 0 0 0 4 2000 0 326 214 22 0 0 0 5 2500 0 432 351 84 1 0 0

Trace 1 2 3 4 5

Messages 500 1000 1500 2000 2500

Pass 60 109 139 181 267

Fail 0 0 0 0 0

Inconclusive 10 18 37 53 51

Time(s) 1.431 3.254 6.668 10.908 15.528

Table XII: Final verdict for property Table XIII: For each INVITE request there should Table XIV: For each INVITE request 2 (normal) be a 2xx response, within 1.5s (normal) there should be a 2xx response (high) Trace No.of messages 1 500 2 1000 3 1500 4 2000 5 2500

Pass 60 109 139 181 267

Fail Inconclusive 0 10 0 18 0 37 0 53 0 51

Trace Messages Pass 1 500 60 2 1000 109 3 1500 139 4 2000 181 5 2500 267

Fail Inconclusive Time(s) 0 10 1.488 0 18 3.210 0 37 6.768 0 53 10.971 0 51 14.548

Trace Messages Pass 1 500 12 2 1000 33 3 1500 76 4 2000 93 5 2500 136

Fail Inconclusive Time(s) 0 97 6.019 0 188 19.564 0 172 28.506 0 233 45.832 0 347 88.174

Table XV: For each INVITE request Table XVI: Final verdict for property Table XVII: Final verdict for property there should be a 2xx response within 2 (high) 2 (Ts = 5s) Ts = 1.5s (high) Trace No.of messages Pass Fail Inconclusive Trace No.of messages Pass Fail Inconclusive Trace Messages Pass 1 500 12 2 1000 31 3 1500 60 4 2000 86 5 2500 94

Fail Inconclusive Time(s) 0 97 5.984 0 190 19.401 0 188 28.984 0 240 44.941 0 389 90.997

1 2 3 4 5

500 1000 1500 2000 2500

12 0 31 2 60 16 86 7 94 42

97 190 188 240 389

1 2 3 4 5

500 1000 1500 2000 2500

12 33 76 93 136

0 0 0 0 0

97 188 172 233 347

Table XVIII: For each INVITE re- Table XIX: For each INVITE request Table XX: For each INVITE request quest there should be a 2xx response there should be a 2xx response within there should be a 2xx response within (high) Ts = 5s (high) Ts = 5s (high) Trace Messages Pass 1 500 12 2 1000 33 3 1500 76 4 2000 93 5 2500 136

Fail Inconclusive Time(s) 0 97 6.019 0 188 19.564 0 172 28.506 0 233 45.832 0 347 88.174

Trace Messages Pass 1 500 12 2 1000 33 3 1500 76 4 2000 93 5 2500 136

Fail Inconclusive Time(s) 0 97 7.464 0 188 20.139 0 172 29.840 0 233 46.993 0 347 91.537

Trace Messages Pass 1 500 12 2 1000 33 3 1500 76 4 2000 93 5 2500 136

Fail Inconclusive Time(s) 0 97 7.464 0 188 20.139 0 172 29.840 0 233 46.993 0 347 91.537

been implemented into a framework, and results from testing SIP properties on large traces collected from IMS service. The results are positive, the implemented approach allows to define and test complex data relations efficiently, and evaluate the performance properties successfully. For the non-positive results, the ‘?’ operator works perfectly to get a final verdict as we expected. Moreover, since we can already test the time related performance requirement, it would be a future work for us to build a performance monitoring benchmark system by using our formalism. Besides, optimizing the complexity of our algorithm is currently another future work. R EFERENCES [1] Open Mobile Alliance. Internet messaging and presence service features and functions. 2005. Standard V1 220050125-A. [2] Open Mobile Alliance. Push to talk over cellular requirements. 2006. Standard V1 0-20060609-A. [3] K.R. Apt and M.H. Van Emden. Contributions to the theory of logic programming. Journal of the ACM (JACM), 29(3):841– 862, 1982. [4] P. Arpaia, L. Fiscarelli, G. La Commara, and C. Petrone. A model-driven domain-specific scripting language for measurement-system frameworks. IEEE Transactions on Instrumentation and Measurement, 60(12):3756 –3766, dec. 2011. [5] C. Barna, M. Litoiu, and H. Ghanbari. Model-based performance testing: Nier track. In Proc. International Conference on Software Engineering (ICSE), pages 872 –875, may 2011. [6] E. Bayse, A. Cavalli, M. Nunez, and F. Zaidi. A passive testing approach based on invariants: application to the wap. Computer Networks, pages 48(2):247–266, 2005. [7] Xiaoping Che, Felipe Lalanne, and Stephane Maag. A logic-based passive testing approach for the validation of communicating protocols. In Proc. of the 7th International Conference on Evaluation of Novel Approaches to Software Engineering, 2012. [8] MH Van Emden and RA Kowalski. The semantics of predicate logic as a programming language. Journal of the ACM, pages 23(4):733–742, 1976. [9] Hewlett-Packard. SIPp. http://sipp.sourceforge.net/, 2004. [10] Robert M Hierons, Paul Krause, Gerald Luttgen, and Anthony J. H. Simons. Using formal specifications to support testing. ACM Computing Surveys, page 41(2):176, 2009. [11] Felipe Lalanne, Xiaoping Che, and Stephane Maag. Datacentric property formulation for passive testing of communication protocols. In Proceedings of the 13th international conference on Applied Computing, ACC’11/MMACTEE’11, pages 176–181. World Scientific and Engineering Academy and Society (WSEAS), 2011.

[12] Felipe Lalanne and Stephane Maag. A formal data-centric approach for passive testing of communication protocols. IEEE/ACM Transactions on Networking, PP(99), 2012. [13] D. Lee and R.E. Miller. Network protocol system monitoringa formal approach with passive testing. IEEE/ACM Transactions on Networking, pages 14(2):424–437, 2006. [14] Stephane Maag and Felipe Lalanne. A formal data-centric approach for passive conformance testing of communication protocols. Technical report, Telecom Sud-Paris, 2011. [15] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, and J. Peterson. IETF RFC3261, sip: Session initiation protocol. 2002.