Balanced Batch LKH: New Proposal, Implementation and Performance Evaluation. Josep Pegueroles Departamento de Ingeniería Telemática. Universitat Politècnica de Catalunya. Jordi Girona 1 y 3. Campus Nord, Mod C3, UPC. 08034 Barcelona
[email protected] Francisco Rico-Novella Departamento de Ingeniería Telemática. Universitat Politècnica de Catalunya. Jordi Girona 1 y 3. Campus Nord, Mod C3, UPC. 08034 Barcelona
[email protected]
Abstract Perfect Secrecy can only be achieved in multicast groups by ciphering data sent to the group with a different key every time a member joins or leaves the group. A Key Server must send the new key to all the remaining members so bandwidth efficiency concerns appear. Logical Key Tree algorithms reduce the number of messages to be sent, but in many scenarios, rekeying after each membership change has no sense. Batch rekeying algorithms are proposed as a solution to these problems. However such methods need to maintain the Logical Key Tree balanced all the time in order to achieve maximum bandwidth efficiency. This paper presents a new technique for multicast batch rekeying. This technique reallocates the tree nodes in order to keep the tree balanced all the time.
Keywords Key management, multicast, batch rekeying.
1. Introduction When adding security features to multicast communications a common secret shared by all the multicast group members is needed. The shared key provides group secrecy and source authentication [1]. This key must be updated every time the membership of the group changes. When it does, Forward and Backward Secrecy (FS and BS) are provided. FS means that the session key gives no meaningful information about future session keys, that is to say no leaving member can obtain information about future group communication. BS means that a session key provides no meaningful information about past session keys and that no joining member can obtain information about past group communication [2]. A centralized trusted entity called Key Server (KS) requires N messages each encrypted with a member private key in order to distribute initial group key to a group of N users. Same number of encrypted messages is needed for trivially distributing new group key when membership changes. Several works address the issues of initially distributing the group key to all users and rekey when group membership changes. Most of the methods trying to reduce the number of required messages for rekeying are based on multilevel logical binary trees of Key Encryption Key(KEK) [3,4,5]. When used over a reliable multicast, this approach results in a quite efficient key update mechanism in which the number of multicast messages needed for updating the Session Key is proportional to the depth of the tree. If KEK tree is balanced, depth of the tree is O(log N), where N is the number of members in the multicast group.
However, for large groups, join and leave requests are very frequent and usually bursty in nature. Different scenarios, such as Web-TV, show a high volume of sign-on/sign-off requests at peak times. In these cases, individual rekeying after each join or leave is relatively inefficient. Batch rekeying techniques have been recently presented as a solution to overcome this problem. In such methods, a departed user will remain in the group longer, and a new user has to wait longer to be accepted. All join and leave requests received within a batch period are processed together at the same time. An example of batch rekeying is presented by Lam-Gouda in [6]. Nevertheless, this method assumes that the KEK tree is kept balanced across multiple batches. However, depending on the actual locations of the request, it is possible that the key tree may grow unbalanced after some number of batches. This work presents a new method for batch rekeying that leads to complete balanced trees. The proposed algorithm preserves the Lam-Gouda algorithm simplicity and improves efficiency since no additional rebalancing algorithm is needed. Furthermore, keeping the tree balanced at any time avoids extra rekeying messages due to tree depth beyond O(log N). The rest of this paper is organized as follows. Section 2 presents Logical Key Hierarchy methods as the most common way to increase bandwidth efficiency in secure multicast rekeying. As an example, two state-of-the-art techniques are discussed. Section 3 introduces the Batch Rekeying techniques as a method for achieving more bandwidth efficiency. Section 4 details the new Balanced Batch Rekeying algorithm, including an efficient example of pseudo-code implementation. Finally in section 5, we present performance evaluation of this method and compare it to Lam-Gouda technique.
2. Rekeying in secure multicast. The main problem symmetric session This is the only Backward Secrecy information after
when managing secure multicast groups is to distribute new keys to members every time a user joins or leaves the group. way of achieving Perfect Forward Secrecy (PFS) and Perfect (PBS). That is to say, a member cannot access the group he has left the group (PFS) or before he joined it (PBS).
The trivial way of doing session key as many times secret key shared between that, all the group can session key.
it involves encrypting the message containing the new as members the multicast group has (N). Once with each a Key Server (KS) and the corresponding member. After communicate secretely each other using the multicast
In many scenarios such as Web-TV or multi-party network games, N may be very large, therefore, multicast key distribution leaks scalability. In the last years, many proposals have been published in order to overcome the scalability problem in Group Key Management [7,8,9]. However, the most promising protocols are those based on logical binary trees of KEKs [3,4]. Next we briefly describe two of these techniques.
2.1 Logical Key Hierarchy: LKH In key tree schemes two types of encryption keys are used: Session Encryption Keys (SEK) and Key Encryption Keys (KEK). SEKs are used to cipher the actual data that multicast groups exchange, for example, video streams in multicast videoconference sessions. KEKs are used to cipher the keying material that members will need in order to get the SEK.
Normally, KEKs are structured in logical binary trees. The root of the key tree is shared by all users and the leaf nodes are users' individual keys. We will adopt the next criterion as naming convention for the rest of the paper. Tree nodes will be referenced as (level number,position at level), so we will refer to root node as (1,1); sons of root node will be (2,1) and (2,2) and so on. An example of key tree is shown in Fig.1a. Key in node (X,Y) will be noted as K(X,Y). K
K
K
K
K
K
K
K
K
K
K
K
K
K M7
K
K M1
K M2
K M3
K M4
K M5
K M6
K
K M7
Fig 1a. Example of balanced and complete Logical Key Binary Tree
M8
K
M1
K M2
K M3
M4
K M5
K M6
Fig 1b. Example of balanced and incomplete Logical Key Binary Tree
Consider a group of 8 users. The tree has 15 nodes, each node corresponds to a KEK. Group members are located at leaf nodes. Keys in the leaves are only known by single users. K(1,1) is known by all members in the group. The rest of the keys are revealed only to users considered sons of the node. For example, K(3,1) is known only by users in leaves (4,1) and (4,2), and K(2,2) is only revealed to users in nodes (4,5) to (4,8). The LKH key management scheme works as follows. Consider the multicast group in Fig.1b with N=7 members (M1..M7) and a centralized group controller (KS). Each member must store a subset of the controller's keys. These subset of KEKs will allow the member to get the new SEK when it changes. A generic member (Mj) stores the subset of keys in the path from the leaf where he is to the root. In our example, member M1, in node (4,1), will store K(4,1),K(3,1),K(2,1) and K(1,1). 2.1.1 Managing joinings When a new member (M8) joins the group he must contact the KS via a secure unicast channel. Then they negotiate a shared key that they will use in later interactions (K(4,8)). After that, the controller must update every KEK in the path from the leaf, where new member is located, to the root. See Fig 2a in which new keys are noted with quotes. The KS has to reveal the updated keys to the corresponding users. He uses the existing key hierarchy, along with reliable multicast, to efficiently distribute them as follows. He sends two messages containing the whole set of updated keys, one to each of the members in nodes (4,7) and (4,8), via a unicast channel and using their individual keys. After that, he constructs and sends a multicast message containing K’(2,2) and K’(1,1) ciphered with K(3,3), so only members in nodes (4,5) and (4,6) can decipher it. Finally, he also constructs and sends a multicast message containing new root key K’(1,1) and ciphered with K(2,1), so members in nodes (4,1) to (4,4) can decipher it. At this point, the 8 members in the multicast group know the subset
of keys from their leaves to the root. Every member knows the root key, so this is used to cipher a multicast message containing the new session key (SEK’). 2.1.2 Managing leavings Now, assume that member M4 leaves the group. All keys along the path from node (4,4) to the root must be changed. K(4,4) is simply deleted. See Fig 2b. The updated KEKs are multicasted to the remaining group members encrypted under keys in sibling nodes of the updated ones. In our example, KS first sends the whole set of updated keys to node (4,3) via a unicast channel, and using the individual key of member M3 to cipher it1. After that, constructs and sends a multicast message containing K’(2,1) and K’’(1,1) ciphered with K(3,1), so only M1 and M2 can decipher it. Finally, he sends a multicast message containing K’’(1,1) ciphered with K’(2,2), so members in nodes (4,5) to (4,8) can decipher it. At this point, all keys that M4 knew while he was a member of the group have been updated, so he has been excluded from any future communication. Following the example it is easy to see how the binary tree-based key management scheme can update keys using 0(log2(N)) messages, where N is the number of members in the multicast group. K
K' (1,1)
K
K
K
K
K'' (1,1)
K'
K' (2,2)
K
K' (3,4)
K
K' (2,1)
K
K
K
K' (3,2) K
K
K
M3 K
K M1
K
M2
K M3
M4
K
K M5
M6
K
K M7
M8
Fig 2ª. Example of LKH joining
K
K M1
K M2
K M5
K M6
M7
K M8
Fig 2b Example of LKH leaving
2.2 One way function trees: OFT Following the same logical tree scheme, Balenson et al. [4] proposed a variation of this method for group key management. Their scheme uses a binary one-way function tree (OFT) to store the group's key hierarchy. The structure of the tree is very similar to LKH. The main difference between LKH and OFT is that keys in the tree are not independent. Each interior node key in OFT follows the rule defined in (1) kx = f( g(kleft(x)), g(kright(x)) )
(1)
where left(x) and right(x) denotes the left and right child of the node x, respectively. The function g is one-way, and we call g(k(x)) the blinded function of key k(x). The function f is a mixing function, for example XOR. Each member knows the unblinded node keys on the path from its node to the root, and the blinded node keys that are siblings to its path to the root. In our example, M6 has to store the blinded keys of nodes (4,5), (3,4) and (2,1). See Fig.3
1
Note that new position of member M3 (former node (4,3)) is now (3,2)
K
K
= f ( g (K(3,1)) , g (K(3,2))) K
K
K
K
K M1
= f ( g (K(2,1)) , g (K(2,2)))
M2
= f ( g (K(3,3)) , g (K(3,4)))
K
K
K M3
K M4
K
K M5
K M6
K M7
M8
Fig 3. Example of Binary Tree constructed according to OFT
rules
Now, imagine M6 leaves the group, new blinded key values of nodes (4,5)', (3,4)' and (2,1)' must be sent from the KS to all the appropriate subsets of members.
It is important to remark that the efficiency of these tree-based key management schemes depends critically on whether the key tree remains balanced, that is to say if distances from the root node to any two leaf nodes differ at most by 1. In general, to any leaf the root to balanced is
for a balanced binary tree with N leaves, the distance from the root is log2 N. But if the tree becomes unbalanced, the distance from a leaf can become as high as N. So keeping the key management tree important to achieve maximum efficiency of the technique.
3. Batch Rekeying With binary key tree techniques, individual rekeying has reached his lower bound in number of required messages for rekeying (O(logN)) [10]. Recently, some works have proposed batch rekeying to overcome this limit. In batch rekeying algorithms join and leave requests are collected during a time interval and processed in a batch. Since the KS does not rekey immediately, a leaving member will remain in the group till the end of the batch period, and a new member will have to wait the same time to be accepted. However, this batch period can be adapted to dynamics in the multicast group. On the other hand, batch rekeying techniques increase efficiency in number of required messages thus it takes advantage of the possible overlap of new keys for multiple rekey requests, and thus reduces the possibility of generating new keys that will not be used.
3.1 Lam-Gouda batch rekeying In [6] Lam, Gouda et al. presented a very simple marking algorithm that updates the key tree and generates a rekey subtree. Briefly, their system can be summarized as follows. After each rekey interval the KS collects all Join and Leave requests and processes them according to the two possible cases. If the number of leavings is greater or equal than the number of joinings, new members are allocated in the places of the departed members. Empty leaves are
marked as null. All node keys in the path from the replaced leaves to the root are updated following the rules in LKH. If the number of joinings is greater than the number of leavings a rekey subtree is constructed with all the remaining new members left after applying the algorithm described above. The rekey subtree is allocated under the departed user node with the smallest height.
4. Balanced Batch Rekeying The algorithm explained in the previous section aims to keep the tree balanced through different batches by allocating the rekey subtree under the shallowest node in each rekeying. However, this rebalancing system is only valid when the number of joinings and leavings are very similar, in any other case a periodic rebalancing algorithm is needed. In Fig 4, it is easy to see how the tree grows unbalanced through different batches. In this example, in the first batch, same number of joinings and leavings is requested, so the tree is kept balanced. In Fig 4b members in nodes (4,4) and (4,8) ask for departing the group, but no joining is requested; so nodes (3,2) and (3,4) become leaf nodes with private keys of remaining members. In the third step, Fig 4c, three joinings and no leavings are asked again, this time, the rekey subtree is allocated under node (3,1), the shallowest one. Finally, in Fig 4d two of the members under node (2,2) want to leave the group. After the 4 batches only 6 members are left and therefore only a 4 degree key tree is needed, instead of that, the KS must keep a tree of degree 5. K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
Fig 4b. Members 4 and 8 leave the group
Fig 4a. Batch with same number of leavings and joinings
K
K
K
K
K
K
K
K
Fig 4c. Batch with 3 requested joinings and no leaving member.
K
K
K
K
K
K
K
K
Fig 4d. Batch with two leavings under node (1,1) and no joining.
4.1 Proposed algorithm In order to overcome this inefficiency we propose a new batch rekeying algorithm that keeps the tree balanced for every batch. The algorithm updates not only node keys but also node naming or position, so rekeying nodes can change their original position after each batch following a very simple rule. The KS computered system does not have much more processing load cause he only has to update the position of the nodes using simple rules. Besides that, keeping the tree balanced reduces the total amount of required program memory. In the other side, the new algorithm slightly increases the number of operations to be done by individual members, cause they have to know all the time the position in the tree that they are occupying in order to update it properly. However, this increase is not significant for single multicast members, even if they are devices with low computation capability. Next, we will describe the atomic steps the KS and the individual members must follow to carry out the algorithm. 4.1.1 Key Server Side There are four main actions that the KS has to do every batch: marking the rekeying nodes, prune the tree, make new rekey tree and construct and send the multicast rekeying messages. Mark Rekeying Nodes In the first step, nodes that should be removed have to be pointed out. After collecting the leaving requests, all nodes from leaving members leaves to root need to be updated, so they are marked for deletion. Notice that no replacement with joining members is carried out. This is why the important figure in this algorithm is the reusing of subtree nodes, and in Lam-Gouda algorithm replaced nodes and its siblings also have to be updated. Prune Tree The prune action is very simple, it consists in deleting the marked nodes and keep the subtree structures that remain unchanged. After this action, the KS has to manage three types of elements: remaining subtrees (structures with more than one members), joining members and siblings of leaving members. As the tree is a binary tree, siblings of leaving members cannot reuse any KEK but his individual key, so they should be treated the same way as new joining members. Make New Rekey tree Now, the KS has to construct the new rekey tree balanced following the next recursive criterion. Group all trees of depth j in twos. If any element is left, group it with tree of depth j+1 and treat the result as a tree of depth j+2. The criterion must begin with trees of minimum depth, that is to say, single elements, and be repeated until just only one tree is resulted. Construct and Send Rekey Messages Finally, the rekeying messages have to be sent. These messages should include three information fields: destination node, new position of destination node and rekeying material. The destination node is the node to which sons the message is addressed. This field is used by single members to decide whether the rekeying message concerns to them or not.
The new position is the renaming field of the message. Using this information, users can rename themselves and their keying material. The rules used for renaming are explained in the next subsection. The Rekeying material field is the actual data of updated keys, calculated, for example, according to LKH. 4.1.2 Multicast Member Side Basically the multicast member only has to decide if a multicast rekeying message is sent to him, receive it and update his position and keying material. Receive Rekey Message A single member (located in node (m,n) will only listen to a message if the coordinates of the destination node field (say (i,j)) comply with the following conditions.
m≥i ( j·2
(2)
m −i
) − (2
m −i
− 1) ≤ n ≤ j·2
m −i
(3)
Update Position and Keys After deciding if a message concerns him, node (m,n) and keys are renamed using the new position field (p,q) in rekeying message. The renaming follows the next expressions.
m = p + (m − i) n = q·2
( m −i )
− ( j·2
(4) ( m −i )
− n)
(5)
Re-used keys and new keys are also renamed according to relative position with new node name.
4.2 Pseudo-code implementation Next, a pseudo-code implementation of the algorithm is presented for both parts, key server side and client. The pseudo-code follows the atomic operations that different agents in a secure multicast communication must comply with if the new batch rekeying algorithm wants to be used. 4.2.1 Key Server Side Multicast_Key_Server{ while session_on { handle_event ( ); } handle_event { case{ event = join { process_join ( ) } event = leave { process_leave ( )} event = batch { process_batch ( )} } }
process_join { register_new_member_for_next_batch number_of_joinings++ } process_leave { register_leaving_member_for_new_batch num_leavings_pendientes++ } process_batch { mark_rekeying_nodes ( ) prune_tree ( ) update_tree ( ) send_rekeying_messages ( ) } mark_rekeying_nodes { for every_registered_leaving { mark_nodes_to_root_as_deleted } } prune_tree { for every_marked_as_deleted_node { if node_has_non_deleted_sons { node_is_marked_as_subtree_root } } } update_tree { while number_of_subroot_trees > 1 { find deepest_subroot_tree find deepest_subroot_tree group_subroots_and_mark_as_new_subroot_tree update naming } } }
It is important to note that the most important function from all the above described ones is update_tree(). This function shows the main differences between the proposed balanced batch LKH algorithm and the Lam-Gouda technique. In the update_tree step of the algorithm, subtrees that can be reused are treated the way they lead to a minimum number of rekeying messages and balanced new key tree.
4.2.2 Multicast Member Side Multicast_Key_Client{ while session_on { listen_to_multicast_channel( ) } listen_to_multicast_channel { if rekeying_message { check_if_I_am_son_of_the_destination_node_field update_my_position_and_key_names } } }
5. Performance evaluation There is a long history of network and Internet traffic analysis. The majority of this, however, looks at packet level and network level traces, and does not examine session level user dynamics. We want to study and simulate the behavior of our new algorithm, so we had to consider different models to generate join/leave request patterns. Next we present the different considered scenarios and the used models.
5.1 Benchmark scenarios Two benchmark scenarios are given in [2] as those to consider when studying or simulating multicast systems: single source broadcast and virtual conferences. However, we have included a third one in order to fit more precisely the real multicast world. We have used three simple models to generate user behavior patterns, one for each of the mentioned scenarios. Next we briefly describe how we have considered them. 5.1.1 Single source broadcast In this scenario a single source continuously broadcasts data to a large number of recipients. A typical example of this scenario is Pay-TV. The number of recipients can be up to hundreds of thousands and more. The lifetime of the group is usually long. Group membership is dynamic: members join and leave at a relatively high rate. At peak times a high volume of sign-on/sign-off requests are expected. Almeroth and Ammar [11] started the study of user behavior for single source multicast sessions many years ago. A simple way of modeling user behavior at session level is by means of exponential distribution interarrival time. We have used two exponential random number generators to simulate request arrivals at KS. One for joinings and another one for leavings. In Fig 5 it is shown a sample pattern of our model for single source broadcast and the histogram for Web-TV interarrival time.
Fig 5. Join/Leave pattern for virtual conference benchmark scenario
5.1.2 Virtual conferences Virtual conference scenarios include on-line corporate meetings, interactive lectures... A virtual conference involves several tens to hundreds of peers. Usually most, or all, group members wish to transmit data. The group is often formed per event and is relatively short-lived (say, few minutes or hours). Membership is often static: members join at start-up, and remain signed on throughout. We have found no studies about user behavior modeling for virtual conferences. However, according to the previously mentioned features, we have developed a very simple model that we have used for virtual conferences. A random number of users stablish a virtual conference. After a random period of time users begin to join/leave the group following an exponential interrequest time statistics. See Fig 6.
Fig 6. Join/Leave pattern for virtual conference benchmark scenario
5.1.3 Multiplayer video games In multiparty networked games the number of players strongly depends on time-ofday and network externality effects. The presence of other users alters other users behaviors. Player interarrival times are highly correlated at short lags which implies that the arrival of some users will lead to others arriving.
Moreover, interarrival times and number of players in a session shows an inversely proportional relationship; as the number of players in a session increases, the interarrival time decrease. So number of players is a deteminant in other player’s decisions to join a group. In [12] Henderson and Bhatti found that interarrival times for networked games follow a heavy-tailed distribution. We have used this result to generate patterns according to lognormal distribution for joinings and exponential for leavings. See Fig 7.
Fig 7. Join/Leave pattern for virtual conference benchmark scenario
5.2 Results Simulations for the comparison of our new algorithm to Lam-Gaouda batch rekeying were done. As expected, in all cases the balanced algorithm showed a better behavior than Lam-Gouda in terms of tree depth. Next, results for the three different benchmark scenarios are considered. Statistically generated join/leave patterns were used. The pattern life for network games was 12 hours considered every second (x axis). Except in case of peak times, only a joining or a leaving can be considered every second. Different batch periods were considered, from 5 minutes to 50 minutes (y axis). In Fig 8 it is plot the tree depth behavior for the two considered algorithms (z axis). It can be seen how the balanced batch rekeying method leads to less depth for all the cases.
Fig 8. Comparison of tree depth evolution for Lam-Gouda and balanced batch rekeying algorithm in networked games environment.
Results for virtual conference show similar behavior. It is important to note that joining/leaving traffic pattern was generated to fit a monotonic increase in number of members. For virtual conference, only a life of an hour was considered (x axis). Measures were taken for different batch periods (y axis), and population was dynamic but always between 256 and 512 members. In Fig 9 can be easily seen how the balanced algorithm preserves the same tree depth for every time and batch, while Lam Gouda tree depth increase with time.
Fig 9. Comparison of tree depth evolution for Lam-Gouda and balanced batch rekeying algorithm in virtual conference environment.
Finally, web tv environments for a period of monotonic increase of number of members have the same same behavior. Differences in the increase rhythm can be explained according to peak time arrivals. As new members arrive in a batch at peak times, Lam-Gouda algorithm has to construct a very big rekey subtree and allocate it in the old tree, this makes the tree grow quickly. Instead of that, balanced algorithm, reconstruct the whole tree and achieves a slowly growth.
Fig 10. Comparison of tree depth evolution for Lam-Gouda and balanced batch rekeying algorithm in web tv environment.
6. Conclusions In this research, we have presented a new rekeying technique for batch joining and leavings. The new method is based on Logical Key Hierarchy protocol but avoids rekeying for every single membership change. Unlike other existing batch rekeying methods, the proposed technique keep the Key Tree balanced all the time. Balancing the tree reduces the number of encrypted messages to be sent in order to distribute the new session key. Examples of pseudo-code implementation of the algorithm and results for performance evaluation have also been presented.
Acknowledgments This work is supported by the Spanish research council under project DISQET (CICYT TIC2002-818) and CREDO (CICYT - TIC2002-00249)
References [1] Wallner, Harder, Agee. Architectures. RFC2627. 1998
Key
Management
for
Multicast:
Issues
and
[2] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B. Pinkas, it Multicast security: A taxonomy and some efficient constructions INFOCOM 99. Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 2, pp. 708-716, 1999. [3] Harney, Harder. Logical Key Hierarchy Protocol (LKH). I-D Harney-spartalkhp-sec-00. Mar 99. Work in progress. [4] Balenson, McGrew, Sherman. Key Management for large Dynamic Groups: One-Way Function Trees and Amortized Initialization. Aug 2000 I-D irtf-smuggroupkeymgmt-oft-00. Work in progress [5] Canetti, Malkin, Nissim. Efficient Communication Multicast Encryption. Eurocrypt99 pp 456-470 1999
Storage
Tradeoffs
for
[6] Li, Yang, Gouda, Lam. Batch Rekeying for Secure Group Communications}. ACM SIGCOMM 2001, San Diego, August 2001 [7] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer, it Group Secure Association Key Management Protocol (GSAKMP), draft-irtf-smug-gsakmp-00.txt, November 2000, Work in Progress. [8] H. Harney, C. Muckenhirn, Group Specification, IETF, RFC 2093, July 1997.
Key
Management
Protocol
(GKMP)
[9] T. Hardjono, B. Cain, Simple Key Management Protocol for PIM}, draft-ietfpim-simplekmp-01.txt, Feb 2000, Work in Progress. [10] Snoeyink, Suri, Varghese (2001). Distribution}. IEEE INFOCOM 2001.
A
Lower
Bound
[11] Almeroth, Ammar, (1997) Multicast Group Behavior Multicast Backbone (MBone), IEEE Communications, June 1997
for
in
Multicast
the
Key
Internet's
[12] Henderson, Bhatti (2001). Modelling user behavior in networked games. Proceedings of ACM Multimedia 2001, Ottawa, Canada, pp212-220, October 2001
