1 Luigi Logrippo SITE Feature Interactions as Inconsistencies

2 Development Early research on FI was based on the idea that Fis were the result of complex interleavings of features See Feature Interaction contexts Later it became understood that, more simply, if features are logically inconsistent then they cannot coexist

3 Main idea Many software flaws can be discovered by making the logic precise and thoroughly examining it by the use of logic tools Formal methods Feature interactions are the result of logic flaws Inconsistency of specs Application areas: New VoIP and Web based systems Security Many others Do this Do that

4 Feature Interaction in Automotive Electronic Stability Program (ESP) and Cruise Control (CC) ESP: Break if wheels slip on wet road CC: Increase speed until cruise speed is reached FI detectable by the fact that the two features have contradicting requirements

5 Protection rings in Bell-LaPadula security model High security personnel can use delegatio n to transfer access rights to lower security personnel FI: Delegation defeats BLP

6 C 3. A gets connected to C 1. A calls B 2. B forwards to C A has C in OCS list A B has CF to C B FI: CF defeats OCS. OCS: Originating Call Screening CF: Call Forward FI in communications

7 Infinite loops FIs Companies A, B and C have policies where each of them uses the next in a loop as suppliers of parts in excess of inventory This can start a chain reaction with potentially disastrous effects! Send 1000 hockey pucks Send 800 pucks Send 600 pucks Send 400 pucks Send 400 FI: subcontracting defeats itself

8 Infinite loops FIs Companies A, B and C have policies where each of them uses the next in a loop as suppliers of parts in excess of inventory This can start a chain reaction with potentially disastrous effects! Send 1000 hockey pucks Send 800 pucks Send 600 pucks Send 400 pucks Send 400 FI: subcontracting defeats itself

9 Presence communications features 1 Alice: call Bob urgently about meeting cancellation Bob’s policy : send to voice mail all calls that arrive when I am moving faster than 50Km/h FI: Bob’s policy defeats Alice’s urgent call policy

10 Presence communications features 2 Alice: call Bob as soon as he arrives in building Bob: call Alice as soon as she arrives in building One of the two policies will be defeated by the other

11 FIs as inconsistencies There is FI when there is inconsistency between: Two simultaneous actions of one agent ESP – CC example Two simultaneous actions of two different agents ‘Call as soon as gets in the building’ example An action and the requirements of a user Actions and systems requirements Infinite loop example Inconsistency of actions is

12 This idea is explicit in Within an explicit logic framework: Felty and Namjoshi, FIW 2000 Various papers of Aiguier and LeGall, e.g. Formal Methods 2006 (LNCS 4085) More generally talking about ‘conflicts’, ‘broken assumptions’, etc. Kolberg, Magill, Wilson, IEEE Comm., 2003 Gorse, Logrippo, Sincennes, originally in Gorse’s Master’s thesis of 2000 and eventually published in SoSym 2006 Metzger et al., FIW 2003 and 2005 Turner, Blair 2006 Etc.

13 Interesting aside on logic Not all inconsistencies we have identified are straight logical inconsistencies… Some are infinite loops Others may be deadlocks What is the logic interpretation of an infinite loop or a deadlock? What is the computational interpretation of a logical inconsistency? Subject of ongoing work on the relationship between lambda calculus and logic

14 How do we know about the conflicts This can be obvious, in cases where there is a straight contradiction A and not A But this is rarely the case Most papers leave it to the systems designer to state whether two actions or requirements are in contradiction, E.g. accept call contradicts disconnect

15 Determining more precisely inconsistency of actions So action inconsistency is usually a symptom Based on knowledge of expected systems behavior Detection is tentative Detection tool identifies possible conflict scenarios and interaction must be confirmed by human inspection

16 Next step of analysis: Considering pre- & post-conditions Wu and Schulzrinne have moved forward with this idea Not entirely new… Introducing the idea of conflicts between pre- and post- conditions of actions Whether actions conflict can be determined on the basis of their pre-and post-conditions This can provide information also on possible FI resolution

17 Use of pre- and post-conditions Enable(A,B) (positive interaction) The post-condition of A is implied by the pre-condition of B Disable(A,B) (negative interaction) The post-condition of A is not implied by the pre-condition of B Conflict of post-conditions: (negative interactions) The expected postconditions of two actions conflict directly Special case: they request the same resources The expected postconditions of two actions conflict because of parameters

18 How to choose pre- and post-condition Communications systems are very complex and every action is the result of, also produces, very complex conditions Only few elements can be expressed in pre- and post-conditions that are meant for analysis These elements can only be chosen in terms of broad generalizations The choice of these elements is of course vital for producing a useful analysis In terms of the characteristics of APPEL, we have chosen to focus on two elements: Call states State of the media

19 How to determine conflicts Similarly, conflicts must be determined in terms of broad generalizations E.g. if one action requests a resource of a certain type, then it might disable another action that requires the same type of resources These generalizations can be made more specific when more information is available

20 Example 1

21 How to detect Specifications must be made precise! Sometimes they are already sufficiently precise, e.g. in a XML-based language E.g.BPEL Constraint Logic Programming Given a set of logic constraints, CPL tools can tell whether There is a solution, constraints are satisfiable There is no solution, in fact there is a counterexample

22 How to solve Solution is a more complex problem, will depend from User intentions, Try to identify user goals May require an interactive system Solution methods will vary according to the application domain

23 Conclusions Complex designs require the composition of complex features With a lot of user control on what will happen in different situation (user policies ) Introduction of these features will require sophisticated methods to control different situations of feature conflicts