Luigi Logrippo SITE

1
Luigi LogrippoSITE

• Feature Interactions
• as Inconsistencies

luigi_at_site.uottawa.ca http//www.site.uottawa.ca/
luigi/
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 delegation to
transfer access rights to lower security
personnel FI Delegation defeats BLP
6
FI in communications
FI CF defeats OCS .
3. A gets connected to C
2. B forwards to C
1. A calls B
OCS Originating Call Screening CF Call Forward
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 800 pucks
Send 1000 hockey pucks
Send 400
Send 600 pucks
Send 400 pucks
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 800 pucks
Send 1000 hockey pucks
Send 400
Send 600 pucks
Send 400 pucks
FI subcontracting defeats itself
9
Presence communications features 1

• Alice call Bob urgently about meeting
  cancellation
• Bobs policy send to voice mail all calls that
  arrive when I am moving faster than 50Km/h
• FI Bobs policy defeats Alices 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 Gorses
  Masters 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 analysisConsidering 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