Building a Reliable IP Multicast Distributed System

1. Building a Reliable IP Multicast Distributed System Karl Thomas Rees CS 560

2. System Needs • IP telephone-like application, featuring a client and a dynamic number of operators that “compete” with each other through a system of bids to recognize what language the user at the client end was speaking, and then route the call accordingly. • Architecture should be robust enough to be extendable for use with future NLP projects. • Naturally, IP Multicast is the underlying protocol of choice.

3. Project Steps (minus the NLP) • Design protocol suitable for transfer of sound from client to multiple operators. • Design protocol suitable for transfer of messages between operators and clients. • Design protocol stack /API. • Consider reliability / flow control issues.

4. Sound Recognition Protocol • A “super-protocol” that rests on top of IP Multicast layer:

5. Sound Stream Protocol • Class to encapsulate a sound wave.

6. Foreign Language Recognition System Protocol • Messages between operators and clients

7. FLRS Messages • FLRS_ANNOUNCE • FLRS_BID • FLRS_CLOSE_BIDS • FLRS_ACCEPT • FLRS_REJECT • FLRS_ROUTE

8. API • The famous rees.net package. Trust me, it’s a sweet piece of Java code. • Built to hide networking aspect. Thus, all Operators should extend their “Recognizer” threads from a FLRSPacketHandler that automatically updates the sound wave / calls “recognize” method.

9. Reliability Issues • FLRS Messages must be guaranteed, otherwise entire system can crash. • NLP can be very processor intensive; might not be able to handle real-time sound as it arrives, so we need some method of flow control. • Different operators will be processing the sound waves with different algorithms and therefore at different speeds. Don’t want to limit the performance of the entire system by the flow needs of the slowest operator.

10. “Old School” Reliability Methods • Sender-initiated Go-Back-N or selective repeat mechanism for error recovery. Very expensive, since sender must keep track of state for all receivers in group. • Receiver-initiated error recovery (negative acks) lets receivers keep state, but since we use negative acks, sender must keep very large buffer and make assumptions about when its safe to take something out of the buffer. • Both strategies suffer from the need to re-send the data over Multicast, wasting bandwidth network wide.

11. Tree-based Multicast Transport Protocol (TMTP) • TMTP uses an expanding ring search to dynamically organize the dissemination group members into a hierarchical control tree as members join and leave a group • Receiver driven. Tree structure is exploited to restrict the scope of retransmissions to the region where packet loss occurs; thereby insulating the rest of the network from additional traffic. • Problem—needs to be implemented in switches.

12. Structure-Oriented Resilient Multicast (STORM) • Relies on idea that some loss is acceptable. Also, recognizes that data is time-sensitive. Eliminates expired data; thus loss is usually limited to data that would already be useless. • Might work for Sound Stream (assuming we can deal with loss), but not for FLRS. • Again, implemented in routers.

13. Waypoints • Servers called waypoints will be placed throughout network that participate in the error recovery protocol, supplying repairs to receivers. From the application's perspective, waypoints appear to be additional application endpoints in the network. A third-party approach.

14. Reliable Adaptive Multicast Protocol (RAMP) • Can elect to send either reliable or unreliable.