1. 588 Section 6 Neil Spring May 11, 1999

2. Schedule Notes – (1 slide) Multicast review –(3slides) RLM (the paper you didn’t read) –(3 slides) ALF & SRM –(8 slides)

3. Reminders & Notes Programming Assignment 2 due May 24 Homework 3 will be due June 1 Project 3 will be due June 7 Final Project too! Project 1 seems to have gone well Thanks for your help with the images

4. Multicast Summary (Review) What? –Queries to anyone who is listening –Updates to shared state Why? –Economic use of resources –Scale Scope control Plenty of ways to generate distribution trees

5. Multicast Trees (Review) Reverse Path Flooding –find a good tree Reverse Path Broadcasting –avoid duplicates on a wire by electing a parent Truncated RPB –prune uninterested leaves Reverse Path Multicasting –prune on demand

6. Multicast Challenges (Review) Differences in receiver bandwidth Reliability –redundant transmission –retransmission Ordering/consistency of multiple senders

7. Multicast Challenge: Heterogeneity We all want to watch the rolling stones on our computers. Our world includes links speeds that differ by 3 orders of magnitude (at least!) –modems, isdn –lans, cable modems –wireless links One broadcast does not fit all!

8. Response: Simulcast 28.8 modems get this stream. Direct network links get another. Problems?

9. Response: RLM Receiver-driven Layered Multicast Send a bunch of streams of increasing detail –base layer: includes the most important stuff, small –additional layers: add detail, may be large Receivers dynamically decide how many layers to subscribe to. Loss implies congestion implies over- subscription.

10. RLM: How many layers? Startup: –get the first one, wait a few seconds –ask for the next one, wait a few seconds, –repeat until drop (skipped sequence number) –go back to the previous layer With exponentially increasing timer: –Try the next layer maybe there’s new bandwidth or less congestion maybe the drop wasn’t your fault.

11. Multicast Challenge: Reliability The SRM paper is one approach (little later) Redundant transmission is another –messages may be small so redundancy is cheap –explicit: here are the previous 6 commands again –implicit: redundancy in video or audio streams real audio has some (doesn’t rely on it exclusively) Or you just tolerate missing a frame

12. Why is reliability hard? Can’t keep state about all receivers and still scale Can’t reason about RTT/cwnd No fate sharing

13. What is ALF Application Level Framing Someone explained it to me as ‘it’s just UDP’. Application defines an atomic unit –roughly like a packet –approaches a record, block, file, frame, etc Application deals with ordering –may accept out of order packets (real audio)

14. Response: SRM All interaction is multicast Receivers learn they’re missing something when: –hole in sequence space –receive a report from someone else about a newer packet Receivers missing data ask everyone for it Imagine a student asking for a copy of the handout Anyone can reply

15. SRM Retransmit Requests Avoid too many retransmit requests: –deterministic suppression: nodes farther away see our request and don’t make one of their own –probabilistic suppression: nodes equally far have a random timer, not all will fire before they see our request. Is there a better solution for containing retransmissions and retransmission requests?

16. SRM Retransmit Containment Administrative Scoping (I don’t know) Separate Groups –for local receivers that could help out –possibly separate channels for each missed packet (can a host subscribe that fast?) TTL Scope Control –how to reach those who also want a retransmit?

17. SRM TTL-based Scope Hacks Reply with TTL*2 –? Request from the requestor with TTL –?

18. SRM Requirements How many packets do you hold on to? How do you order updates? –Eg. Whose writing goes on top? –Thomas’ write rule?