Scalable Reliable Multicast

Overview

• Some Applications need this type of services. e.g.

1. Software Distribution: The software at various site needs to be updated. If the distribution is not done reliably then some copies may have older versions and some may have newer version. And there will be conflict in operation.
2. PPT Slides in Video Conference.
3. Distributed White Board (WB): Assumues that the White Board is being shared by various parties in Group on Network at distant places. If one  party draws on the board and immidiately the drawing of second party follows,  then everybody involved in the group should see the update by first party and then update by second one and not reverse. In the sence the multicast should be reliable.

• For unicast, TCP provides Reliability. However that is not guranteed for the multicast by TCP.

• Reilable Multicast Needs Casual Ordering:

• However the Reodering can happen in the network having chain of the nodes.
• Thus casual ordering is difficult to be provided at the network layer.

• Same strategy does not work for all in multicast, because

• Applications may or may not require ordering
• Also there can be may senders.
• Above all there can be multiple senders of same data. e.g. Replicated servers in Akamai.com etc

Design Goals

• To give flexibility to application: - Ordering, Where data comes from, etc.
• To have no Assumptions about lower layers:- Use Datagram delivery for data transfer.
• To have adaptive parameters:- The provision should be there for the tuning parameters so that performance should be increased.

Design Challenges

• Sender has to maintain state such as receiver has received packet or not.
• as there are multiple receivers, this becomes increasingly difficult.
• Also Receivers join and leave without any notification to the senders.

•  Subset of group may loose packets : As for multicast we first build tree and then send the data on that. If one of the node in the path fails then all nodes below will loose packets. (see fig. 1 below). Thus Sender need to track set of receivers.

Fig. 1

• Thus there will be per receiver state at Sender.
• Another problem is that well defined parameters in unicast may not be of any meaning for reliable multicast. e.g. RTT, CWND, etc.
• And Hence Receiver Based Approch is needed for Reliable multicast

Problem with Sequencing :

TCP uses byte number for sequencing.
However that has problem with multicast.

• Whether to maintain sequence numbers per source or independant of source.
• If we maintain sequence number per source then there will be problem when there are multiple senders of the same data (replicated servers). This is because if one of the server fails then other server may start sending but will be having diffrent sequence number and thus the receiver will be confused and falsely assuming loss of data.
• Sequence number wrap arond can take place and then late joining receivers will not be knowing whether to ask for previos packet as random sequence number are used in TCP at start.
• Also this problem can come with intermidiate partitions.

Solution: Application Layer Framming

• Framming done by the application and thus unit of data is defined by application
• e.g. "Block 5 of sildes.ppt"
• Now FTP /TCP can also use this.
• Now with this technique in multicast, sequence number can be per source or independant of source and anyone having data can retransmit.

---

Reliable Multicast Protocol

• Does not gurantee Ordering
• But gurantees sending of data to all receivers.

General working :

• Each receiver keeps track of the sequence number received (per sender or information in frame)
• Periodic session messages are sent by the each sender. It contains highest sequence number sent so far and also time stamp. (for estimation of RTT).
• This is needed because:
• Assume that sender sends sequence number 1,2,3,4,...
• If sequence number 4 gets lost then receiver is not able to know whether packet has lost or sender has stopped sending the data. Hence sender sends periodic session messages.

On loss detection :
Consider following scenario shown in figure

figure 2

• Each node in the subset (shown inside the circle) will set timer with random values for time outs
• One of them will eventually time outs and fires the multicast-repair-request.
• Anybody having packet then can multicast the packet.

---

Random Timer values

• Repair Timer

1. Uniform in [C1, C1+C2] x d(S,A) , where S is source and A is node for which we are setting value of the timer. 'd( )' is distance function.
2. Here Closest to source will detect loss first as its value of time out will be lowest.

• Responce Timer

1. Uniform in [D1, D1+D2]x d(B,A)

• If C1 high-
• Large repair delay
• But more suppression for farther nodes

• If C2 is high-
• Larger responce delays
• but more suppression for larger group size.

• Similarly for D1 and D2

---

Extentions

There should be Adaptive values for C1, C2, D1 and D2
The values should be adapted based on
- observed delays
- observed duplicate request frequency
Also adaption should be application specific as different applications need diffrent tolerance to delays and no. of duplicates
e.g.
For White Borad - Fast repair are needed
For s/w updates - No need of fast repair.

---