A Reliable Multicast Framework for Light-weight Sessions. and Application Level Framing. Sally Floyd, Van Jacobson, Steve McCanne.

Transcription

1 A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing Sally Floyd, Van Jacobson, Steve McCanne Lawrence Berkeley National Laboratory Ching-Gung Liu University of Southern California Lixia Zhang Xerox PARC SIGCOMM 95 Cambridge, MA 1 September 1995

2 Errata: Figure 3 in the proceedings contains the wrong figures Graphs all show Delay/RTT that is 05 too big (eg, 30 should be 25) Corrected paper and tech report (longer version) available at: ftp://ftpeelblgov/papers/srmpsz ftp://ftpeelblgov/papers/wbtechpsz fjmlz SRM 2

3 Why Multicast? Efficiency (only one copy of data per link, independent of number of receivers) Group queries (can request data without knowing who has it) fjmlz SRM 3

4 The World used to be so simple Application data Protocol Application data Protocol fjmlz SRM 4

5 but multicast changes the rules Sender can t keep state for unknown number of receivers Algorithms based on estimating path properties (RTT, congestion window) don t generalize to trees Model of communication as conversation breaks down fjmlz SRM 5

6 Most work on reliable multicast attempts to condition environment so unicast transport models will work Eg, Chang & Maxemchuk (and derivatives like RMP) form members into token ring; MTP elects a central controller These approaches have serious scaling problems (Forming ring or electing leader require group-wide agreement which is expensive and problematic when membership changes frequently) fjmlz SRM 6

7 At SIGCOMM 90, Clark and Tennenhouse proposed a new communication model, Application Level Framing (ALF), that easily generalizes to multicast Some key parts are to let applications manage the communication, speak in application data units (eg, video frames, disk blocks) and use an applicationspecific namespace for data (eg, filename & sector offset) fjmlz SRM 7

8 Since 1991, we have been trying to elaborate the ALF model One piece we ve developed is a scalable, reliable multicast framework, SRM It is fully decentralized (no ring or central controller) and handles arbitrarily large groups A complete protocol using the framework has been implemented in the LBL whiteboard tool, wb, and tested on the MBone Wb has been in widespread use since 1993 for conferences with anywhere from two to several thousand participants fjmlz SRM 8

9 SRM Reliability Machinery All traffic is multicast Each session has a bandwidth limit Anyone can send if have data and aggregate traffic is under limit All members send low-rate reports that contain their current state Report sends randomized and rate limited to 3% of session bandwidth fjmlz SRM 9

10 SRM Reliability Machinery (cont) Receivers learn they re missing data either from hole in sequence space or from someone s report Receivers multicast a repair request to ask for missing data Anyone that has data can reply, not just original source of data fjmlz SRM 10

11 Ack Implosions A 2 1 B C D fjmlz SRM 11

12 Ack Implosions (cont) A synchronized repair requests 1? 2 B 1? 2 1? 2 C D fjmlz SRM 12

13 Avoiding ack implosions Every node estimates distance (in time) from every other node (Info for this carried in session reports) Nodes use randomized function of distance to decide when they should request repair (or reply to a repair request) Receipt of request or reply causes node to suppress its own attempt fjmlz SRM 13

14 Distance Estimates i j Si Si MsgT MyT Dist Rj i: Si Rj Sj Sj i: Si+(Sj-Rj) Ri When j s report arrives at i, distance from j is calculated as: fjmlz SRM 14

15 Linear Topology Repair Chronology Time -2 S R1 R2 R3 R4 snd 1,2-1 rcv 1,2 0 rcv 2 1 rcv 2 2 snd 1? rcv 2 3 rcv 1? rcv 1? 4 rcv 1? snd 1 rcv 1? 5 rcv 1 rcv 1 6 rcv 1 fjmlz SRM 15

16 Worst case topology (star) and randomization R1 R8 R2 R7 S R3 R6 R4 R5 fjmlz SRM 16

17 Request and repair timers set to random number in intervals: Simplest SRM uses fixed values for constants: log members fjmlz SRM 17

18 Delay/RTT Number of Repairs Number of Requests Session Size Session Size Session Size (random trees; all nodes members) fjmlz SRM 18

19 Delay/RTT Number of Repairs Number of Requests Session Size Session Size Session Size (1000 node, bounded degree trees) fjmlz SRM 19

20 Random interval constants (weakly) sensitive to both topology and location of loss Can get better repair response, fewer duplicates, or both, if and dynamically adjusted: fjmlz SRM 20

21 (1000 node, bounded degree trees, adaptive algorithm) Session Size Delay/RTT Session Size Number of Repairs Session Size Number of Requests fjmlz SRM 21

22 Other SRM Applications Almost any large-scale data distribution BGP routes, DNS zone xfers, Usenet news, stock quotes, etc) Self-configuring cache hierarchies for, eg, Web or FTP data fjmlz SRM 22

23 Some Open Questions Local repair to avoid crying baby problem Other forms of bandwidth adaptation / congestion control fjmlz SRM 23