588 Section 6

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?