A FRAMEWORK FOR SYNCHRONOUS AND UBIQUITOUS COLLABORATION Advisor

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, School of Informatics Indiana University, Bloomington

v. Outline n n Motivation Research Issues Collaboration Framework Control Mechanisms Ø Ø Ø n n n Session Control Access Control Floor Control Experimental Results Contribution Future Work 2

3

v. Key Terminologies n Session Ø n online workgroup of collaborators working with sharing various collaborative applications. Floor control Ø mechanism by which interaction to synchronous shared application is mediated. Ø n Synchronous collaboration Ø n enable different users of a session to share the same resource in real time (at the same time) Asynchronous collaboration Ø n e. g. shared whiteboard (only one user can draw at a time), or collaborative chess game (only one player can play at a time) allow different users of a session to access the same resource at different times Ubiquitous collaboration Ø capability of multiple users to link together with disparate access devices in anytime and anywhere 4

v. Role Definitions n Administrator Ø n Chairperson Ø Ø n Define policies and manage conference manager Create or destroy sessions Control sessions and participants’ presences in a conference by a set of session protocols Moderator or Master Ø A person who plays a control role in a session Ø n e. g. Control who has a floor for a shared whiteboard Requester Ø Normal user 5

v. Research Issues I n Heterogeneous community collaboration Ø Most heterogeneous community collaboration systems cannot communicate with each other. Ø Ø n e. g. H. 323 <-> AG (Access Grid) We need wider range of collaboration by building integrated collaboration system, which combines heterogeneous community collaboration into a single easy-to-use environment. Ubiquitous collaboration Ø Ø Current virtual conferencing systems lack support for ubiquitous collaboration. Make systems more usable and more useful, and enable people to work together with roaming users as well as others remotely. 6

v. Research Issues II n Access control in collaboration system Ø Ø n The cooperation on the resources shared among collaborators may produce new results on the shared resources. Access control policies and mechanisms are needed to restrict unauthorized access to a variety of protected resources. Group coordination (Floor control) Ø Ø 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. 7

v. Collaboration Framework n n n 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 Ø Ø Ø control manager session / membership control manager access / floor control manager policy manager request and reply event message handlers communication channel 8

v. A Framework Architecture Application Instance Session Control Manager Session/Membership Control Manager Access/Floor Control Manager Policy Manager Join. Conf Handler User. List Handler Join. Conf User. List XGSP Message Session. List Handler Action Request/Reply Handler Session. List XGSP Message Request/Set Action XRBAC Message Communication Channel

v. Broad View Architecture Registries of all scheduled conferences ØUser Conference accounts Manager ØPolicies (Web Server) Ø Application (Instant Messenger) Proxy Application (Whiteboard) Filter Control manager Message / Service Middleware (Broker) User roster Session roster Application Instance 0 Application Instance 1 User Node

v. XGSP (XML based General Session Protocol) n Means control logic defined in XML. Ø Ø n manage presence membership maintain connectivity among collaborators organize online sessions support heterogeneous community collaboration 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 sessions, and presences of users in sessions) 11

v. XRBAC (XML Role Based Access Control) n RBAC is a scheme that describes access rights based on roles in an organization. Ø Ø n 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 Define policies in XML to enable only authorized users to access protected collaborative applications Authorization is performed by explicitly moderator-mediated interaction (request-response) mechanism Flexibility – adapting to the state change of collaborative applications at run time Fine-grained action - defined as the smallest interactive major events (semantic events) 12

v. XRBAC Architecture Conference Manager 6. Activation / Deactivation Service 5. Access Decision Service 4. Pull Policies Local Policy Store 1. Push Policy 7. Decision Response GUI Fine-grained actions Message / Service System Access 2. Access (Broker) Requester 3. Authentication Service Moderator Push mode Øpolicies are passed to a user by conference manager at conference join time Øthis lead to policy consistency KMC (Key Management Center) Pull mode Øpolicies are retrieved from internal store of a user node at access time

v. XFloor (XML Floor Control) n In face-to-face offline session, users generally follow rules of etiquette or social protocol when they interact with each other. n In online session, users usually interact with each other using computer-mediated policies and tools. n n Floor control policy and mechanisms have to be able to provide a floor on shared application for only one user 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 control) Ø ex) Text-chat application Moderator-mediated floor control mechanism Ø ex) Shared whiteboard application Ø Major event conflict detection function (strict conflict avoidance) Ø Non-optimistic locking mechanism Two-player turn-taking mechanism Ø ex) Collaborative chess game application 14

v. Examples nt t) e ev jec r jo g ob a M vin o (M M (M ajo ov r e ing ve ob nt Major event jec t) (Moving object) Text event nt XGSP event en ev g in w nt e ev ra ev e g in D XG SP w ra D e Drawing event XG n ve t Broker t SP Text event

v. XFloor Policy n n Floor policy means how users request applications, how the applications are assigned and released. Request Ø Users can request through the use of XFloor control tool Ø Moderator can directly assign a floor to collaborators Response Ø If the floor is available, a moderator 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 moderator or after a prefixed amount of time. 16

v. XFloor Mechanism n Determination of types classified to access applications Ø <Action> <Action. Name>line</Action. Name> <Capabilities>line drawing</Capabilities> <Access. Type>shared</Access. Type> </Action> Ø n Return types: Exclusive, Shared, Released, Implicit 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 17

v. Decision Procedures of XFloor Mechanism (Strict Conflict Avoidance) Access / Floor Control Manager Floor Request Queue Floor Requesters 2. Access Type 3. Access and Floor Decision Service Control Decision Service Decision 1. Policy Store 4. Current Floor State Information Table Floor Waiting Queue Chairperson Major event conflict detect function is used to avoid the floor conflicts. Ø This guarantees the mitigation of race conditions of floor requests to shared application and thus enforces mutual exclusion among shared application. Ø

v. Non-optimistic Locking Mechanism with Shared Whiteboard Access / Floor Control Manager 2. Request Floor 3. Request Floor B R O K E R 4. Decision 5. Set Floor (Grant) Requester 1. Lock 6. Grant (unlock) Moderator Ø Fine-grained actions are used to allow more concurrent activity among participants. Ø Coarse-grained action can be used to allow a participant to make more activities at a time. Ø This mechanism guarantees that the consistent state at application level is maintained among participants.

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

v. Baseline Performance Results The latency of wired network is in the range of milliseconds. The latency of wireless network is in the range of seconds. 9. 37 ms / 1 byte 54. 65 ms / 60 KB 2. 33 sec / 1 byte 22. 18 sec / 60 KB NCSA CGL at IU SDSC 64. 78 ms / 1 byte 353. 44 ms / 60 KB 0. 43 ms / 1 byte 13. 79 ms / 60 KB 2. 34 sec / 1 byte 22. 86 sec / 60 KB 2. 58 sec / 1 byte 28. 43 sec / 60 KB 21

v. Baseline Performance Results I

v. Baseline Performance Results II

v. Baseline Performance Results III

v. Experimental Results I Transit Time + Processing Time in Request Node in Query and Dissemination of Sessions <Request. Session. List> <User. ID>kakim</User. ID> <Conference. ID>testroom</Conference. ID> </Request. Session. List> <Reply. Session. List> <User. ID>kakim</User. ID> <Conference. ID>testroom</Conference. ID> <Session. List> Session list in testroom conference </Session. List> </Reply. Session. List>

v. Experimental Results II Transit Time + Processing Time in Request Node in Query and Dissemination of Sessions Bloomington Indianapolis San Diego

v. 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 Graphical display data (Image or drawing object data) Broker Transcoding Post-trancoding ØProblem: wireless network and cell phone does not support the transfer of more than 60 KB Display Filter 27

v. Image Filtering Structure 1. Binary Image Data Canvas Size (1024 x 768) 4. Transcoded Binary Image Data Broker 2. Binary Image Data Canvas Size (160 x 144) 3. Transcoded Binary Image Data Create Image Create Buffered Image Scale Image Convert to PNG Whiteboard Application Filter 28

v. Experimental Results III Transfer time of Image from Desktop to Cell phone In our experiments, 1 MB (on desktop) image size is transformed into 52 KB (for cell phone) image size by application 29 filter. Ø

v 800 x 600 JPEG Image on Desktop vs. 158 x 134 PNG Image on Cell Phone 60 KB (JPEG) 800 x 600 Shrunk size 0. 2 x 0. 2 50 KB (PNG) 158 x 134

v. Experimental Scenario Overview Access Request Simulator Moderator Node (Decision Node) Broker Request Node <Request. Action> <Set. App. Action> Request arrivals with exponential distribution with mean interarrival time (3 seconds) Three different network combinations over three different locations: 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 desktop and cell phone together (wired + wireless) (# of requests from desktop =50)+(# of requests from cell phone =50)

v. Overhead Timing Considerations Ttotal = Td + Tw + Tn Td Tw Tn = Treq + Tres Access Request Queue Decision Procedure Decision Response Broker Moderator Total latency (Ttotal) (Completion time of a request) = Waiting time (Tw) + Decision time (Td) + Network transit time (Tn = Treq + Tres) Requesters 32

v. Experimental Results IV Mean completion time of a request vs. Mean request interarrival time (3000 milliseconds) We may need to make the granularity of fine-grained actions larger to reduce the wireless network overhead. Ø but it may decrease the amount of concurrency and violate the principle of least privilege because it may give a user more privilege than needed. We need to observe user’s behavior with applications considering responsiveness vs. concurrency and responsiveness vs. principle of least privilege. Ø 33

v. Experimental Results V Reply + Non-Blocking vs. No-Reply + Blocking Reply + Non-Blocking No-Reply + Blocking Gain of performance from (No-Reply + Blocking) scheme: ØDesktop: 9. 77% (Grid. Farm), 1. 12% (NCSA), 7. 51% (SDSC) ØDesktop + Cell phone: 51. 46% (Grid. Farm), 59. 79% (NCSA), 59. 83%(SDSC) ØCell phone: 84. 88% (Grid. Farm), 87. 42% (NCSA), 86. 96% (SDSC) 34

v. Formal Verification by Colored Petri Net n n 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. 35

v. Abstract Representation of Control Mechanism by Colored-Petri Net 36

v. Simplied Abstract Representation of Control Mechanism Request Queue Arrival Unlock Critical Section 1 Access and Floor Control Current Floor State Decision Service Information Table 3 Waiting List Queue Request Nodes 5 Send Decision Communication Service Init Simulation Start 4 2 Real Code Access Type Decision Service Policy Store Nodes

v. Contribution I System research n Ø A framework for synchronous and ubiquitous collaboration designs a framework for controlling sessions, accesses, and floors for synchronous and ubiquitous collaboration as well as heterogeneous community collaboration XGSP Ø provides a general solution for heterogeneous community collaboration Ø Shared event mechanism XRBAC Ø flexible and fine-grained access control based on RBAC model XFloor Ø show a synchronous collaboration, which means all participants in collaboration always have the same views and data in real time, with a major event conflict detection function and a nonoptimistic locking mechanism Ø provides flexibility from free-for-all to application specific floor control mechanism Formal verification of modeled control mechanisms (XRBAC and XFloor) Ø mutual exclusion, deadlock, starvation 38 Ø Ø Ø

v. Contribution II n System software Ø Ø Ø Building of a framework on both cell phone and desktop Ø Defined general session protocol in XML (XGSP) Ø This includes another colleague’s contribution on desktop Designed and implemented XRBAC and XFloor Building of application filter for cooperation of heterogeneous types of whiteboard applications Building of application proxy for Instant Messenger Building of collaborative applications on cell phone Ø Text Chat, Instant Messenger, Shared Whiteboard with Image Annotation Modeling of control mechanisms (XRBAC and XFloor) Ø Use of Colored Petri-net to prove the correctness of the modeled mechanisms 39

v. Future Work n n Fault-tolerant role delegation mechanism with role hierarchy policy Ø A recovery approach from failure-prone system 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) Ø n n e. g. Collaborative chess game on cell phone Design and implementation of authentication service and encryption service of messages for roaming users with cell phones Support for floor control of synchronous collaborative media applications such as audio / video 40