csec experimenting with progress mappings for the sweep-line analysis of the internet open trading...

CSEC

Experimenting with Progress Mappings for the Sweep-Line Analysis of the Internet Open

Trading Protocol

Guy Edward Gallasch, Chun Ouyang, Jonathan Billington

Lars Michael Kristensen

CPN Workshop

10th October 2004

Computer Systems Engineering CentreSchool of Electrical and Information Engineering

University of South Australia

Department of Computer ScienceUniversity of Aarhus

2CSEC

Outline

• Motivation and Contribution

• The Sweep-Line Method

• Internet Open Trading Protocol (IOTP)

• A Revised IOTP CPN Model

• Sweep-Line Exploration of IOTP

• Experimental Results

• Conclusions and future work

3CSEC

Motivation and Contribution

• State Explosion Problem: – Too many states to fit in computer memory!

• Evaluation of the Sweep-line method on an industrial example.

• Evaluation of Sweep-line using different progress mappings.

• Gain experience in applying Sweep-line effectively.

• Obtain verification results for IOTP that were previously out of reach.

4CSEC

Sweep-Line Method – Progress Measure• A notion of progress within the system being modelled:

– States with lower progress are unlikely to be reached from

states with higher progress.

– States with lower progress can be deleted on-the-fly.

• A progress measure:

– Formally captures the notion of progress.

– Specifies a progress mapping from markings to ordered

progress values.

• We can take the set of natural numbers as the progress

values and the usual orderings on this set, e.g. ≤, <, >.

5CSEC

Sweep-Line Method – Progress Mappings• A mapping is monotonic if:

– There is only progress, no regress.

– For each reachable marking, all successors have the same progress value or a higher progress value.

• A mapping is non-monotonic if:– We have regress edges.

– Arcs leading from states with higher progress values to states with lower progress values.

• The Sweep-line method can deal with regress:– Mark destinations of regress edges as persistent.

– Re-explore the occurrence graph from these persistent states.

6CSEC

IOTP – Basic Concepts

• Informal narrative description in RFC 2801 (290 pages).• Trading Roles:

– Consumer, Merchant, Payment Handler, Delivery Handler (and Merchant Customer Care Provider)

• IOTP Messages• Document Exchanges:

– Authentication– Offer (Brand Dependent Offer and Brand Independent Offer)

– Payment

– Delivery

– Payment-and-Delivery

• IOTP Transactions:– Authentication, Purchase, Refund, Deposit, Withdrawal, and Value

Exchange

7CSEC

IOTP – Transaction Procedures

• IOTP Transactions are constructed by combining document exchanges– An example of Purchase

Transaction

8CSEC

IOTP – Transaction Procedures

• IOTP Transactions are constructed by combining document exchanges– An example of Purchase

Transaction

• Transaction Cancellation and Error Handling– Cancel Message

– Error Message

– Message Identifier (local to each trading role)

Authentication (optional)

Payment

Brand Dependent

Offer

Brand Independent

Offer

Payment

Delivery

Payment-and-

Delivery

9CSEC

A Revised IOTP CPN – Overview

10CSEC

Revised IOTP CPN – Top Level

• Four IOTP entities (trading roles) communicate with each other via a simple model of the underlying transport medium (HTTP service)

11CSEC

Consumer Trading Role Page

12CSEC

Consumer Trading Role Page

Token contains:

•Trading Role internal state

•Transaction type

•Current Document Exchange

•Message ID and Retrans counter of last message sent

•Message ID of last message received.

13CSEC

Analysis of the Revised IOTP

• The analysis focuses on the six Authentication and Payment-related transactions.

• Analysis of each transaction for different values of RCmax– RCmax : the maximum value of the message retransmission counter.

• The value of RCmax is not specified in RFC 2801.– Unbounded number of configurations of the CPN to analyse.

• When RCmax > 4, the number of states of both the Purchase and the Value Exchange transactions became too large to manage with available computer resources.

14CSEC

Sweep-Line Exploration of IOTP

• The sweep-line method is applied to alleviate the problem of state explosion for the revised IOTP CPN with RCmax > 4

• Two approaches to define a progress mapping: – Generic features: Sequence numbers and Retransmission counters.

– IOTP-specific features: take advantage of behavioural properties of IOTP.

• Three progress mappings defined:– Generic progress mapping

– IOTP-specific progress mapping

– Combined progress mapping

• Valid transaction termination property of IOTP is examined

15CSEC

Generic Progress Mapping

• Wouldn’t it be nice… a progress mapping giving good performance, based on common protocol attributes:– Sequence numbers (Message IDs).

– Retransmission counters.

• Each IOTP trading role maintains its own message identifier and retransmission counter for the message most recently sent.

• Definition of generic progress mapping generic_2 for IOTP:

16CSEC






))()()1max(()(2_ MMRCM trTRtr

trgeneric GetRCGetMessID

17CSEC






TR = {Consumer, Merchant, Payment Handler, Delivery Handler}



18CSEC







GetRCtr : Marking -> Trading Role Retrans Counter



19CSEC








GetMessIDtr : Marking -> Trading Role Message ID



20CSEC








GetMessIDtr : Marking -> Trading Role Message ID

(RCmax+1) is one greater than Max(GetRCtr)



21CSEC

IOTP-Specific Progress Mapping

• Two sources of IOTP-specific progress are identified:

1. Within a transaction, progress is exhibited by the execution of successive document exchanges.

– The mapping exch_comb enumerates the combinations of

document exchanges in the order that they occur in e.g. a Purchase Transaction.

2. Within a document exchange, progress is exhibited by the internal state changes of the trading roles.

– Four mappings, m , c , ph and dh , enumerate the trading

role internal states in the order that they occur.

• Definition of the IOTP-specific progress mapping specific

22CSEC

IOTP-Specific Progress Mapping

• Two sources of IOTP-specific progress are identified:

1. Within a transaction, progress is exhibited by the execution of successive document exchanges.

– The mapping exch_comb enumerates the combinations of

document exchanges in the order that they occur in e.g. a Purchase Transaction.

2. Within a document exchange, progress is exhibited by the internal state changes of the trading roles.

– Four mappings, m , c , ph and dh , enumerate the trading

role internal states in the order that they occur.

• Definition of the IOTP-specific progress mapping specific

)()()()()()( _ MMMMMM dhphcmcombexchspecific

23CSEC

IOTP-Specific Progress Mapping (2)• Mapping values are engineered so that successive document

exchanges are explored sequentially– i.e. ‘flatten’ the occurrence graph to make it ‘long and narrow’

rather than ‘short and wide’

24CSEC

IOTP-Specific Progress Mapping (2)• Mapping values are engineered so that successive document

exchanges are explored sequentially– i.e. ‘flatten’ the occurrence graph to make it ‘long and narrow’

rather than ‘short and wide’

• Example:– Purchase Transaction

Occurrence Graphlooks somethinglike this.

– We want to ‘flatten’ it

Auth

Pay

BDOffer

Deliv

Pay-and-Del

Pay Pay

BIOffer

Deliv

Pay-and-Del

Pay

25CSEC

IOTP-Specific Progress Mapping (3)• Example: Purchase Transaction OG Exploration

Auth

Progress0

26CSEC


Auth BDOffer

Progress0 104

27CSEC


Auth PayBDOffer

Progress0 104 208

Pay

28CSEC


Auth PayBDOffer

DelivPay

Progress0 104 208 286

29CSEC


Auth PayBDOffer

Deliv

Pay-and-Del

Pay

Progress0 104 208 286 364

30CSEC


Auth PayBDOffer

Deliv

Pay-and-Del

Pay

BIOffer

Progress0 104 208 286 364 494

31CSEC


Auth PayBDOffer

Deliv

Pay-and-Del

Pay

PayBIOffer

Pay

Progress0 104 208 286 364 494 598

32CSEC


Auth PayBDOffer

Deliv

Pay-and-Del

Pay

PayBIOffer

DelivPay

Progress0 104 208 286 364 494 598 676

33CSEC


Auth PayBDOffer

Deliv

Pay-and-Del

Pay

PayBIOffer

Deliv

Pay-and-Del

Pay

Progress0 104 208 286 364 494 598 676 754

34CSEC

Combination of Generic and Specific Progress Mapping

• The generic progress mapping generic_2 incorporates the RCmax

parameter and is hoped to ‘scale’ well with RCmax.

• The IOTP-specific progress mapping specific takes advantage

of knowledge of the sequential nature of IOTP operations, but lacks potential for scalability.

• We hope to obtain a progress mapping with the advantages of both generic_2 and specific

• Definition of a combined progress mapping comb for IOTP:

35CSEC

Combination of Generic and Specific Progress Mapping

• The generic progress mapping generic_2 incorporates the RCmax

parameter and is hoped to ‘scale’ well with RCmax.

• The IOTP-specific progress mapping specific takes advantage

of knowledge of the sequential nature of IOTP operations, but lacks potential for scalability.

• We hope to obtain a progress mapping with the advantages of both generic_2 and specific

• Definition of a combined progress mapping comb for IOTP:

where weight is (at least) one larger than Max(generic_2 )

))()()()( 2_ MweightMM specificgenericcomb

36CSEC

Combination of Generic and Specific Progress Mapping (2)

• Max(GetMessIDtr):

– 15 non-error and non-cancel messages, used at most once.

– Message ID of sender increments for every new message.

– Each new error message (requesting retransmission) increments the Message ID of the receiver.

– Retransmissions have the same Message ID as the original.

– Reception of a message may stimulate a response from the receiver, incrementing the Message ID once more.

• Max(GetMessIDtr) = 15(RCmax+1)

• Max(GetRCtr) = RCmax

• Thus Max(generic_2 ) = 4(15(RCmax+1)2 + RCmax

• Therefore weight = 4(15(RCmax+1)2 + RCmax + 1

37CSEC

• Sweep-line statistics for the analysis of the revised IOTP CPN using generic_2

– The progress mapping is non-monotonic.

– This is expected, as message identifiers and retransmission counters are reset to 0 at various times during an IOTP transaction.

– Not a useful reduction.

Experimental Results - generic_2

38CSEC

• Sweep-line statistics for the analysis of the revised IOTP CPN using specific

– The progress mapping is monotonic

– The reduction in space and time is better than when using generic_2

– The space reduction worsens as RCmax increases

Experimental Results - specific

39CSEC

• Sweep-line statistics for the analysis of the revised IOTP CPN using comb

– The progress mapping is monotonic

– The reduction in space is identical to using specific for small RCmax

but does not worsen as rapidly when RCmax increases

Experimental Results - comb

40CSEC

Conclusions

• Particularised the sweep-line method for CPNs, which allows us to just associate a progress mapping with the CPN.

• Defined three progress mappings for the analysis of the revised IOTP CPN model and presented our intuition and rationale behind each.

• Verified transaction termination property of the revised IOTP with RCmax increased to 7.

• Demonstrated that the sweep-line method can be successfully applied to a complex real-life example.

• Future work– Formalise the progress mapping using vectors, as has been done in similar

work on the Wireless Application Protocol.– To apply the compositional sweep-line method to the analysis of IOTP.– To apply sweep-line method to investigate more properties of IOTP.– Develop guidelines for successful application of sweep-line.

csec experimenting with progress mappings for the sweep-line analysis of the internet open trading...

Documents

notion of progress

progress measure

delivery slide

lower progress values

higher progress values

iotp entities

delivery iotp transactions

different progress mappings