1 / 17

Yallcast Architecture Overview

Yallcast aims to unify IP multicast and simple distribution in a single architecture for efficient content delivery. This overview discusses the goals, status, and next steps of the Yallcast project.

elizabethfrancis
Download Presentation

Yallcast Architecture Overview

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. Yallcast Architecture Overview Paul Francis NTT PF Labs francis@slab.ntt.co.jp www.yallcast.com

  2. “Distribution” Today:Two Parallel Tracks • IP Multicast • Simple, automatic, standardized • Has problems, hasn’t reached “critical mass” • Server-based • Broad functionality, almost everything server-based today • Application-specific, ad hoc, no standards, management-intensive

  3. Yallcast Goal:Unify Both Tracks • “Host”-based distribution tree • Tunneled over IP unicast (and multicast) • Buffering in hosts (or not) • DNS name-based group addressing • Dynamically self-configuring topologies

  4. Status of Yallcast • Basic algorithms worked out • Especially dynamic tree configuration • Experimental implementation • Jan. 00 release target • Many many open issues • This talk is a call for participation • Certainly not a call for standardization

  5. Yallcast Architecture Overview • Rendezvous Nodes: • Bootstrap members into tree-mesh • Member Nodes: • Dynamically configure into tree-mesh • Send, receive, and forward frames • Group ID: • rendezvousName, treeName, [udpPort]

  6. Yallcast Topologies Tree Link (Tunneled) Member (host with buffer) Cluster (IP mcast) Mesh Link

  7. Yallcast Topologies • Dynamically configured Tree and Mesh • Both can carry content frames • Tree Topology • Optimized for efficiency, but fragile • Mesh Topology • Optimized for robustness, but inefficient

  8. IP Multicast: Yallcast “Cluster” • Group ID hashed into IP multicast addr • IP Multicast tightly scoped • Currently to 1 hop • Admin scoping may be possible • Cluster head member dynamically elected • Joins rest of tree-mesh • Other members send/receive via IP multicast

  9. Reduced Role of IP Multicast • IP Multicast always runs under yallcast • IP Multicast no longer expected to have global scope

  10. Yallcast Content Protocol Stack Application API Yallcast Tree Protocol (YTP) (framing, forwarding, sequencing) yTCP yRTP yRMTP Etc... Yallcast ID Protocol (YIDP) UDP TCP IP Multicast IP Unicast

  11. Member Identification • Based only on: • Member domain name • Yallcast port (32-bit locally unique number) • Not based on IP or UDP/TCP port • Member “how to reach” information carried separately • IP addresses (including NAT box), ports, etc.

  12. Yallcast Content Protocols • Application frame-based • Per-source 64-bit byte sequencing • Frame can be forwarded over tree or mesh • Tag-based headers (hop by hop) • Frame source id --> 16-bit tag • HxH source id, HxH dest id, group id --> 64-bit tag

  13. Comparison to IP Multicast • Routing table scalability • Group ID (address) assignment • End-to-end Reliability • Congestion Control • Proximity discovery • Delivery efficiency (for non-reliable)

  14. Trickier Comparisons • Evolutionary Path • Don’t need any infrastructure in advance • Just bundle with app • Add infrastructure as needed • Buffering • Hosts have lots of buffer---async distribution • But introduces new coordination problems

  15. Rendezvous Node’s Algorithm • rendezvousName, treeName, [udpPort] • Listen on udpPort • Keep list of (some or all) group members • Tell new members of existing members, group parameters (buffer size, security, etc.) • Partition detection (detect multiple roots) • Convenient place for other services.

  16. Member Node’s Algorithm • Check local IP multicast for other members • If exist, join local cluster • May optionally contact Rendezvous • If none, contact Rendezvous • Learn of existing members • Run Yallcast Tree Management Protocol (YTMP) with existing members

  17. Yallcast Project Next Steps • Build real applications over yallcast • Develop yallcast under real applications • Work towards open-source environment • Early standardization neither necessary nor appropriate • Standardize when ready for OS and proxy-server deployment

More Related