Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/104—Peer-to-peer [P2P] networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L45/00—Routing or path finding of packets in data switching networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L45/00—Routing or path finding of packets in data switching networks
  • H04L45/16—Multipoint routing
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/104—Peer-to-peer [P2P] networks
  • H04L67/1044—Group management mechanisms 
  • H04L67/1048—Departure or maintenance mechanisms
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/104—Peer-to-peer [P2P] networks
  • H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
  • H04L67/1065—Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT] 
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/104—Peer-to-peer [P2P] networks
  • H04L67/1044—Group management mechanisms 
  • H04L67/1046—Joining mechanisms
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

• the present disclosure relates to peer-to-peer overlay networks and, more particularly, to a method for parallelizing overlay operations in an overlay network.
• An overlay network is a network which is built on top of another network. Nodes in the overlay network can be thought of as being connected by logical links, each of which corresponds to a path in the underlying network. Many peer-to-peer networks are implemented as overlays networks running on top of the Internet. Traditionally, overlay networks have relied upon unicast messaging to communicate amongst the nodes.
• host group multicast has been proposed for overlay messaging operations. Briefly, host group multicast protocols create a group address, and each router stores state for each group address that is active. The state in the router grows as the number of simultaneous multicast groups. There is delay to create a group, and the network may have a limited number of group addresses.
• a peer node wants to use native host-group multicast to issue parallel queries to a set of nodes, it must first create the state in the routers and bring the receivers into the multicast. This setup adds delay and is only appropriate if the multicast path is going to be re-used for some time.
• the set of nodes is fairly dynamic and the set of requests between nodes is not predictable, so re-use of such multicast groups is limited.
• Host group multicast is designed for relatively small numbers of very large sets of recipients. So host group multicast is not a good choice for use in parallelizing network overlay operations where there are many simultaneous small groups of peers involved in a message. Therefore, there is a need for parallelizing overlay operations in an overlay network.
• a method for parallelizing overlay operations in an overlay network includes: identifying an overlay operation having a parallel messaging scheme; determining a destination address for each parallel message in the messaging scheme; encoding each destination address into a data packet; and transmitting the data packet over the overlay network using a multi- destination, multicast routing protocol.
• Figure 1 is a diagram of an exemplary network configuration having an overlay network
• Figure 2 is a flowchart illustrating an exemplary method for parallelizing overlay operations in an overlay network
• Figure 3 is a diagram of a portion of an overlay network
• Figures 4A-4B are diagrams illustrating how the used to describe the multi-destination, multicast routing protocolsegmentary
• Figure 5 is a diagram illustrating a node lookup in a Kademlia overlay network
• Figure 6 is a diagram illustrating an event detection and reporting algorithm
• Figure 7A and 7B are diagram illustrating a conventional scheme for traversing a multicast tree and a proposed messaging scheme which relies upon a multi-destination, multicast routing protocol, respectively.
• FIG. 1 is a diagram of an exemplary network configuration having an overlay network.
• the underlying network 10 is generally comprised of a plurality of network devices 12 interconnected by a plurality of network routing devices 14 (i.e., routers). The physical network links between these devices are indicated by the solid lines in the figure.
• An overlay network 20 is built on top of the underlying network 10.
• the overlay network 20 is a series of logical links defined between devices and indicated by the dotted lines in the figure.
• Exemplary overlay network architectures include Content Addressable Network (CAN), Chord, Tapestry, Freenet, Gnutella, and Fast Track. It is readily understood that this disclosure pertains to other types of overlay network architectures.
• FIG. 2 illustrates a method for parallelizing overlay operations in an overlay network.
• a suitable overlay operation is identified at 22.
• Exemplary overlay operations may include but are not limited to a node joining the overlay; a node leaving the overlay; routing table updates; a node forwarding routing tables or routing table excerpts to other nodes; a node exchanging node state and/or overlay measurements with another node; a node sending a request to several other nodes; and a node publishing an event to several subscriber nodes.
• Multi-destination, multicast routing is then used to transmit an applicable message over the overlay network.
• the source node determines a list of destinations for the message 24 and encodes each destination address 26 into the header of a single data packet.
• the destination addresses for such messages are typically known to the source node.
• node A is trying to send messages to nodes B, C and D.
• dest B C D I payload].
• the data packet is then sent 28 from the source node.
• Multicast-enabled routers along the transmission path will in turn forward the data packet on to its destinations.
• a multicast-enabled router Upon receiving the data packet, a multicast-enabled router processes the data packet as follows. For each destination address in the data packet, the router performs a route table lookup to determine the next hop. For each different next hop, the data packet is replicated and then the list of destinations is modified so that each data packet only contains the destination addresses which are to be routed through the next hop associated with the data packet. Lastly, the modified data packets are forwarded by the router to the applicable next hop(s).
• router R1 will forward a single data packet having a destination list of [B C D] to router R2.
• router R2 When router R2 receives the data packet, it will send one copy of the data packet to router R4 and one copy of the data packet to R5.
• the data packet sent to router R4 has a modified destination list of B.
• the data packet sent to router R5 will have a modified destination list of [C D].
• This data packet will be forwarded on by routers R5 and R6 until it reaches router R7.
• the data packet will again be partitioned into two data packets, each packet having destinations of C and D, respectively. It is readily understood that data packets having a single destination may be unicast along the remainder of their route.
• Explicit Multicast (Xcast) protocol is an exemplary multi- destination, multicast routing protocol. Further details regarding the Xcast protocol may be found in Explicit Multicast Basic Specification as published by the Internet Engineering Task Force and which is incorporated herein by reference. However, it is readily appreciated that other multi-destination, multicast routing protocols are within the scope of this disclosure. [0025] In one exemplary embodiment, the multi-destination, multicast routing protocol is implemented at an application level of the source node. In other words, the application performing the overlay operation identifies those operations having parallel messaging schemes and transmits the message(s) accordingly.
• each peer Pj has a queue Q which has pending messages to send.
• the messages in the queue may be unicast messages or multicast messages.
• the multicast messages may have been added directly by the overlay operations implemented in the peer or may have resulted from combining messages during prior processing of the contents of Q.
• the peer After adding a unicast message to Q, the peer examines Q and may combine a set u of unicast messages to create a multicast message ni k to group g k where rri k contains the contents of the unicast messages, pj e gk,
• +1 , and g k e Fj, where p j is a given peer and Fj is the set of all combinations of sets of peers in the overlay of size i 2, 3, ..., n.
• the peer may flush one or more messages from the queue, combine other unicast/multicast messages, and/or wait for further messages.
• the peer acts to maintain the maximum queuing delay of any message below a threshhold d q .
• Other criteria which prevents multicasting a message includes: has the packet reached a size limit on its payload; has the packet reached a size limit on its list of destination addresses; has the packet reach a processing limit related to time or peer resources needed to construct it, store it, receive it, and process it; has the packet reached a time delay related to how long the message can remain in the queue prior to being transmitted; or do the contents of the messages being combined into the multicast message completely overlap, partially overlap, or have no overlap (the more overlap, the more efficiency gain in using multicast). [0028] Assume peers agree on the rules for combining and extracting unicast messages to/from multicast messages.
• Multicast routing offers efficiency and concurrency to overlay designers. However it is necessary that: first, the scalability of the multicast algorithm for number of groups meets the scalability requirements of the overlay. If C is the capacity of the network to support simultaneous multicast group state for this overlay, then NG ⁇ C. Likewise, if v is the maximum group size, then
• This methodology assumes that the underlying network employs multicast-enabled routers. In many situations, this is a valid assumption. In other instances, only a subset of the routers in the underlying network is multicast- enabled. In these instances, the multicast-enabled routers use special tunnel connections to transmit data packets amongst themselves.
• the underlying network does not provide any ' multicast-enabled routers.
• special computers may be deployed nearby other routers in the underlying network. These computers would ' be configured to implement the routing protocol described above, thereby forming a logical multicast backbone.
• a source node wanting to send a multicast packet sends the packet to the nearest computer in the logical multicast backbone which in turn routes the packet over the logical multicast backbone to its destinations.
• Figure 4A shows the current state of the of an exemplary overlay network.
• a node 42 may join the network while another node 44 leaves the network as shown in Figure 4B. To do so, an incoming or departing node must communicate its change in status to the other nodes in the network. For instance, an incoming node may unicast request messages to multiple nodes in the network as shown in Figure 4C. Rather than sending multiple unicast messages, the incoming node may send a single packet using multi-destination, multicast routing as shown in Figure 4D. It is understood that different types of overlay networks employ different messaging schemes for communicating amongst nodes. Nonetheless, these types of overlay operations are particularly suited for parallelization in the manner described above.
• Kademlia is a multi-hop overlay that by virtue of its symmetric distance metric (the XOR function) is able to issue parallel requests for its routing table maintenance, lookups and puts.
• a peer computes the XOR distance to the node, looks in the corresponding k-bucket to select the ⁇ - closest nodes that it knows of already, and transmits parallel requests to these peers. Responses return closer nodes.
• Kademlia iteratively sends additional parallel requests to the ⁇ -closest nodes until it has received responses from the k- closest nodes it has seen.
• a typical value of ⁇ is 3.
• Figure 5 shows a node lookup for a node in the 110 k-bucket. For a 160-bit address space there will be up to 160 buckets.
• Node lookup is used by other Kademlia operations including DHT store, DHT refresh, and DHT lookup.
• Meridian is a measurement overlay in which relative distance from other nodes in the overlay is used for solving overlay lookups like closest node discovery and central leader election.
• Meridian uses a gossip protocol to propagate membership changes in the overlay. During a gossip period, a message is sent to a randomly selected node in each of its rings. The message contains one node randomly selected from each of its rings. Unicast gossip messages can be multicast in the manner described above to i * destinations using a single i * -way message.
• EpiChord peers maintain a full-routing table and approach 1- hop performance on DHT operations compared to the O(log N) hop performance of multi-hop overlays, at the cost of the increased routing table updates and storage.
• An EpiChord peer's routing table is initialized when the peer joins the overlay by getting copies of the successor and predecessor peers' routing table. Thereafter, the peer adds new entries when a request comes from a peer not in the routing table, and removes entries which are considered dead. If the churn rate is sufficiently high compared to the rate at which lookups add new entries to the routing table, the peer sends probe messages to segments of the address space called slices. Slices are organized in exponentially increasing size as the address range moves away from the current peer's position. This leads to a concentration of routing table entries around the peer, which improves convergence of routing.
• EpiChord uses p-way requests directed to peers nearest to the node. During periods of high churn, a peer maintains at least 2 active entries in each slice of its routing table. When the number of entries in a slice falls below 2, the peer issues parallel lookup messages to ids in the slice. These parallel lookup messages may be sent using multi- destination, multicast routing in the manner described above. Responses to these lookups are used to add entries to that slice in the routing table.
• Accordion is similar to EpiChord except that maintenance traffic is budgeted based on available bandwidth for each peer. Accordion uses recursive parallel lookups so as to maintain fresh routing table entries in its neighborhood of the overlay and reduce the probability of timeout. The peer requesting the lookup selects destinations based on the key and also gaps in its routing table. Responses to forwarded lookups contain entries for these routing table gaps. Excess bandwidth in the peer's bandwidth budget is used for parallel exploratory lookups to obtain routing table entries for the largest scaled gaps in the peer's routing table. The degree of parallelism is dynamically adjusted based on the level of lookup traffic and bandwidth budget, up to a maximum configuration such as 6-way.
• D1 HT is a one-hop overlay that defines the overlay maintenance algorithm EDRA (Event Detection and Reporting Algorithm), where an event is any join/leave action.
• EDRA Event Detection and Reporting Algorithm
• Iog 2 (x) successor peers at relative positions Iog 2 (0) through Iog 2 (n) as shown in Figure 6.
• ⁇ is the interval at which a peer propagates events to its successors in the ring
• Propagated events are those directly received as well as those received from predecessors since the last event message.
• TTL time to live
• Each peer receiving the message extracts its TTL from the list.
• Random walk has been shown to be the most efficient search technique in unstructured topologies that are represented as power-law graphs.
• a random walk if an incoming query can not be locally matched, the request is forwarded to a randomly selected neighbor, excluding the neighbor from which the request was received.
• Systems using random walk include Gia and LMS.
• Multi- destination, multicast routing can be used at the initial node in a parallel random walk to reduce edge traffic as well as some internal traffic. It can also be used in subsequent hops.
• Multicast trees define the data paths between nodes in the overlay network. Multicast trees are formed by considering constraints on the in-degree and out-degree of nodes. Since the nodes typically use unicast links to connect parent and children nodes, each link uses bandwidth on the node's network interface. To accommodate the limited branching factor permitted at each node generally increases path length in the tree, leading to larger end-to-end latency.
• Various protocols for constructing and maintaining these types of multicast trees are known in the art.
• a new messaging scheme is proposed that uses a multi- destination, multicast routing protocol to transmit data packets amongst the nodes in the multicast tree.
• the nodes in the overlay network are configured to forward data packets in accordance with a multi-destination, multicast routing protocol. Data packets may then be transmitted between nodes in accordance with a multicast tree using the multi-destination, multicast routing protocol.
• Figures 7A and 7B provide a comparison between the conventional scheme and the newly proposed messaging scheme. In Figure 7A, a data packet is sent using a conventional unicast approach; whereas, in Figure 7B, a data packet is sent using a multi-destination, multicast routing protocol.
• the content to many out-going links on a node can be carried in a single sequence of multi-destination addressed packets.
• the out-degree of the multi-destination routing nodes can be much higher, leading to lower latency multicast trees compared to the conventional approach.
• multicast routing means that the size limit of multi-destination routing can be overcome.
• a multi-destination packet is limited to a maximum of 50 destinations and each node is constrained to say C number of connections. Nevertheless we can form overlay trees of millions of nodes where each node connects to at most C*50 out-going nodes.
• Each node receiving a single incoming packet forwards it using a the set of address which corresponding to its adjacencies.
• the root of the tree can connect to C*50 children nodes.
• Each of these in turn can connect to up to C*50 children using separate multi-destination packets.
• some distributed hash tables support location-based searches.
• applications may search for services or information related to a specific location, such as a latitude-longitude position.
• a grid is often used to correlate multiple locations to a single identifier.
• the grid is referenced to find the nearest grid point to the location.
• the location data e.g., mailing address, postal code, latitude-longitude position, etc.
• multiple points on the grid are queried in parallel. For instance, if one wants to search for services in a larger area than a single grid point, then one queries a neighborhood of grid points in the given area. Rather than send a unicast message to each grid point, it is proposed to use multi-destination, multicast routing protocol to query a set of adjacent grid points.
• a service discovery mechanism of any type may support specific protocols for discovery, advertisement and invocation. It may also support specific service description formats and semantics.
• a service discovery mechanism may be administered within a network administration domain and has a type which defines its protocols and formats. Exemplary types include SLP, UDDI and LDAP. It is envisioned that DHTs may be used to locate service discovery mechanisms of interest within a peer-to-peer environment. Further details regarding this technique may be found in U.S. Provisional Patent Application No. 60/715,388 filed on September 8, 2005 which is incorporated herein by reference.
• a non-empty set of identifiers may be concatenated and used as input to a DHT._ Each such key and reference to a service discovery mechanism is inserted in the DHT.
• the reference to the DHT may be a description of the service discovery mechanism and its access method, a URI, or a software interface for communicating with service discovery mechanism. More than one key may be inserted into the DHT for a given service discovery mechanism, thereby supporting different ways of searching for the mechanism.
• an identifier may be segmented and each segment individually inserted into the DHT. This supports wild card and full-text retrieval lookup in certain DHT-based-systems.
• a service discovery mechanism may also have other attributes such as location of the domain or location of services administered by the domain. In these instances, location-based searches of DHTs may be used to locate a suitable service discovery mechanism. A plurality of grid points near the location of interest may be queried using a multi-destination, multicast routing protocol as discussed above. In this way, a peer can discover a service discovery mechanism based on location. [0049] Once again, only a few exemplary overlay operations have been described above. It is readily understood that the multi-destination, multicast routing protocol described above may be applied to other overlay operations having parallel messaging schemes. The following description is merely exemplary in nature and is not intended to limit the present disclosure, application, or uses.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Physics & Mathematics (AREA)
• Computing Systems (AREA)
• Mathematical Physics (AREA)
• Theoretical Computer Science (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Priority Applications (2)

Applications Claiming Priority (4)

Publications (2)

Family

ID=37836533

Family Applications (1)

Country Status (3)

Cited By (7)

Families Citing this family (16)

Family Cites Families (11)

• 2006
  • 2006-09-08 WO PCT/US2006/035116 patent/WO2007030742A2/en not_active Ceased
  • 2006-09-08 JP JP2008530233A patent/JP2009508410A/ja active Pending
  • 2006-09-08 US US11/991,633 patent/US20090116484A1/en not_active Abandoned

Also Published As

Similar Documents

Legal Events