1 / 18

588 Section 6

588 Section 6. Neil Spring May 11, 1999. Schedule. Notes (1 slide) Multicast review (3slides) RLM (the paper you didn’t read) (3 slides) ALF & SRM (8 slides). Reminders & Notes. Programming Assignment 2 due May 24 Homework 3 will be due June 1 Project 3 will be due June 7

alesia
Download Presentation

588 Section 6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related