A Framework for Synchronous and Ubiquitous

Collaboration

Advisor & Chairperson : Dr. Geoffrey FoxCommittee Faculty : Dr. Dennis Gannon, Dr. Kay Connelly, Dr. Sun Kim

Kangseok Kimkakim@cs.indiana.edu

Computer Science Department Indiana University

2

Outline Motivation Research Issues Universal XGSP Collaboration Framework XGSP (XML based General Session Protocol) XRBAC (XML Role Based Access Control) XFloor (XML Floor Control) Experimental Results Contribution Future Work

3

4

Research Issues I Heterogeneous community collaboration

Most heterogeneous community collaboration systems cannot communicate with each other.

e.g. H.323 <-> AG, AG <-> SIP We need wider range of collaboration by building integrated

collaboration system, which combines collaborative applications as well as other collaboration into a single easy-to-use environment.

Universal collaboration and access Mean capability of multiple users to link together with dispar

ate access modes to access collaborative systems. Make systems more usable and more useful, and enable pe

ople to work together with others remotely.

5

Research Issues II Access control in collaboration system

The cooperation on the resources shared among a group of users may produce new results on the shared resources.

Access control policies and mechanisms are needed to restrict unauthorized access to a variety of protected information and resources.

Group coordination support As users try to manipulate shared application at the same ti

me, a user may have to contend with other users for access to the shared application.

To maintain consistent shared state at application level, we need to control competing accesses and mitigate race conditions for shared resources.

6

Universal XGSP Collaboration Framework Built on heterogeneous (wire, wireless) computing environmen

t. Handle cooperation and communication among heterogeneous

communities. Provide collaborative applications in the heterogeneous commu

nity collaboration. Shared event mechanism. Structured as three layers and six major components: node ma

nager, session / membership control manager, access / floor control manager, policy manager, request and reply event message handlers, and communication channel.

Universal XGSP Collaboration Framework Architecture

Collaborative Applications

Node Manager

Session/Membership Control Manager Access/Floor Control Manager

XGSP Event Messages XGSP Event Messages XGSP Event Messages

Request/Reply Handler Request/Reply Handler Request/Reply Handler

Communication Channel

Policy Manager

Broad View Architecture

Application Proxy

Application Filter

Conference Manager

Message / Service Middleware (Broker)

9

XGSP (XML based General Session Protocol)

Session means online workgroup of collaborators working with sharing various collaborative resources.

Means control logic defined in XML. The control logic is used to manage presences and connectivity among

collaborators in online session, and organize online workgroups (sessions or conference).

To maintain consistent state information among sessions and collaborators in a coordinated way.

We use query-dissemination interaction event messaging mechanism with publish-subscribe messaging service.

provide a flexibility for adapting dynamic changes of collaboration states (creation and destroy of workgroups, and presences of participating users in workgroups)

XRBAC (XML Role Based Access Control)

RBAC is a scheme that describes access rights based on roles in an organization. Pros: ease of administration, scalable Cons: not flexible, not effective to fine-grained

access control

XRBAC Use roles based on users’ privileges and devices’

capabilities Chairperson-mediated interaction mechanism

(request-response) mechanism Flexibility – adapting to the state change of

collaborative resources at run time Fine-grained action - defined as the smallest

interactive major events (semantic events)

XRBAC Architecture

Chair node Request node

DecisionResponse

AccessRequest

Conference Manager

Message / Service System

(Broker)

Push Policy Push Policy

KMC (Key Management Center)

Activation / Deactivation

Service

Access Decision Service

Authentication Service

Local Policy Store

Pull Policies

Activation / Deactivation

Service

Access Decision Service

Authentication Service

Local Policy Store

Pull Policies

12

XFloor (XML Floor Control) Interaction management for synchronous collaborative

application. In traditional face-to-face offline session, participants generally follow rules

of etiquette or social protocol when they interact with each other. In online session, participants usually interact with each other using comput

er-mediated policies with CSCW (Computer Supported Cooperative Work) tools.

Floor control policy and mechanisms have to be able to provide a floor on shared resource for only one participant in online session at any time.

XFloor provides flexibility ranging from free-for-all to application specific floor control mechanism.

Free-for-all (no floor) ex) Text-chat application

Chairperson-mediated floor control mechanism ex) Shared whiteboard application Major event conflict detection function (Strictly conflict avoidance) Non-optimistic locking mechanism

Two-player turn-taking mechanism ex) Collaborative chess game application

Examples

Broker

Major event

(Moving object)Major event

(Moving object)

XGSP event XGSP eventXG

SP e

vent

Drawing

even

t Drawing event

Drawing event

Text event Text event

Major event(Moving object)

14

XFloor Policy Floor policy means how users request resources, how the

resources are assigned and released. A set of predicate rules (policies) are defined in terms of request,

response, and release to provide the floor for only one participant at a time.

Request Users can request through the use of XFloor control tool Chairperson can directly assign a floor to collaborators

Response If the floor is available, a chairperson assigns the floor to the

floor requester. Otherwise, the floor request is queued into a floor waiting

queue or can be denied. Release

Floor is assigned to a requester waiting in a floor waiting queue in FIFO order

Floor can also be released from directly chairperson or after a prefixed amount of time.

15

XFloor Mechanism Determination of types classified to access resources

If the return type is “Implicit” -----> grant “Exclusive” ---> grant or queued “Shared” -----> grant or deny “Released” ----> grant

If one of the elements does not exist in policy, then a type “Invalid” is returned into chairperson and the request is denied.

Determination of whether an action in a request exists in current floor state information table, in other words, a request action conflicts with the action of current floor holder

If the return type is “Exclusive” and request action exists in the floor state information table, then the request is queued. Otherwise, the request is granted

If the return type is “Released” and a floor waiting queue is not empty, then the request is granted and the first request in the waiting queue is granted.

If the return type is “Released” and a floor waiting queue is empty, then the request is granted

Decision Procedures of XFloor Mechanism (strictly Conflict Avoidance)

FloorRequestQueue

Access TypeDecision Service

Access and Floor ControlDecision Service

PolicyStore

Current Floor StateInformation Table

FloorWaitingQueue

Decision

Access / Floor Control Manager

Floor Requesters Chairperson

- This guarantees the mitigation of race conditions of floor requests to shared application.

Non-optimistic Locking Mechanism with Shared Whiteboard

Access / FloorControl Manager

BROKER

SetFloor

RequestFloor

1. Lock

2. Request Floor3. Request Floor

4. Decision

5. Grant 6. Grant (unlock)

Fine-grained locks are used to allow more concurrent activity among participants. Coarse-grained lock can be used to allow a participant to make more activities at a time. This mechanism guarantees that the consistency state at application level is maintained among participants.

Request-Response Interaction Scheme between a Chairperson and a Floor Requester with Human-Computer Interaction

BROKER

Access /Floor

ControlManager

Set Floor

Set Floor

Request FloorRequest Floor

Decision

Decision(Grant, Deny,

Queued, Release)

19

Baseline Performance Results

SDSC

NCSACGL at IU

9.37 ms / 1 byte54.65 ms / 60 KB

0.43 ms / 1 byte13.79 ms / 60 KB

64.78 ms / 1 byte353.44 ms / 60 KB

2.58 sec / 1 byte28.43 sec / 60 KB

2.33 sec / 1 byte22.18 sec / 60 KB

2.34 sec / 1 byte22.86 sec / 60 KB

Baseline Performance Results ILatency in Round Trip Time(Desktop - Broker - Desktop)

0

100

200

300

400

500

600

10 20 30 40 50 60 70 80 90 100Data size in killobytes

Tim

e in

mill

isec

onds

GridFarm NCSA SDSC

Baseline Performance Results IILatency in Round Trip Time

(Cell phone - Broker - Cell phone)

0100020003000400050006000700080009000

10000

1 2 3 4 5 6 7 8 9 10Data size in killobytes

Tim

e in

mill

isec

onds

GridFarm NCSA SDSC

Baseline Performance Results IIILatency in Round Trip Time

(Cell phone - Broker - Cell phone)

0

5000

10000

15000

20000

25000

30000

10 20 30 40 50 60Data size in killobytes

Tim

e in

mill

isec

onds

GridFarm NCSA SDSC

Experimental Results ITransit Time in Request and Response of Sessions

Transit Time in Request and Response of Sessions(Desktop - Broker - chair node - Broker - Desktop)

020406080

100120140160180200

10(1.4)

20(2.7)

30(3.9)

40(5.2)

50(6.5)

60(7.8)

70(9.1)

80(10.3)

90(11.6)

100(12.9)

Session size in number (Data size in killobytes)

Tim

e in

mill

iseco

nds GridFarm NCSA SDSC

Experimental Results IITransit Time in Request and Response of Sessions

Transit Time in Request and Response of Sessions(Cell phone - Broker - chair node - Broker - Cell phone)

0100020003000400050006000700080009000

10(1.4)

20(2.7)

30(3.9)

40(5.2)

50(6.5)

60(7.8)

70(9.1)

80(10.3)

90(11.6)

100(12.9)

Session size in number (Data size in killobytes)

Tim

e in

mill

iseco

nds

GridFarm NCSA SDSC

Application (Whiteboard) Filter Architecture View

Broker

Filter

Display

Display

DisplayTranscoding

Graphical display data(Image or drawingobject data)

Pre-transcodingProblem: as new device or new type of

application is added, all types ofapplication have to be updated

Post-trancodingProblem: wireless network and

cell phone does not support the transfer of more than 60 KB

Image Filtering Structure

Create Image

Create Buffered Image

Scale Image

Convert to PNG

Broker

Whiteboard Application Filter

BinaryImage Data

BinaryImage Data

Canvas Size(1024 x 768)

Canvas Size(160 x 144)

Binary Image Data Transcoded Binary Image Data

Experimental Results III Transfer time of Image from Desktop to Cell phone

Transfer time of Image from Desktop to Cell phone

0

5000

10000

15000

20000

25000

GridFarm NCSA SDSCLocations

Tim

e in

mill

iseco

nds

Filtering TimeImage

Experimental Results IVTransfer time of Drawing objects from Desktop to Cell phone

Transfer time of Drawing objectsfrom Desktop to Cell phone

0100020003000400050006000700080009000

GridFarm NCSA SDSCLocations

Tim

e in

mill

iseco

nds Filtering Time

Drawing Objects

800x600 JPEG Image on Desktop vs. 158x134 PNG Image on Cell Phone

60 KB (JPEG)800 x 600

50 KB (PNG)158 x 134Shrunk size

0.2 x 0.2

Experimental Scenario Overview

BrokerAccess Request Simulator

Chair Node(Decision Node)

Request Node

<RequestAction>Request arrivals

with exponential Distribution with mean interarrival time (3 sec)

<SetAppAction>

Three different network combinations over three different locations (# of requests = 100)1. collaboration using only desktop devices (wired network)

(# of requests = 100)2. collaboration using only cell phone devices (wireless network)

(# of requests = 100)3. collaboration using desktops and cell phones together

(wired + wireless network) (desktop (# 50) + (cell phone (# 50))

Overhead Timing Considerations

Total latency (Ttotal) = Waiting time (Tw) + Decision time (Td) + Network transit time (Tn = Treq + Tres)

Broker

QueueDecision

Procedure

Chair node Request nodes

Decision Response

AccessRequest

Td Tw Tn = Treq + Tres

Ttotal = Td + Tw + Tn

Experimental Results V Mean completion time of a request vs. Mean request interarrival time (3000 milliseconds)

Mean completion time of a request vs. Mean requestinterarrival time (3000 milliseconds)

0

1000

2000

3000

4000

5000

6000

Desktop Desktop +Cellphone

Cell phone

Mean request interarrival time in milliseconds

Mean

com

plet

ion

time

ofa

requ

est i

n m

illise

cond

s GridFarmNCSASDSC

Experimental Results VIReply + Non-Blocking vs. No-Reply + Blocking

Mean completion time of a request vs. Mean requestinterarrival time (3000 milliseconds)

05000

10000150002000025000300003500040000

Desktop Desktop +Cellphone

Cell phone

Mean request interarrival time in milliseconds

Mean

com

plet

ion

time

ofa

requ

est i

n m

illise

cond

s GridFarmNCSASDSC

Mean completion time of a request vs. Mean requestinterarrival time (3000 milliseconds)

0

1000

2000

3000

4000

5000

6000

Desktop Desktop +Cellphone

Cell phone

Mean request interarrival time in millisecondsMe

an c

ompl

etio

n tim

e of

a re

ques

t in

mill

iseco

nds GridFarm

NCSASDSC

Reply + Non-Blocking No-Reply + Blocking

Desktop : 9.77% (GridFarm), 1.12% (NCSA), 7.51% (SDSC)Desktop + Cell phone : 51.46% (GridFarm), 59.79% (NCSA), 59.83% (SDSC)Cell phone : 84.88% (GridFarm), 87.42% (NCSA), 86.96% (SDSC)

34

Formal Verification by Colored Petri Net

We modeled the mechanisms (XRBAC and XFloor) and verified the modeled mechanisms in terms of mutual exclusion, dead lock, and starvation.

The key part for the modeling and formal verification is to show consistent shared state at application level to collaborators by mitigating race conditions for shared resources

We used Colored Petri Nets (CP-nets or CPNs) with time for the abstract modeling representation of the control mechanisms.

XML based Control Mechanism Modeled by CP-nets

i f boo lsthen 1` (IntInf.to Int (time()))e ls e empty

if s haredReqs < > [] then s etF a ls eAc tion(s haredReqs )e ls e s haredReqs

o ldReqs

if grantDeny = give orels e grantDeny = re leas ed then (s ort OldReq.lt tmpReqs )e ls e o ldReqs

(loc k ,grantDeny,newReq) (lock ,grantDeny,newReq)

(loc k,grantDeny ,newReq)

o ldReqsif grantDeny = grant then (s o rt OldReq.lt tmpReqs )e ls e o ldReqs

if grantDeny = givethen 1` loc ke ls e empty

loc k if grantDeny < > releas ed anda ls o grantDeny < > givethen 1` loc ke ls e empty

if boo ls andals o s haredReqs < > []then timeOverAc tion(s haredReqs )e ls e s haredReqs

s haredReqs

o ldReqs

s haredReqs

s haredReqs

if s haredReqs = []then s haredReqse ls e rm (hd s haredReqs ) s haredReqsif s haredReqs < > []

then 1` (loc k , grantDeny , hd s haredReqs )e ls e empty

loc k

if grantDeny = releas edthen 1` loc ke ls e empty

(loc k,grantDeny )

(loc k ,grantDeny )

loc k

s haredReqs

s haredReqs

bools

s haredReqs

if ex is tAc tion(newReq, o ldReqs )then (s haredReqs ^ ^ [newReq])e ls e s haredReqs

(loc k ,grantDeny ,newReq) (loc k ,grantDeny ,newReq) (lock ,grantDeny ,newReq) (loc k ,grantDeny ,newReq)

if grantDeny = re leas ed ore ls e grantDeny = givethen 1` (loc k ,grantDeny ,newReq)els e empty

(loc k ,grantDeny ,newReq)(loc k,grantDeny ,newReq)

(loc k ,grantDeny ,newReq)

n

n@+ ex pTime(100)

n if n= kthen emptyels e 1` ((n+ 1)@+ expTime(100))

if s haredReqs = [] ore ls e timeChec k Ac tion(hd s haredReqs )then newReqs ^ ^ [newReques t()]e ls e [o ldReques t(hd s haredReqs )]^ ^ newReqs

newReqs

proc time

if GT (proc time, re leas edtime) anda ls o s haredReqs < > []then trueels e fa ls e

if GT(proc time, re leas edtime)then 1` proc timeels e 1` re leas edtime

releas edtime

releas edtime

proc time

IntInf.to Int (time())

loc k

if s haredReqs < > [] andals o o ldReqs < > []then (loc k ,grantDeny ,findAc tion(hd s haredReqs , o ldReqs ))e ls e (loc k ,grantDeny ,newReq)

(loc k ,grantDeny ,newReq)(loc k ,grantDeny ,newReq)

(loc k ,grantDeny ,newReq)

o ldReqs

(loc k ,grantDeny ,newReq)

(loc k ,newReq)

(loc k ,newReq)if !res pons e = 4then 1` (loc k,newReq)els e empty

if !res pons e = 3then 1` (loc k,newReq)e ls e empty

(loc k ,grantDeny ,newReq)

(loc k ,grantDeny ,newReq)

(lock ,newReq)

(lock ,newReq)

if !res pons e = 2then 1` (loc k,newReq)els e empty

if !res pons e = 1then 1` (loc k ,newReq)els e empty

(loc k,grantDeny ,newReq)(loc k ,newReq)if !res pons e = 0then 1` (loc k ,newReq)e ls e empty

newReq::newReqs

newReqs (loc k , newReq)@+ proc time

(loc k ,newReq)

UpdateTable

input (newReq, o ldReqs );output (tmpReqs );ac tionc hangedAc tion(newReq, o ldReqs , o ldReqs );

GiveF looroutput (grantDeny );actiondec is ionGive();

GIVEorUnlock

Unloc k

T imeOver

Trans mitReply

ReceiveDec is ion

Rec eiveReply

input (newReq, o ldReqs );output (tmpReqs );ac tionchangedAc tion(newReq, o ldReqs , oldReqs );

SendReply

Init

Arriva l

Poll ing

Trans mitDec is ion

D4

input (newReq, o ldReqs );output (grantDeny );ac tionif ex is tAc tion(newReq, o ldReqs )then dec is ionQueued()e ls e dec is ionGrant()

D5

input (s haredReqs );output (grantDeny , re leas edtime);ac tionif s haredReqs = []then dec is ionGR()e ls e dec is ionGT()

D3

output (grantDeny );ac tiondec is ionGD();

D2

output (grantDeny );actiondec is ionGrant();

SendDec is ion

D1

output (grantDeny );ac tiondec is ionDeny ();

StopStart

output (proc time);ac tionexpT ime(90);

ZL oc kxGrantDeny xNewReq

LL oc k

Giv eF loorL oc k

UL ock xGrantDeny

WaitingL is t

Queue

1` []

SharedReqs

EL ock xGrantDenyx NewReq

DLoc k xGrantDeny xNewReq

Nodes

Loc k xGrantDenyx NewReq

CL oc k x GrantDeny xNewReq

Simula tionStart

1` 1

COUNT

Reques tNodes

COUNT

T imeOver

BOOL

Waiting T ime

1` 0

INT

T ime

INT

BLoc k xGrantDenyx NewReq

StateInformation

Table1` []

OldReqs

AL oc k xGrantDenyx NewReq

Releas edL oc k xNewReq

Exc lus iv eL oc k x NewReq

SharedL oc k x NewReq

Implic itL oc k x NewReq

Dec is ionDone

L oc k x GrantDeny xNewReqInv a lid

L oc k x NewReq

Reques tQueue

1` []

NewReqs

Nex tReques t

loc k

L oc k

Bus yL oc kx NewReq

1 1` []

1 1` 1@0 1 1` 0

1 1` []

1 1` []

1 1` loc k @0

Simplied XML based Control Mechanism Model

SimulationStart

Init

RequestNodes

Arrival

RequestQueue

PolicyStore

Access TypeDecision Service

Real Code

SendDecision

Nodes

Access and Floor ControlDecision Service

Current Floor StateInformation Table

Critical Section

Waiting List Queue

Unlock

Communication Service

Contribution1. Building of Universal XGSP Collaboration Framework on both mobile device (cell ph

one) and non-mobile device (desktop) Defined general session protocol in XML (XGSP) This includes another colleague’s contribution on desktop

2. Designed and implemented XRBAC The use of role based on users’ privileges and devices’ capabilities Scalability, Flexibility, Fine-grained access control

3. Designed and implemented XFloor Provides flexibility from free-for-all to application specific floor control mechanis

m Chairperson-mediated interaction control with strictly conflict avoidance and no

n-optimistic locking mechanism4. Building of application filter for cooperation of heterogeneous types of whiteboard a

pplication Shared display model and shared event model

5. Building of application proxy for Instant Messenger Shared event model

6. Building of collaborative applications on cell phone Text Chat, Instant Messenger, Shared Whiteboard with Image Annotation

7. Modeling of XML based control mechanisms (XRBAC and XFloor) To prove the correctness of the modeled mechanisms

38

Future Work Fault-tolerant role delegation mechanism with role hierarchy policy

A recovery approach from failure-prone system We already implemented polling (heart-beat message) mechanism.

Design issues for building applications on mobile devices An approach to overcome technical limitation occurring as porting applic

ations from desktop computers (moderate screen size) to mobile devices (small screen size)

Improvement of quality of the transcoded image from desktop into cell phone

Design and implement the authentication of users joining a session during roaming with cell phone devices, and the encryption of messages sent to and from the cell phone devices

Support for floor control of synchronous collaborative media applications such as audio / video

Optimistic floor control mechanism Means allowing conflicts and resolving them With time-stamp and with different application