`
`Paul Francis
`NTT PF Labs
`francis@slab.ntt.co.jp
`www.yallcast.com
`
`0001
`
`BUNGIE - EXHIBIT 1015
`
`
`
`“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
`
`0002
`
`
`
`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
`
`0003
`
`
`
`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
`
`0004
`
`
`
`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]
`
`0005
`
`
`
`Yallcast Topologies
`
`Member
`(host with
`buffer)
`
`Mesh
`Link
`
`Tree Link
`(Tunneled)
`
`Cluster
`(IP mcast)
`
`0006
`
`
`
`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
`
`0007
`
`
`
`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
`
`0008
`
`
`
`Reduced Role of IP Multicast
`
`• IP Multicast always runs under yallcast
`• IP Multicast no longer expected to have
`global scope
`
`0009
`
`
`
`Yallcast
`Content
`Protocol
`Stack
`
`Application
`
`API
`
`Yallcast Tree Protocol (YTP)
`(framing, forwarding, sequencing)
`
`yTCP
`
`yRTP
`
`yRMTP
`
`Etc...
`
`Yallcast ID Protocol (YIDP)
`
`UDP
`IP
`Multicast
`
`TCP
`IP
`Unicast
`
`0010
`
`
`
`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.
`
`0011
`
`
`
`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
`
`0012
`
`
`
`Comparison to IP Multicast
`
` Routing table scalability
` Group ID (address) assignment
` End-to-end Reliability
` Congestion Control
`
` Proximity discovery
` Delivery efficiency (for non-reliable)
`
`0013
`
`
`
`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
`
`0014
`
`
`
`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.
`
`0015
`
`
`
`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
`
`0016
`
`
`
`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
`
`0017
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
