Yallcast: Extending the Internet Multicast Architecture
`
`Paul Francis
`
`NTT Information Sharing Platform Laboratories
`francislab.ntt.co.jp
`
`September 30, 1999
`
`Contents
`
`1 Introduction
`1.1 Document Roadmap
`1.2 Motivation
`1.3 Yallcast: An Alternative Architecture
`1.4 Yallcast in a Nutshell
`1.5 Yallcast Pros and Cons (Mostly Pros)
`1.6 Back to the Architectural Foundation
`1.7 Related Work
`1.8 Simplicity (or Lack Thereof)
`
`2 Yallcast Architecture
`2.1 Major Components
`2.2 Yallcast Tree and Mesh Topologies
`2.3 Content Protocols
`2.4 Yallcast Tree Management Protocol (YIMP)
`2.5 Parent Discovery and Selection in YTMP
`2.6 Security Architecture Overview
`2.7 API
`
`3 Odds and Ends
`3.1 Neighbor Aliveness
`3.2 Configuration with Yallcast Proxy Servers
`3.3 Web Caching (and Hierarchically Nested Groups)
`3.4 Meta-Rendezvous Service (Another Nested Groups Application)
`3.5 Distributing Across a Lot of Time
`
`1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`3
`3
`3
`5
`5
`6
`8
`9
`9
`
`11
`11
`12
`15
`19
`25
`29
`29
`
`31
`31
`32
` 33
`37
` 38
`
`BUNGIE - EXHIBIT 1005
`
`

`

`0.1 Abstract
`
`If we take a broad view of the term "multicast" to mean any distribution of content to more than one
`machine, we find that multicast is proceeding along two distinct architectural tracks. On one track is
`IP multicast, which mainly targets realtime non-reliable applications, but for which hopes run high for
`reliable applications as well. On the other are a plethora of open or proprietary host- or server-based
`approaches, each typically targeting a specific application or product line.
`
`IP multicast suffers from a number of technical problems, lacks applications, and in general is having
`trouble reaching critical mass, especially regarding anything resembling a global infrastructure. Server-
`based approaches arc valuable and wide-spread, but there is no synergy in terms of multiple distinct
`groups working within the same architecture. As a result, progress is not as fast as it could be, and
`consumers are strapped with multiple application-specific infrastructures to deal with.
`
`This paper presents an architecture, called yallcast, that aims to unify both tracks under a single umbrella
`architecture. Yallcast attempts to take the best from both tracks
`reliable and asynchronous distribution
`from the server-based track, and dynamic auto-configuration via a simple API from the IP multicast track.
`
`A key component of yallcast is that it allows a group of endhosts (the hosts where the content-consuming
`application resides) to auto-configure themselves into a tunneled topology for the purpose of content dis-
`tribution. Yallcast can run over IP multicast, but does not require it. This allows application developers
`to bundle yallcast into their applications, giving their applications robust and scalable configuration-free
`out-of-the-box multicast. This is key to the initial acceptance of yallcast and for allowing it to reach
`critical mass.
`
`Yallcast is not limited, however, to endhost-based distribution. It can also work in infrastructure servers
`(boxes that receive, replicate, and forward content but that are not consumers of the content). This
`allows improved performance for applications that require it. It can also provide other benefits such as
`better security. The endhost- and server-based modes of operation taken together, along with yallcast's
`ability to utilize local islands of IP multicast, allow yallcast to support the broadest possible range of
`applications.
`
`2
`
`

`

`1 Introduction
`
`1.1 Document Roadmap
`
`Lest the reader be immediately put off by the size of this document, I offer the following brief roadmap:
`
`If, having read the abstract, you want to go straight to a very brief technical overview of yallcast, look
`at Subsection 1.4 ("Yallcast in a Nutshell") and perhaps the subsection preceding it (1.3). For a deeper
`technical overview, see Subsections 2.1 and 2.2.
`
`Otherwise, this paper pretty much proceeds in increasing detail, and you can just start at the beginning
`and continue until you've read enough. The first Section (1, "Introduction"), tells you why we need
`better distribution, what yallcast is, and why yallcast provides better distribution.
`
`The second Section (2) takes you through yallcast in increasing technical detail. Of particular interest
`might be Subsection 2.4 ("Yallcast Tree Management Protocol (YIMP)" ), and to some extent the fol-
`lowing subsection, which describe how yallcast tunneled topologies arc dynamically configured
`the only
`really novel thing about yallcast.
`
`The last section outlines an assortment of enhancements that may be made to the basic architecture to
`increase yallcast's capabilities or solve various problems endemic to yallcast. This section can easily be
`skipped by all but the most interested readers.
`
`This document is in an early draft stage. It is still missing references, and has not gone through any peer
`review. Any references or comments on the document or yallcast itself are greatly appreciated.
`
`1.2 Motivation
`
`Let's take a broad view of the term "multicast" and take it to mean every instance where content is
`moved from one machine to more than one other machine. For lack of a better term, and to avoid long
`and clumsy phrases, let's refer to this broad view multicast as simply distribution.
`
`Viewed this way, the majority of what gets transmitted over the internet is distribution: mail, news, web
`pages (HTML) and files of all types (jpg, mp3, etc.), chat, channels, DNS records, audio-video broadcasts,
`and so on. While strictly 2-party exchanges are obviously important, it is not an exaggeration to say
`that the internet is what it is because of its distribution functionality.
`
`In spite of this, virtually every distribution application in the internet today runs over the unicast in-
`frastructure and derives its distribution functionality from mechanisms internal to and specific to the
`application itself. For instance, RFC822 mail headers have mechanisms for detecting loops among mail
`forwarders, NNTP has the NEWNEWS command to manage flooding of news articles, HTTP has redi-
`rection and mechanisms for handling caches, and so on. Practically speaking, though, there is no general
`"infrastructure" support for distribution in existence today. The exception that proves this rule is IP
`multicast, globally available tunneled in the form of the mbone, and privately available as either tunneled
`or native IP multicast.
`
`The reason this exception proves the rule is that IP multicast has so far not lived up to early expectations,
`to say the least. And this in spite of the fact that it is now available on most host operating systems
`and in most routers (though it is usually not "turned on"). Different people have different ideas on why
`IP multicast has not taken off, ranging from a lack of tools for managing IP multicast installations to
`insufficient protocol development to a lack of IP multicast-ready applications (all examples of reasons
`voiced by participants in the IETF maddogs ad hoc group). Many people, myself included, have labored
`under the tacit assumption that if we could only fix this or that problem, and add this or that functionality,
`then IP multicast would reach some sort of critical mass and take off, in the same sense that HTTP/HTML
`at some point reached a critical mass and took off. It would then serve as the infrastructure foundation
`
`3
`
`

`

`upon which various kinds of distribution applications would be built.
`
`I no longer believe this is a realistic possibility. IP multicast, in its role as "the architectural foundation
`for internet distribution", suffers from one fundamental problem, one major problem, and a lot of nagging
`problems.
`
`The fundamental problem is that IP multicast works only across space, not across time, whereas most
`distribution on the internet (almost everything mentioned above), works across both space and time.
`What I mean by this is that the recipients of most types of distribution content (mail, web pages, etc.)
`want to receive it at different times. Even content that under ideal conditions would reach all recipients
`immediately (i.e., "push" content like mail) can't because not all recipients arc ready to receive all the
`time (mainly because they are not connected to the internet all the time). IP multicast, on the other
`hand, requires that all recipients receive the content at the same time. (I understand that there is a way
`around this, namely multicasting the content multiple times until all recipients have got it. But this is
`not a very attractive thing to have to do, and rather proves my point.)
`
`The major problem referred to above is that IP multicast addresses arc too small. Basing the global
`architectural foundation for distribution on a 27-bit address space is, frankly. silly. It may very well
`be that some of the current initiatives for IP multicast address assignment will satisfactorily solve the
`problem (I did say this was only a major problem, not a fundamental problem), but it really is bending
`over backwards unnecessarily. And of course there is IPv6, but I wouldn't want to assume that that will
`become ubiquitous any time soon.
`
`The nagging problems include:
`
`• Large IP multicast routing tables.
`
`• Congestion control over IP multicast.
`
`• Reliable data transport over IP multicast.
`
`• Good access control and security mechanisms.
`
`I want to repeat that all of the above discussion of IP multicast is in its role as "the architectural
`foundation for internet distribution." To be fair, I understand that its not like some person or group ever
`sat down and, working from a clean whiteboard, analyzed all the options and decided that IP multicast,
`with its 27 bit address space and space-only distribution mechanism, was the best choice for all internet
`distribution. Rather, we've incrementally backed ourselves into this corner via some set of historical
`decisions, or non-decisions, that have long since been overtaken by events.
`
`IP multicast is ideal for applications that cannot tolerate (much) delay, can tolerate some loss, and
`have throughput that is relatively high but upper-bounded. This mainly includes interactive things like
`audio-video conferencing and internet games. A host- or server-based approach works poorly or not at
`all for these applications. On the other end of the spectrum, a host- or server-based approach is great for
`applications that can tolerate significant delay (minutes or hours) and cannot tolerate loss. This includes
`things like mail and file distribution. IP multicast works poorly or not at all for these applications. For
`stuff in between (chat, distributed whiteboard, audio-video one-way broadcast), both can suffice, and
`reasonable people could agree to disagree on which is better.
`
`For this stuff in between, however, it just turns out that the path of least resistance for obtaining
`distribution funtionality is the server-based approach. This may be in part because of the technical
`problems of IP multicast, or because people don't like mucking with their router infrastructures, which
`today arc mission-critical resources. I think probably the primary reason, though, is that for the server-
`based approach, the application provider needs to convince the application user to deploy only the
`application itself. For the IP-multicast based approach, the application provider needs to convince the
`application user to both deploy the application and deploy IP multicast (or, more often, convince yet
`
`4
`
`

`

`somebody else to deploy IP multicast). The latter is a far more difficult proposition. Whatever the
`reasons, for almost any application where a host- or server-based approach will suffice, even if IP multicast
`would ultimately be a better approach, the server-based approach will be used.
`
`As a result, we now live in a world where there arc dozens of application-specific ad hoc and propri-
`etary server-based systems for doing distribution. In addition to open standards like NNTP, IRC, ICP,
`RFC822 mail headers, and so on, many companies offer proprietary server-based systems: Pointcast for
`its channels, Tivoli for its software distribution, Tibco for its publish/subscribe stuff, RealNetworks for
`its audio-video broadcasts, and on and on. This state of affairs cries out for a standard approach that
`that can handle all of the above sorts of distribution and more.
`
`1.3 Yallcast: An Alternative Architecture
`
`What is really needed is a general architecture for all internet distribution. This architecture should have
`mechanisms for both space-based and time-based multicast. It should be able to seamlessly incorporate
`multicast media (LANs, satellite) and IP multicast where they exist and where their use is appropriate.
`It should have an easy evolutionary path, by which I mainly mean that it shouldn't require changes to
`existing infrastructure, including host operating systems. It should have a fully scalable naming scheme.
`And it shouldn't suffer from any of the nagging problems of IP multicast.
`
`This paper presents an architecture that holds promise as the general architecture for all internet distri-
`bution. I call it yallcast, for reasons that will be clear shortly.
`
`Simply put, yallcast is a suite of protocols that allows all of the replication and forwarding required for
`distribution for a given application to be clone in the endhosts that are running the application itself. In
`other words, yallcast works in the case where the only replicators/forwarders (distributors) of content arc
`the consumers of the content themselves. Let me be clear. Yallcast does not force all distribution to be
`clone by the content consumers
`it can also be clone by "servers" in the infrastructure. Nor does yallcast
`prevent the use of IP multicast
`it is used, but only where it exists and where its use is appropriate.
`With yallcast, neither infrastructure servers nor IP multicast are necessary for distribution, but they
`can be brought to bear where economics or application requirements make them appropriate. When IP
`multicast is used, it will generally be confined to local networks. Islands of locally scoped IP multicast
`groups will be connected by global yallcast.
`
`1.4 Yallcast in a Nutshell
`
`Here is a very brief overview of the key technical components of yallcast: The core of yallcast is a topology
`management protocol, called )(IMP, that allows a group of hosts to dynamically auto-configure into two
`topologies:
`
`• a (tunneled) shared tree topology for efficient multicast distribution of application content, and
`
`• a (tunneled) mesh topology, for robust broadcast distribution of various information, including
`control information and, where appropriate, application content.
`
`The tunnels can be either two-party (using UDP or TCP), or N-party (using very tightly scoped IP
`multicast). Each host can join or leave the two topologies (jointly called the tree-mesh) independently,
`making the group itself dynamic.
`
`Each group has one or more rendezvous hosts associated with it. Rendezvous hosts are not attached
`to the tree-mesh
`rather, they serve as a discovery or bootstrap mechanism for allowing hosts joining a
`group to find other hosts already in the tree-mesh. Group members contact a rendezvous host when they
`first join and when they finally quit the group (where possible). The rendezvous host maintains a list of
`
`5
`
`

`

`some or all group members, and informs joining hosts of a number of these. The hosts then participate
`in the topology management algorithm with these already attached hosts to attach to the group.
`
`The name of a given group consists of three components:
`
`• the name of the rendezvous hosts (if multiple, they have the same name),
`
`• the UDP ports the rendezvous hosts are listening on (optional, if not the default port number)
`
`• the name of the group, which is unique to the rendezvous host.
`
`This naming scheme both 1) allows any host (with a domain name) to locally create a globally unique
`group name, and 2) allows for discovery of the rendezvous host. The group name can be encoded as a
`URL, and for all practical purposes is a URL:
`
`yallcast://rendezvous.host.name:port/group.name
`
`This gives you a basic picture of yallcast, and is all I say about it for the time being. Later (sec-
`tions 2 and 2.2 and beyond) I'll introduce all the terms and acronyms and more detail (where the devil
`lies).
`
`1.5 Yallcast Pros and Cons (Mostly Pros)
`
`In what follows, I present the advantages and disadvantages of yallcast versus IP multicast in the context
`of the larger goal of internet distribution. These arguments are clearly not meant to convince, given
`that they are based on an overly simple description of yallcast. Rather, they simply highlight the main
`features. It will take extensive experimentation to see if the advantages presented here really pan out.
`
`Forwarding Table Size
`
`I first conceived yallcast solely in response to the problem of large forwarding tables in IP multicast
`routers. My thought was that, for many kinds of distribution, especially smallish groups with relatively
`low volume, there is no particular reason that IP multicast must be used
`the group member hosts
`themselves could manage replication and forwarding just fine. This offloads the job from routers, saving
`them for higher volume multicast applications where their higher speeds and more optimal topologies are
`needed.
`
`In the case where yallcast forwarding is taking place in endhosts, there is no forwarding table size problem
`because the endhost has only to carry topology information for the groups it has joined. Since the host is
`also running an application for each group, the overhead clue to maintaining the forwarding information
`itself can be seen as just an incremental extra cost on the application. (Each yallcast host only needs to
`know about its neighbors in the tree-mesh and a small handful of other hosts in the group, independent
`of the size of the group.)
`
`In the case where yallcast forwarding is taking place in infrastructure server boxes, each server must carry
`only topology information for those group members among the nearby hosts it serves. Unlike the case
`with IP multicast, each yallcast topology is created from scratch and requires no servers in the "middle"
`of the topology to connect servers at the "edges". The "edge" servers connect directly with other "edge"
`servers through tunnels. (In IP multicast the routes are dynamic, but the underlying topology, even in
`the case of the tunneled mbone, is not.) In other words, all yallcast servers require forwarding information
`on a par with what "local" routers (as opposed to routers in the backbones) must carry.
`
`Name/Address Assignment
`
`Yallcast does not have IP multicast's address assignment problems because any host with a domain name
`can locally create any number of globally unique yallcast group names. (Hosts without a domain name
`
`6
`
`

`

`will be able to use a meta-rendezvous service provided by hosts that do have a domain name, but this is
`getting ahead of the story.) In addition, with yallcast running "above" IP multicast, address assignment
`in IP multicast is simplified because IP multicast will generally be limited to local areas where address
`assignment is much easier.
`
`Of course the cost of this is each yallcast group's dependence on one or a small number of rendezvous
`hosts. Practically speaking, I don't think this is much of a problem. One can replicate the rendezvous
`host for reliability, and the rendezvous host is neither involved in the topology building algorithm per
`se nor is attached to the tree-mesh, so its per-group-member overhead is low. Also, there are practical
`advantages to having a central point of contact accounting, distribution of security information, access
`control, and so on.
`Evolutionary Path (or, the Chicken-and-Egg Problem)
`Yallcast does not have the application/infrastructure chicken-and-egg problem of IP multicast. This is
`the problem where nobody (hardly) wants to write applications for IP multicast because there is no
`infrastructure, and nobody (hardly) wants to put in the infrastructure because no users have applications
`that demand it. Because yallcast can run purely in the hosts running the application, and in fact can be
`wholy bundled with each application no OS changes
`the application developer can build a distribution
`application with little concern about the users' network environments or OS capabilities.
`
`This allows for a natural evolution of a distribution infrastructure. Applications start with pure endhost-
`based yallcast. Naturally applications will push the limits of endhost forwarding performance, creating a
`demand for infrastructure boxes. These boxes, however, can be installed one at a time on an as-needed
`basis (in the same way that web caches can be added one at a time), making their deployment relatively
`easy. The infrastructure boxes boost performance, applications respond by demanding even more, and
`the ensuing demand/supply arms race results in the desired end-goal a "distribution infrastructure box"
`on every wire (even if those boxes turn out to be yallcast servers not IP routers).
`
`Personally I think there will always be a good use for pure endhost-based yallcast. If we assume a tree
`with a small fan-out (I generally assume a fan-out of 2), then even a tree consisting only of 56kbps dialup
`hosts can generate useful throughput. For instance, say we can get 20 khps throughput (20kbps in and
`40kbps out to two neighbors), which seems reasonable. This is enough for a reasonable quality audio
`presentation with graphics in real time or low-end internet radio.
`
`But even if the end-host only mode of operation serves no other purpose than bootstrapping a distribution
`infrastructure, it will have been as critical to the infrastructure as a first-stage booster rocket is to a
`satellite.
`Congestion Control
`Yallcast does not have the congestion control problems that IP multicast has. Because each (tunneled)
`link in a yallcast tree-mesh is a (unicast) TCP connection or RTP stream, yallcast uses the normal
`congestion control used over the internet today.
`
`Having said that, yallcast does have the characteristic that potentially very large numbers of hosts could
`be transmitting large volumes over the internet at roughly the same time. While the intent is for yallcast
`topology tunnels to normally link hosts near each other thereby avoiding multiple tunnels passing through
`the same routers, this will not be perfect, especially early on before we've gained much experience. As a
`result, sudden internet-wide bursts of traffic could result in unexpected bad consequences.
`End-to-End Reliability
`
`Getting end-to-end reliability out of a host-based infrastructure is far easier than getting it out of IP
`multicast. Since IP packet loss is recovered by TCP at each hop, a yallcast tree has no ack implosion
`problem. In fact, a key objective of most reliable transport protocols for IP multicast is to build a tree
`(among routers or among hosts, depending on the scheme) over which acks or naks can be sent. Yallcast
`of course builds a tree, but just happens to use it for sending content as well as sending acks.
`
`7
`
`

`

`This is not to say that getting end-to-end reliability automatically falls out of using TCP hop by hop.
`Packets can still be lost: because of buffer overflow at hosts, and because of data loss during topology
`changes. Recovering these loses, though, is relatively straightforward. It requires an end to end sequencing
`protocol to identify loses, push-back flow control at each hop to avoid buffer overflow, and buffering in
`each host to recover topology change-induced losses locally.
`
`The Benefits of Buffering: Across-time Distribution
`
`Perhaps the most important advantage of the yallcast approach over IP multicast is in its ability to
`do distribution across time, not just across space. This allows it to accommodate a large number of
`distribution applications that IP multicast cannot handle and was never meant to handle.
`
`It is easy to visualize how across-time distribution works in the case of a server-based yallcast infras-
`tructure. This is no different from the numerous server-based across-time distribution infrastructures we
`already have (mail forwarder infrastructures, netnews infrastructures, caching infrastructures, Pointcast
`infrastructures, and so on).
`
`It is much more difficult to visualize how across-time distribution works in the case of endhost-based
`yallcast distribution, especially for hosts that are not administratively related. Such a host would, for
`instance, join a tree-mesh and start receiving a file. (It is easiest to think of across-time distribution in the
`context of file distribution, understanding that a file can be anything from a mail message to a software
`executable, since file distribution has relatively relaxed timing constraints.) At some time, the host is
`expected to forward the file to one or two other hosts (to garner the benefits of "multicast" distribution).
`Those other hosts may connect to the sending host long after it has received the file. Therefore, speaking
`generally, any host may be expected to stay on the tree-mesh long enough to pass the file on to other
`hosts, even if this means staying on the tree-mesh long after the file has been fully received. It could
`even mean leaving the tree-mesh when the host disconnects from the internet, and rejoining when the
`host later reconnects, solely for the purpose of passing the file on.
`
`I believe it can be done, to some extent, but I leave further description for later (see Section 3.5). Note
`in any event that integrity of the file in this context is not a particular problem. I assume as a matter
`of course that the distributed tiles have signatures associated with them, and that these signatures are
`obtained from the (trusted, more-or-less) rendezvous host at first contact.
`
`Discovery of Nearby Services
`
`One of the oft-cited uses of IP multicast is to discover nearby (In the context of physical topology) hosts
`containing specific services. The idea here is that the IP multicast topology closely resembles the physical
`topology, and therefore a host that is nearby in the IP multicast topology is also nearby in the unicast
`topology. This is certainly true for native IP multicast (where the multicast and unicast topologies are
`one and the same), but is also generally true for well-managed tunneled IP multicast. The mechanism
`for this discovery is an expanding ring search whereby the hop count, or possibly administrative scoping,
`is incrementally expanded until the service is discovered.
`
`Yallcast cannot easily substitute for this use of IP multicast. Yallcast topologies are dynamically formed
`and can only come to resemble the physical topology rather slowly. Yallcast can certainly be used as
`a means to discover a service by having the hosts with the service join a well-known yallcast group.
`Systems trying to discover the service, however, cannot quickly discover which of the hosts with the
`service is the closest.
`
`1.6 Back to the Architectural Foundation
`
`I'd like to now revisit the earlier comment about IP multicast being inappropriate as the "architectural
`foundation" for distribution in the internet. IP multicast, in its native (non-tunneled) mode, is fast and
`uses the wires efficiently. This is good, and is true because it runs in boxes that can (usually) run at wire
`
`8
`
`

`

`speeds, and that join multiple wires together (i.e., routers). IP multicast also has no buffering, and has
`a ridiculously small addressing space. This is bad, and is true because long ago it seemed (and probably
`was) appropriate to graft multicast functionality onto IP, which is a bufferless thing that today has not
`enough addresses.
`
`Even if someday we manage to go to IPv6. IP multicast will still be bufferless, and so still inappropriate
`for most kinds of distribution. A yallcast architecture, by which I mean one where 1) the distribution
`topology auto-configures and can be limited only to boxes that are consumers of the content, 2) addressing
`is domain-name based as described above, and 3) the links are always unicast IP tunnels, even if the
`nodes on either end share a wire, can have the advantages of IP multicast (fast boxes attached to and
`joining together multiple wires) without the limitations.
`
`1.7 Related Work
`
`Dissatisfaction with IP multicast's slow start seems to be growing, especially within the commercial
`sector. Recently the IETF chartered an ad hoc group, called maddogs, to explore ways to overcome the
`problems of IP multicast and to make it more suitable for commercial products and services.
`
`In spite of this, however, many people seem still to accept the assumption that IP multicast should be
`the foundation for internet distribution. In support of this statement is the fact that, in addition to the
`substantial inter-domain multicast IP protocol work going on, there are research and working groups for
`reliable multicast transport.
`
`There arc a couple of exceptions. Researchers at Telcordia and the University of Maryland, based on a
`suggestion by Christian Huitema, have independently proposed the idea of host-based multicast. They
`developed a protocol for use in the ad hoc mobile network environment. The protocol is called AMRoute,
`and has been published as an internet draft in the Manet working group of IETF. This specific document
`targets IP multicast functionality only (by which I mean it is works across space only), and for mobile
`ad hoc networks only. The internet draft does, however, mention in passing that the approach may
`have broader functionality in the larger internet. As far as I know, however, no substantial work in this
`direction has been done.
`
`Hui Zhang at Carnegie Mellon has also independently been working on host-based multicast (which he
`calls endsystem-only multicast). He and his students have worked out some basic low-level tree-formation
`mechanisms and have done some simulations (see Section 2.4). They recognize most of the broader issues,
`such as naming, and have independently conceived many of the ideas in yallcast (such as the rendezvous),
`though they haven't done much work on these broader issues per se.
`
`More recently, the Reliable Multicast Research Group (R.MR.G) of the HUE has started a work item on
`what it so far calls Auto 'Tree Configuration. Among the goals of that effort is to create an algorithm that
`can build a tree strictly among the recipient hosts of a multicast group. As near as I can tell, however,
`the purpose of that tree is not to distribute content per se, which is still expected to be transmitted via
`IP multicast. Rather, the tree is for transmitting acks/naks and optionally for local retransmissions of
`packets dropped by IP multicast.
`
`1.8 Simplicity (or Lack Thereof)
`
`All other things being equal we all long for simple architectures and protocols. Yallcast is not simple
`and I'm not going to pretend that it is. It constitutes a whole new layer in the architecture and comes
`with a number of new protocols. Nevertheless, I believe it can have a simplifying effect on the state
`of affairs in internet multicast and distribution overall. With yallcast in place, we could jettison all of
`the inter-domain aspects of IP multicast
`the routing protocols and the address assignment stuff. Many
`of the current ad hoc or proprietary server-based distribution technologies could also be replaced by
`
`9
`
`

`

`yallcast, making IT's life simpler. So while yallcast may not be simple, it may very well be simpler than
`the alternatives.
`
`10
`
`

`

`2 Yallcast Architecture
`
`The key attribute of yallcast, and indeed the only thing that makes it different from stuff already out
`there, is that it auto-configures tunneled shared-tree and mesh topologies among a group of hosts using
`ubiquitous internet protocols only (unicast IP and DNS). This is an extremely powerful tool. Virtually
`every form of distribution in the internet can be built upon this single capability.
`
`2.1 Major Components
`
`Each distribution group is comprised of two components:
`
`1. One or more 'rendezvous hosts
`
`2. group member hosts
`
`Each group has a globally unique identifier (the group ID) consisting of the following three components:
`
`1. Rendezvous Host Domain Name
`
`2. Rendezvous Host UDP Port (optional)
`
`3. Group Name
`
`The group ID can be encoded as a URL and has the same syntax restrictions as a URL:
`
`yallcast : //rendezvous