scribe notes: lec. 22 , Scalable Reliable Multicast

Lecture No. 22 Date :- 8 Oct. 2003 Scribe by :- Surya Prakash Kotha (Y3111049)

Reliable Multicast:

Some Applications of this type of services are

Software Distribution: If the software is distributed at various locations.Then the updation must be done reliably. Unless at some locations have older versions.

Some applications have replicated data, for example in an n-redundant file store, so several members are capable of transmitting a data item while for others all data originates at a single source. These differences all affect the design of a reliable multicast protocol. Although one could design a protocol for the worst-case requirements,

PPT Slides in Video Conference.

Distributed-White board (Wb): Suppose the white board is shared between various members who are at different places. Then the problem is not only promptness but also the order is also important. It requires reliable multicast (both in order of delivery and correctness)

Assumues that the White Board is being shared by various members at distant places. If one member draws a line and after second member draws another line with respect to the first line then the order of display is also very important( it is also called causal ordering).

For unicast, TCP provides Reliability. But TCP does not guarentees reliability in multicast
"One size does not fit in all" for multicast. Since some applications require ordering and some dont. And there may be multiple recievers and senders are possible. For all these one protocol will not fit.

An example of Casual Ordering:

Suppose 3 parties are involved in WB - A, B and C
A Draws Line on WB.
Then B draws line related to A's line.
If application says that these two are casually ordered then Everybody should see updates in this sequence only.
Reordering is not desired here.

The reordering may happen due to the changes in the network topology.
So casual ordering is very difficult to provide at network layer level.

For this Clark and Tennenhouse proposed a new protocol model called Application Level Framing (ALF) which explicitly includes an application' s semantics in the design of that application' s protocol

Design Goals

To give flexibility to application: - Ordering, Where data comes from, etc.
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

Unicast has "fate sharing".
Meaning: if either one of sender or receiver fails then the connection is terminated.
But in multicast as there are number of senders or recievers cont decide about the connection.
In unicast anyone (sender or receiver) can be responsible for reliability.
(In TCP, sender is responsible. It keeps on trying till it gest ack from receiver.)

Sender based approach In multi cast:

The first problem is ack implosion. In multicast there are many number of receivers each will send acknowledgment.
Sender has to track the state of reiceiver (it has received packet or not) as there are multiple receivers this is very difficult.
Also Receivers join and leave without any notification to the senders.
The maintainance of RTT and CWND has no meaning in the multicast.
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.

So reciever based approach is fallowed in 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
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 :

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.