Lecture 6

• Bandwidth allocation in multirate multicast is significantly more complicated than the unicast network.

• There can be several bandwidth allocation objectives.– Fair Allocation– Utility Maximization

Transmission of Layered Multicast

• Receiver Driven Layered Multicast (RLM)

• S. Mccanne, V. Jacobson and M. Vetterli,``Receiver Driven Layered Multicast,’’ Proceedings of ACM SIGCOMM 1996, October 1996

RLM

• Every layer is transmitted as a separate multicast group.

• Receivers join and leave groups depending on the bandwidth contention.

• Ideally all receivers would like to receive all layers for good quality of reception.

• However, bandwidth limitations do not allow receivers to subscribe to all layers.

• So receivers should subscribe to the maximum number of layers that do not congest the network.

Initially, all receivers subscribe to the lowest layer.

Receivers conduct join experiments time to time.

If a receiver does not experience significant packet loss for some time, it joins a layer on an ``experimental’’ basis.

If the join experiment causes congestion in the network, it leaves the layer.

Otherwise, the receiver retains the layer.

If at any time, a receiver experiences congestion, it drops the highest layer is subscribes to.

Congestion may be because of decrease in link capacity, or other receivers conducting join experiments.

Receivers learn from the outcomes of other join and leave experiments (shared learning)

If another receiver fails in an add layer experiment, then the inference is that the network is congested, and receivers do not conduct add layer experiments for some time.

Burden of choosing the right level of subscription is left to the receivers

So the source is not burdened with handling the subscription levels for all receivers.

Hence, RLM is scalable.

Defects in RLM

The protocol is not scalable because every receiver needs to know the outcome of experiments of all other receivers.

Hence, every receiver needs to maintain and process a lot of information.

Also, a receiver should not drop the highest layer whenever it is congested.

This is because some other receiver sharing its path, may already be subscribing to a higher layer, and this higher layer is causing the congestion. So, leaving a lower layer may not help.

1

2

Layered Video Multicast with Retransmissions (LVMR)

There is scope of retransmission of lost packets

Receivers do not keep track of the outcome of join experiments of other receivers, but there are other nodes responsible for storing the information.Every receiver takes permission from these responsible nodes before conducting any join experiments.These responsible nodes also issue leave notices for particular layers to receivers in their area.

``Layered Video Multicast with Retransmissions (LVMR): Evaluation of Hierarchical Rate Control,’’ X. li, S. Paul, M. Ammar, INFOCOM 1998

R1 R2 R3R4 R5 R6

R7R8

A node (n1) is in charge of R1, R2, R3

A node (n2) is in charge of R4, R5, R6

A node (n3) is in charge of R7, R8

R1, or R2 or R3 takes join experiment permission from node n1.

A node n4 is in charge of n1 and n2, etc.

If R1 is using 4 layers, then n1 can give permission to R2 to conduct experiment of joining the 3rd layer.

If the max. layer under a nodes jurisdiction is k, then it can give permission to any node for trying to join layers 1,…k, otherwise it passes the request to a higher node.

A node gives permission to only one experiment under its jurisdiction at a time, else the outcomes of the experiments will be confused.

Layer Drop Events

Whenever a receiver experiences congestion, it reports its highest layer number to the node in charge.

The node broadcasts the layer number to all nodes under its charge.

All nodes receiving such congestion information leaves their highest layer, if the highest layer is greater or equal to the reported layer number.

If the congestion is the outcome of a join experiment to the highest layer for the receivers under its charge, then send the congestion info to nodes higher in the hierarchy as well.

If the congestion info reaching from a lower node is regarding the highest layer currently in the domain of a higher node, it broadcasts the info to the receivers under its control for shared learning, and sends the information further up-wards.

Other Alternatives For Network Heterogeneity

• S. Cheung, M. Ammar, X. Li, ``On the use of Destination Set Grouping to Improve Fairness in Multicast Video Distribution’’, INFOCOM 1996

• Group receivers, with ``similar receivers’’ in the same groups

• Transmit different streams at different rates for different groups

• Tradeoff between Bandwidth Inefficiency and stream granularity

Fairness Problems

Does not discuss the splitting of bandwidth between different sessions.

A session which joins later is at a disadvantage, because the entire bandwidth is grabbed by the other sessions.

Any join experiment will lead to congestion for the session.A solution is to have different dropping thresholds for different layers, i.e., a receiver having a higher number of layers drops its highest layer more easily than one with lower number of layers in the event of congestion

Multisession layered video for rate controlled Multicast

X. li, S. Paul, M. Ammar

Reliable MulticastPackets may be dropped in the links and buffers due to congestion or link errors

Need retransmissions in the event of errors.

TCP gives reliability to IP

Normally, real time traffic like audio, video are loss tolerant, but delay sensitive and do not require any retransmission

But data traffic can tolerate delay, but not loss and needs retransmissions

Reliable unicast protocols require the receiver to ACK a successful transmission and NACK an erroneous packet, if an error is detected. If there is no ACK, or there is a NACK then the packet is retransmitted.

Similarly, every receiver can send acknowledgements in multicast, and the source can retransmit missed packets.

However, this overwhelms the source if there are many receivers, and also the source need not retransmit the packet to all receivers, but only to those who misses the packet.

So there is a serious scalability problem.

Reliable Multicast Protocols

Scalable Reliable Multicast, S. Floyd, V. Jacobson,S. Mccanne, C. Liu, L. Zhang, Sigcomm 95

Whenever a receiver misses a packet, it sets up a random timer.

The random timer is related to the distance between the source and the receiver (the random number is normally lower for receivers close to the source).

A receiver multicasts a repair request whenever the timer expires.

A receiver suppresses the request if it hears a request from another receiver.

Normally, a receiver closer to the source sends the repair request before any other receiver.

The source needs to handle only a few repair requests, even if many receivers miss the packet.

Whenever a receiver hears a repair request, and has the data packet, it sets up another random timer.

It multicasts the data packet when the timer expires.

Any other receiver hearing the data packet retransmission suppresses its timer.

Again only a few receivers multicast the same packet.

Cry baby problem

Suppose there is a receiver with an error prone link (wireless link).

All receivers are somehow involved in sending a data packet to this receiver every time there is an error (needs to set up timers etc.).

This is inefficient overall.

Reliable Multicast Transfer Protocol (RMTP)

S. Paul, K. Sabnani, J. Lin, S. Bhattacharya, JSAC April 1997

This protocol follows a hierarchical approach.

There is a designated receiver, DR for each zone.

The DR sends ACK/NACK to the source depending on the packets it receives from the source.

Whenever a receiver misses a packet, it sends a request to its local DR.

If the DR has the packet, it sends it to the receiver, else it sends it to the receiver when it gets the packet retransmitted by the source.

Again the source handles much fewer ACKs/NACKs

We can have a hierarchy of DRs, lower DRs reporting to higher DRs etc., to reduce the load on the source.

Local DRs handle crying babies, if any.

Network Security (Unicast)

• Privacy of communication– Communication is encrypted by a mutually agreed key

between two parties– Y = f(X, Key) (encrypting) X = g(Y, Key)(decrypting)

• Y = X (xor) Key, X = (X (xor) Key) (xor) Key, X = Y (xor) Key

– Key is crucial to secrecy – Rekeying done at intervals or at session termination– During rekeying, message must be exchanged between two

nodes.

• Authentication– Need to prove identity

Authentication

• Public Key signature (RSA)– A user has a public key and a private key. – Everyone else knows the public key (published in a

directory– Only the user knows the private key– Sender sends Y, where Y = f(X, private key), where X

is the message along with X– Receiver does Z = g(Y, public key). If f and g are

rightly chosen, Z = Y, and this means the sender has used his private key, which is known only to the sender.

– This is like a signature.

Message Authenticaton Codes

• However, public and private key operations are time consuming.

• Using Message Authentication Codes (MAC) is another option

• A MAC is a function which takes a secret key k, a message M and returns a value MAC(k, M). Sender sends the MAC value along with the message.

• If sender and receiver both know the secret key, then the receiver can repeat the MAC computation, and be sure of the senders identity.

• MAC computations are faster.

Multicast Security

• Multicast Security: A taxonomy and Some Efficient Constructions, R. Canetti, J. Garray, G. Itkis, D. Mcciancio, M. Naor, B. Pinkas, INFOCOM 1999

• A mutually agreed key is used to encrypt and decrypt all messages in a multicast session.

• It is important that only members of the multicast group are able to decipher the messages communicated for the group.

• When a receiver leaves a group, then the common session key must be changed.– Else the receiver will follow the messages without being

part of the group.

Also, when a member joins newly, then the session may want to use new keys so that the new member can not decrypt the information exchanged while he was not a part of the group.

In this case, the new key may be encrypted with the old key for the existing group, the old key discarded, and the new key send to the new member via a secure unicast communication.

Any problems with this approach?

Member Revocation

The new key must be secretly communicated otherwise non-members will decrypt the messages for the intended group.

The secret communication should not be encrypted with the old key, because then the departing receiver will get hold of

the new key.

Member leaving a group

A simple solution is to share a separate secret key between the source and every destination and

send the new secret key encrypted with the separate keys for all the existing receivers

However, the problem with this approach is every time a receiver leaves, we need to carry out n encryption decryptions, where n is the number of existing receivers,

And the source needs to know total n keys

So the approach is not scalable.

It is possible to have a key distribution scheme which needs O(log n) encryption decryption schemes every time a receiver leaves.

D. Wallner, E. Harder and R. Agee, ``Key Management for Multicast: Issues and Architectures’’, draft-wallner-key-arch-00.txt

N0

N00N01

N000 N001 N010N011

a bc d e f g

K000 K001 K010K011

K00K01

K0

K0000K0001

K0010K0011 K0100

K0101K0110 K0111

b

Node Ni gets key Ki

A receiver gets all the keys in its path.

Receiver a gets Keys K0, K00 K000 K0000

The session messages are encrypted by key K0.

N0

N00N01

N000 N001 N010N011

a bc d e f g

K000 K001 K010K011

K00K01

K0

K0000K0001

K0010K0011 K0100

K0101K0110 K0111

b

How many keys are in the system?

What is the depth of the tree?

When a receiver leaves, all keys in its path are replaced

If Receiver g leaves Keys K0, K01 K011 are replaced.

N0

N00N01

N000 N001 N010N011

a bc d e f g

K000 K001 K010K011

K00K01

K0

K0000K0001

K0010K0011 K0100

K0101K0110 K0111

b

Replacement of Key K011 is encrypted by K0110 and either multicasted or just communicated to f

Replacement of Key K01 is encrypted by new K011 and old K010 and multicasted to entire group or selectively to d, e, f

Replacement of Key K0 is encrypted by new K01

and old K00 and multicasted to entire group.

There are log n keys in the path.

Each key is encrypted with at most two keys.

Hence O(log n) encryption decryptions are required.

We still need to store n keys.

Can we get away with storing just O(2log n) keys?

Key Management for Secure Internet Multicast using Boolean Function Minimization Techniques, I. Chang, R. Engel, D. Kandlur, D. Penderakis, D. Saha

The system has 2log n keys.

Have a binary id for each receiver.

So the binary ids have log n bits. System has 1 key corresponding to each possible value of a bit. Key x represents 0 value of a bit, and x represents 1 value of a bit.

Keys representing complementary bits need not be complements of each other.

If the id of a receiver is 000, then it gets keys x0’ x1 , x2.

A receiver with id 001 gets keys x0’ x1 , x2.

In addition every member has a session key for encrypting/decrypting the message.

When a receiver leaves, a new session key is sent encrypted with the keys which represent the complement of the id of the leaving receiver.

The departing receiver does not have any of the keys,

But any other receiver have at least one of the keys.

For example, if 000 departs, then the session key is encrypted with x0, x1 , x2. Let the encryption of new key with key Ki be Mi , then M0 M1 M2 are transmitted.

The keys held by the departing receiver must also be changed.

For example, keys x0’ x1 , x2 must be changed.

New Key Kn = f(new session key, old key Kn)

Rekeying encryption/decryption has O(log n) complexity as before.

There are O(log n) keys in the system.

This method is particularly efficient for simultaneous revocation of multiple receivers

Typically, rekeying is not done every time a receiver departs, but at intervals. In regular intervals, quite a few receivers may depart.

A simple solution is to multicast the new key with all keys corresponding to each member.

For example, let 000 and 111 depart.

Six encrypted versions are sent, one corresponding to each existing member.

The version corresponding to 001 is successively encrypted by x0’ x1 , x2.

Each version can be decrypted by the targetted member only, and no version can be decrypted by expelled members.

However there is a lower complexity scheme.

The ids of each member can be represented by a boolean function, (001 is x0x1x2).

Keys should be used such that the function for each remaining member evaluates to 1, and that for each departing member is 0.

The minimum number of encryptions required for that can be found by a boolean function minimization.

Karnaugh map techniques can be used.

However, this scheme is not collusion resistant.

Receivers can group to fool the system.

Message Authentication

Suppose there is just one key used by all members in the system to authenticate themselves.

Clearly, the receiver can not tell which member in the group is the source. It knows whether a message is sent by a group member or not by checking the MAC value, but does not know which member sends it.

A simple solution is that each member has its own key, and computes MAC with its individual key. A receiver can compute MACs with all keys of group members. Only the one computed with the correct senders key matches the MAC.

Again, there is the usual scalability problem, as each member needs to maintain n keys.

The paper by Canetti et al (INFOCOM 2000) suggests a scheme where one needs to store only k keys if there are at most k corrupt users.

It is assumed that k corrupt users try to put together their keys to get the key of any one sender, and then use it to generate the MAC so as to fool the receivers.

Each user is given a set of random keys.

The sender has all keys.

The composition of the keys are such that all the keys of a user is not a subset of the keys of any group of k users, with very high probability.

A sender adds MACs computed by every key.

A receiver checks the MAC with each of its keys.

It rejects the message unless all MACs match.

Since its keys are not subset of those of the colluding users, colluding users will not be able to fool the receiver (with very high probability). Why?

We need O(k/q) keys overall,

k is the number of corrupt users

q is the tolerable collusion success probability.