A Reliable Multicast Framework For Light-Weight Sessions and Application Level Framing

1. A Reliable Multicast Framework For Light-Weight Sessions and Application Level Framing Sally Floyd, Van Jacobson, Ching-Gung Liu, Steven McCanne, Lixia Zhang IEEE/ACM Transactions on Networking, Volume 5, Number 6, pp.784-803, December 1997. Presented by: Sean Boyden March 30, 2005

2. Contents • Background & Motivation • Design of Reliable Multicast • SRM Framework • Other Issues • Conclusions

3. Background & Motivation (I) • Several generic reliable multicast protocols have been proposed (e.g. ALF). These use the role of TCP in unicast transmission as motivation for design. • Reasons for this include the fact that different mcast applications require different networking requirements, e.g. in-order delivery, latency, etc. • A good design would leave the specific requirement implementation up to the application rather than the mcast transport layer.

4. Background & Motivation (II) • SRM uses the underlying concepts developed by ALF. ALF left as much functionality and flexibility as possible to the application. • Thus SRM was designed to meet only the minimal definition of reliable multicast: • Eventual delivery of data to all of the group members. • SRM realizes that different applications require different error recovery, flow control, and error control schemes and that these mechanisms must explicitly account for the structure of the underlying application data structure.

5. Background & Motivation (III) • SRM is largely based on the group delivery model of IP multicast. • SRM enhances the mcast group concept by maximizing information and data sharing amongst members. • Strengthens individuality of membership by making each member responsible for its own correct reception of data.

6. Background & Motivation (IV) • SRM attempts to follow the core design principles of TCP • Requires only basic IP delivery model (best-effort) • Requires no modification or special support from underlying IP network • Algorithms in SRM dynamically adjust their control parameters based on the observed performance within a session.

7. Contents • Background & Motivation • Design of Reliable Multicast • SRM Framework • Other Issues • Conclusions

8. Design of a Reliable Multicast (I) • Some party must be responsible for detecting loss and recovering from it. • In TCP, the sender detects loss, however this approach has many drawbacks in a multicast environment • Since receivers send ACKs or NACKs, this can result in an ACK implosion. • IP multicast deliberately imposes an indirection layer so achieving this would be expensive • Existing algorithms become meaningless – how do you estimate RTT; bw-delay product for receivers whose values may be different by orders of magnitude?

9. Design of a Reliable Multicast (II) • Sequencing Issues • Reciever can request retransmissions either in terms of application data units (NFS) or in terms of communication state (TCP). • Comm. state allows application-independence, but since mcast has weaker and more diverse communication state synchronization, this doesn’t make much sense. • Use Application Data Units (ADUs) for multicast. • This also allows any member of mcast group to fill a retransmission request.

10. Design of a Reliable Multicast (III) • ALF results in a framework that is filled in with application-specific details. • SRM follows this, however, certain portions of the framework are completely determined by network dynamics and scaling considerations. • Each application using SRM provides the reliability framework with a namespace to talk about what data has been sent and received.

11. Contents • Background & Motivation • Design of Reliable Multicast • SRM Framework • Other Issues • Conclusions

12. SRM Framework (I) • SRM Assumptions: • The data has unique, persistent names. • The application allows the imposition of a hierarchy upon the namespace (for scalability). • Data space is divided into groups (pages).

13. SRM Framework (II) • Whenever a member generates new data, this data is multicast to the group. • Each member of the group is individually responsible for detecting loss, generally by detecting a gap in the ADU sequence space, and requesting a retransmission. • Since it is possible that the last object of a sequence is lost, each member multicasts a low-rate, periodic session message that announces the highest sequence number received from each member from the current page. • In addition to reception state, the session messages contain timestamps used for estimating temporal distance from each member to every other

14. SRM Framework (III) • To prevent control packet implosion, SRM uses a slotting and damping system to control the sending of request and repair messages. • Instead of using a random delay as in previous protocols (e.g. XTP), the delay in sending a packet is a function of a member’s temporal distance from the node that triggered the request or repair. • Request and repair messages are multicast to the entire group: if a number of hosts miss the same packet, a host close to the point of failure is likely to timeout first and multicast the request. • When other hosts detecting a loss see this request, they suppress their own requests. • Any host that has a copy of the requested data can answer a request. The repair mechanism uses a similar scheme – each has a timer that is set as a function of the temporal distance of the repairing host to the host that requested a repair.

15. SRM Framework (IV) • This mechanism doesn’t require that all session members keep all of the data, so long as each data is available from at least one member. • Ideally a loss generates only one retransmit request and one corresponding repair reply.

16. SRM Framework – Session Messages (I) • Each member multicasts a periodic session message that report the sequence number state for active sources. • This allows receivers to detect the loss of the last packet of a burst and enable senders to monitor the status of receivers • Can also be used to determine current participants of a session. • The bandwidth consumed by these messages is limited to a small fraction (e.g. <5%) of the aggregate bandwidth through dynamically adjusting the frequency based on the number of members in a group.

17. SRM Framework – Session Messages (II) • In a large, long-lived session, the state would be unmanageable if receivers had to report the sequence numbers of every member that had sent it data. To prevent this explosion, SRM imposes a hierarchy on the data. • State-space is divided into “pages” • Each member reports state only for the page that it is currently viewing.

18. SRM Framework – Loss Recovery (I) • SRM offers: • An adaptive mechanism for timers • Local recovery mechanisms for scalability in large congested multicast groups. • Members who detect a loss wait a time then mcast a repair request. This request suppresses other members’ requests for the same loss. • This differs from traditional NACKs as the requests are not addressed to a specific sender and represent data by a unique persistent name rather than communication state.

19. SRM Framework – Loss Recovery (II) • When a host detects a loss, it schedules a repair request for a time in the future. As this request timer expires, the request is mcast to the group and the timer is doubled to wait for the repair reply. • The wait time is a function of the member’s estimated distance to the source of the lost packet, chosen from the a uniform distribution.

20. SRM Framework – Loss Recovery (III) • If a host receives a request for the missing data before its request timer expires then it does an exponential backoff. • If a host B receives a request from host A, it sets a repair timer to a value from the uniform distribution. This functions in the same manner as the request function, however, there is no exponential backoff if it sees another repair reply – it cancels its timer.

21. SRM Framework – Loss Recovery (IV) • Sender of the repair reply does not verify if the requestor actually receives the repair or not. • If the repair reply itself is lost, the receiver’s timer will again expire and a new request issued.

22. SRM Framework – Congestion Control (I) • SRM uses simple congestion control: • Each member of the mcast group receives a fixed bandwidth constraint. • Would function if the group used OOB comm. to confirm bandwidth availability. • Simplistic model probably not adequate.

23. SRM Framework – Network Partitioning (I) • SRM relies on IP multicast groups, where members can arrive and depart independently. • Because of this, SRM does not distinguish between a network partition from a normal departure from the mcast group. • During a partition members can continue to send data into the connected parts of the partition. • After the partition is repaired, the SRM loss mechanism will distribute the missing data.

24. Contents • Background & Motivation • Design of Reliable Multicast • SRM Framework • Other Issues • Conclusions

25. Other Issues • Other requirements of specific applications (e.g. require a partial or total ordering of data) can be built on top of the SRM framework on an app-by-app basis. • Could implement a layer between SRM and applications to take care of apps with similar needs above SRM without building into app itself.

26. Contents • Background & Motivation • Design of Reliable Multicast • SRM Framework • Other Issues • Conclusions

27. Conclusions • SRM framework meets a minimal definition of reliable multicast, and delivering extra functionality if necessary to individual applications. • Based on the assumptions of IP mcast delivery and unique persistent names for both data and sources. • Focused on request and repair mechanisms.