A Framework for Synchronous and Ubiquitous Collaboration

1. A Framework for Synchronous and Ubiquitous Collaboration Advisor & Chairperson : Dr. Geoffrey Fox Committee Faculty : Dr. Dennis Gannon, Dr. Kay Connelly, Dr. Sun Kim Kangseok Kim kakim@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

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 disparate access modes to access collaborative systems. • Make systems more usable and more useful, and enable people 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 time, 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 environment. • Handle cooperation and communication among heterogeneous communities. • Provide collaborative applications in the heterogeneous community collaboration. • Shared event mechanism. • Structured as three layers and six major components: node manager, session / membership control manager, access / floor control manager, policy manager, request and reply event message handlers, and communication channel.

7. Universal XGSP Collaboration Framework Architecture Collaborative Applications Node Manager Session/Membership Control Manager Access/Floor Control Manager Policy Manager Request/Reply Handler Request/Reply Handler Request/Reply Handler XGSP Event Messages XGSP Event Messages XGSP Event Messages Communication Channel

8. 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)

10. 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)

11. Activation / Deactivation Service Activation / Deactivation Service Access Decision Service Access Decision Service Pull Policies Pull Policies Local Policy Store Local Policy Store Authentication Service Authentication Service XRBAC Architecture Conference Manager Push Policy Push Policy Decision Response Message / Service System (Broker) Access Request Chair node KMC (Key Management Center) Request node

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 computer-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

13. Examples Major event (Moving object) Major event (Moving object) Major event (Moving object) Text event Text event Broker XGSP event XGSP event Drawing event Drawing event XGSP event Drawing event

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

16. Access / Floor Control Manager Access Type Decision Service Access and Floor Control Decision Service Floor Request Queue Decision Policy Store Current Floor State Information Table Floor Waiting Queue Floor Requesters Chairperson Decision Procedures of XFloor Mechanism(strictly Conflict Avoidance) • This guarantees the mitigation of race conditions of floor requests • to shared application.

17. Access / Floor Control Manager 2. Request Floor 3. Request Floor B R O K E R Request Floor 4. Decision 1. Lock Set Floor 5. Grant 6. Grant (unlock) Non-optimistic Locking Mechanism with Shared Whiteboard • 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.

18. Request-Response Interaction Scheme between a Chairperson and a Floor Requester with Human-Computer Interaction Access / Floor Control Manager B R O K E R Request Floor Request Floor Decision Set Floor Set Floor Decision (Grant, Deny, Queued, Release)

19. Baseline Performance Results 9.37 ms / 1 byte 54.65 ms / 60 KB 2.33 sec / 1 byte 22.18 sec / 60 KB NCSA CGL at IU 0.43 ms / 1 byte 13.79 ms / 60 KB SDSC 2.34 sec / 1 byte 22.86 sec / 60 KB 64.78 ms / 1 byte 353.44 ms / 60 KB 2.58 sec / 1 byte 28.43 sec / 60 KB

20. Baseline Performance Results I

21. Baseline Performance Results II

22. Baseline Performance Results III

23. Experimental Results ITransit Time in Request and Response of Sessions

24. Experimental Results IITransit Time in Request and Response of Sessions

25. Application (Whiteboard) Filter Architecture View Pre-transcoding Problem: as new device or new type of application is added, all types of application have to be updated Display Graphical display data Display Broker (Image or drawing object data) Display Transcoding Filter Post-trancoding Problem: wireless network and cell phone does not support the transfer of more than 60 KB

26. Image Filtering Structure Broker Binary Image Data Binary Image Data Canvas Size (160 x 144) Canvas Size (1024 x 768) Binary Image Data Transcoded Binary Image Data Create Image Create Buffered Image Scale Image Convert to PNG Whiteboard Application Filter

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

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

29. 800x600 JPEG Image on Desktop vs. 158x134 PNG Image on Cell Phone 60 KB (JPEG) 800 x 600 50 KB (PNG) 158 x 134 Shrunk size 0.2 x 0.2

30. Experimental Scenario Overview Broker Access 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) • 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))

31. Overhead Timing Considerations Ttotal = Td + Tw + Tn Td Tw Tn = Treq + Tres Access Request Queue Broker Decision Procedure Decision Response Chair node Request nodes Total latency (Ttotal) = Waiting time (Tw) + Decision time (Td) + Network transit time (Tn = Treq + Tres)

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

33. Experimental Results VIReply + Non-Blocking vs. No-Reply + Blocking 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 modelingrepresentation of the control mechanisms.

35. XML based Control Mechanism Modeled by CP-nets

36. Simplied XML based Control Mechanism Model Unlock Request Queue Critical Section Access and Floor Control Decision Service Current Floor State Information Table Arrival Waiting List Queue Send Decision Request Nodes Communication Service Init Real Code Simulation Start Access Type Decision Service Policy Store Nodes

37. Contribution • Building of Universal XGSP Collaboration Framework on both mobile device (cell phone) and non-mobile device (desktop) • Defined general session protocol in XML (XGSP) • This includes another colleague’s contribution on desktop • Designed and implemented XRBAC • The use of role based on users’ privileges and devices’ capabilities • Scalability, Flexibility, Fine-grained access control • Designed and implemented XFloor • Provides flexibility from free-for-all to application specific floor control mechanism • Chairperson-mediated interaction control with strictly conflict avoidance and non-optimistic locking mechanism • Building of application filter for cooperation of heterogeneous types of whiteboard application • Shared display model and shared event model • Building of application proxy for Instant Messenger • Shared event model • Building of collaborative applications on cell phone • Text Chat, Instant Messenger, Shared Whiteboard with Image Annotation • 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 applications 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