CS138c Project Proposal:

Reliable Multicast Protocols for Bus-based LANs

Paul LeMahieu and Lihao Xu

The Basic Idea

We are working on implementing a reliable mulitcast protocol designed to take advantage of the inherent broadcast capabilities of many LANs. We are concerned with the reliability of the communication itself and will not be dealing with the issue of node failures. The primary issue is organizing the collection of acknowledges to prevent a source node from being overwhelmed and to acheive the maximal concurrency in acknowledge collection.

Design Options

Multicast with Reliable Point-to-Point

We can always implement reliable multicasting by first implementing reliable point-to-point communications. We can then multicast via a tree, with the root sending to two or more nodes in the multicast group and instructing each child node to further the multicast by acting as the root of a subset of the original group. Reliability is ensured by the reliability of the point-to-point communications. This is wasteful, however, in the presence of unreliable hardware broadcast capabilities.

Multicast with Unreliable Hardware Broadcast

To take advantage of the bus-based nature of most LANs, we can use a hardware broadcast to send the data to the group, and then use a point-to-point acknowledgement scheme to ensure the reliability of the multicast. This is a very efficient way to do multicasts, especially since it lets us take advantage of the simple bus nature of networks such as Ethernet.

The benefits of this protocol are not limited to bus-based LANs, however. Any local area network providing hardware multicast should have an upper layer protocol of this nature. In fact, non-bus-based networks providing hardware multicast will probably perform better since the initial send is concurrent due to hardware (as with a bus-based network), but the point-to-point acknowledges don't suffer from the contention present in a bus-based network. Examples of this kind of LAN are switched Ethernet and ATM switches, which typically provide hardware broadcast as well as contention free point-to-point.

Project Details

Implementation of a hardware-broadcast with acknowledge tree
- The basis of the protocol will be the sliding window protocol of reliable point-to-point. The only significant difference is that now multiple acknowledges must be received before sliding the window forward.
- The tree will be tunable . That is, we'll be able to adjust the degree of collection at each level. This will allow comparison between the simple special case where each group node acknowledges directly to the sender and more general cases.
- We will do the implementation with mayc since this gives a great deal of control over network behavior. The network will be modeled as a separate process, allowing us to introduce various types of error (deletion, duplication, bursty errors) as well as ranges of error rates.
Simulations
To evaluate the protocol, we need to be able to judge its behavior under various conditions. By proper programming we should be able to provide a multicast simulation environment where we can see at what points the benefits of more complicated protocols such as this begin.
- Delay models
  The cost of a message is made up of not only the time on the physical medium itself, but also of the send and receive time at the source and destination machines which correspond to the time required for a message to traverse the software layers down to the medium and back up again.
- Error models
  The type of error introduced in a network can vary. We should show that a protocol such as this can be tailored to fit real error models such as bursty packet losses due to buffer overflow and network congestion.
- Network models
  The simplest model is that of a simple bus, which allows true broadcast but blocking point-to-point. It would be interesting to see how a switched network which gives hardware broadcast and non-blocking point-to-point performs.

Related Issues

There are related topics which we will not be expoloring:

Node failures
Message ordering
This is a question that comes up for any multicast protocol. There are three basic types of ordering properties, ordered from weakest to strongest:
- Single source ordering. This is the weakest property, one that we will provide. It guarantees that multiple message from the same source to the same group are received in the same order by all group members.
- Multiple source ordering. This guarantees that messages from different sources multicasting to the same group are received in the same order by all group members.
- Multiple group ordering. This guarantees that messages from possibly different sources destined to different groups are received in the same order by group members in the intersection of the different groups.