`
`the Internet Multicast Architecture
`
`Paul Francis
`
`ACIRI
`francis@aciri.org, www.aciri.org
`
`April 2, 2000
`
`Contents
`
`0.1 Abstract
`
`1 Changes
`
`2 Introduction
`2.1 Document Roadmap
`2.2 Motivation
`2.3 Yoid: An Alternative Architecture
`2.4 Yoid in a Nutshell
`2.5 Yoid Pros and Cons (Mostly Pros) .
`2.6 Back to the Architectural Foundation
`2.7 Related Work
`2.8 Simplicity (or Lack Thereof) ....
`
`3 Yoid Architecture
`3.1 Major Components
`3.2 Yoid Tree and Mesh Topologies
`3.3 Content Protocols
`3.4 Yoid Tree Management Protocol (YTMP)
`3.5 Parent Discovery and Selection in YTMP
`3.6 Security Architecture Overview
`3.7 API
`
`4 Odds and Ends
`4.1 Neighbor Aliveness
`4.2 Configuration with Yoid Proxy Servers
`
`1
`
`3
`
`4
`
`4
`4
`4
`6
`6
`7
`9
`10
`10
`
`12
`12
`13
`16
`20
`26
`30
`30
`
`32
`32
`33
`
`BUNGIE - EXHIBIT 1019
`
`
`
`4.3 Web Caching (and Hierarchically Nested Groups)
`4.4 Meta-Rendezvous Service (Another Nested Groups Application)
`4.5 Distributing Across a Lot of Time
`
`34
`38
`39
`
`2
`
`
`
`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 are 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 yoid, that aims to unify both tracks under a single umbrella
`architecture. Yoid 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 yoid 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
`distribution. Yoid can run over IP multicast, but does not require it. This allows application developers
`to bundle yoid into their applications, giving their applications robust and scalable configuration-free
`out-of-the-box multicast. This is key to the initial acceptance of yoid and for allowing it to reach critical
`mass.
`Yoid 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 yoid's ability to
`utilize local islands of IP multicast, allow yoid to support the broadest possible range of applications.
`
`3
`
`
`
`1 Changes
`
`April 2, 2000 Updated for name change from Yallcast to Yoid.
`
`2
`
`Introduction
`
`2.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 yoid, look
`at Subsection 2.4 ("Yoid in a Nutshell") and perhaps the subsection preceding it (2.3). For a deeper
`technical overview, see Subsections 3.1 and 3.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 (2, "Introduction"), tells you why we need
`better distribution, what yoid is, and why yoid provides better distribution.
`The second Section (3) takes you through yoid in increasing technical detail. Of particular interest
`might be Subsection 3.4 ("Yoid Tree Management Protocol (YTMP)"), and to some extent the following
`subsection, which describe how yoid tunneled topologies are dynamically configured—the only really
`novel thing about yoid.
`The last section outlines an assortment of enhancements that may be made to the basic architecture to
`increase yoid's capabilities or solve various problems endemic to yoid. 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 yoid itself are greatly appreciated.
`
`2.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
`
`4
`
`
`
`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
`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 are 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 are 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
`
`5
`
`
`
`problems of IP multicast, or because people don't like mucking with their router infrastructures, which
`today are 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
`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 are 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.
`
`2.3 Yoid: 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 yoid, for reasons that will be clear shortly.
`Simply put, yoid is a suite of protocols that allows all of the replication and forwarding required for
`distribution for a given application to be done in the endhosts that are running the application itself. In
`other words, yoid works in the case where the only replicators/forwarders (distributors) of content are
`the consumers of the content themselves. Let me be clear. Yoid does not force all distribution to be done
`by the content consumers—it can also be done by "servers" in the infrastructure. Nor does yoid prevent
`the use of IP multicast—it is used, but only where it exists and where its use is appropriate. With yoid,
`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 yoid.
`
`2.4 Yoid in a Nutshell
`
`Here is a very brief overview of the key technical components of yoid: The core of yoid is a topology
`management protocol, called YTMP, 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.
`
`6
`
`
`
`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
`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:
`
`yoid://rendezvous.host.name:port/group.name
`
`This gives you a basic picture of yoid, and is all I say about it for the time being. Later (sections 3 and 3.2
`and beyond) I'll introduce all the terms and acronyms and more detail (where the devil lies).
`
`2.5 Yoid Pros and Cons (Mostly Pros)
`
`In what follows, I present the advantages and disadvantages of yoid 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 yoid. 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 yoid 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 yoid 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 due to maintaining the forwarding information
`itself can be seen as just an incremental extra cost on the application. (Each yoid 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 yoid 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 yoid 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 yoid servers require forwarding information
`on a par with what "local" routers (as opposed to routers in the backbones) must carry.
`Name/Address Assignment
`
`7
`
`
`
`Yoid does not have IP multicast's address assignment problems because any host with a domain name
`can locally create any number of globally unique yoid group names. (Hosts without a domain name 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 yoid 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 yoid 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)
`Yoid 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 yoid 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 yoid. 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 yoid servers not IP routers).
`Personally I think there will always be a good use for pure endhost-based yoid. 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 kbps 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
`Yoid does not have the congestion control problems that IP multicast has. Because each (tunneled) link
`in a yoid tree-mesh is a (unicast) TCP connection or RTP stream, yoid uses the normal congestion control
`used over the internet today.
`Having said that, yoid 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 yoid
`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 yoid 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
`
`8
`
`
`
`routers or among hosts, depending on the scheme) over which acks or naks can be sent. Yoid of course
`builds a tree, but just happens to use it for sending content as well as sending acks.
`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 yoid approach over IP multicast is in its ability to do distri
`bution 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 yoid infrastruc
`ture. 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 yoid
`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 4.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 files 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.
`Yoid cannot easily substitute for this use of IP multicast. Yoid topologies are dynamically formed and
`can only come to resemble the physical topology rather slowly. Yoid can certainly be used as a means to
`discover a service—by having the hosts with the service join a well-known yoid group. Systems trying to
`discover the service, however, cannot quickly discover which of the hosts with the service is the closest.
`
`2.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
`
`9
`
`
`
`uses the wires efficiently. This is good, and is true because it runs in boxes that can (usually) run at wire
`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 yoid 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.
`
`2.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 are 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 3.4). They recognize most of the broader issues,
`such as naming, and have independently conceived many of the ideas in yoid (such as the rendezvous),
`though they haven't done much work on these broader issues per se.
`More recently, the Reliable Multicast Research Group (RMRG) of the IRTF 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.
`
`2.8 Simplicity (or Lack Thereof)
`
`All other things being equal we all long for simple architectures and protocols. Yoid 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 yoid 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
`
`10
`
`
`
`hoc or proprietary server-based distribution technologies could also be replaced by yoid, making IT's life
`simpler. So while yoid may not be simple, it may very well be simpler than the alternatives.
`
`11
`
`
`
`3 Yoid Architecture
`
`The key attribute of yoid, 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.
`
`3.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:
`
`yoid://rendezvous.name:port/groupName
`
`The group ID has this form for two primary reasons. First, it allows any host with its own domain name
`to independently create (globally unique) identifiers for any number of trees. In other words, identifier
`creation is simple and scalable. Second, it allows discovery of the rendezvous host(s).
`The primary purpose of