RFC 6029

A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem

📅 published October 2010, from ietf

RFC 6029: A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem 💖

okay bestie, let's get into this one 🫶 It's an Informational RFC from the IRTF (Internet Research Task Force), published October 2010 as RFC 6029, with ISSN 2070-1721. The authors are I. Rimac, V. Hilt, M. Tomsu, and V. Gurbani from Bell Labs, Alcatel-Lucent, plus E. Marocco from Telecom Italia. Its title is "A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem" 🎀. The title block doesn't list anything it obsoletes or updates, so there's no mention of either here.

Abstract ✨

So a huge chunk of Internet traffic right now comes from peer-to-peer (P2P) apps 🦋. They started out for file sharing and have moved on to real-time communications and live media streaming. These apps find each other through an overlay network and barely know anything about the network underneath it 🙈. So when they pick a peer, they often go off measurements they've made themselves, and that can lead to choices that aren't the best. This document is a survey from the P2P Research Group 🌸. It rounds up the existing research on finding and using network topology info for Application-Layer Traffic Optimization. Iconic research recap, honestly 💅.

Status of This Memo 📜

This one is not an Internet Standards Track spec. It's published just for information 💜.

It's a product of the Internet Research Task Force (IRTF), which publishes research and development results about the Internet. Those results might not be ready for deployment, periodt ⭐. This RFC reflects what the Peer-to-Peer Research Group of the IRTF agreed on. Anything the IRSG approves for publication isn't a candidate for any level of Internet Standard. You can see Section 2 of RFC 5741 for the details 🔥.

For current status, errata, or feedback, check out http://www.rfc-editor.org/info/rfc6029 🧚.

Copyright (c) 2010 IETF Trust and the people listed as the document's authors. All rights reserved 🌈.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you'll find at http://trustee.ietf.org/license-info, as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this document 📜.

Table of Contents 🍓

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Survey of Existing Literature  . . . . . . . . . . . . . . . .  4
     2.1.  Application-Level Topology Estimation  . . . . . . . . . .  5
     2.2.  Topology Estimation through Layer Cooperation  . . . . . .  8
       2.2.1.  P4P Architecture . . . . . . . . . . . . . . . . . . .  9
       2.2.2.  Oracle-Based ISP-P2P Collaboration . . . . . . . . . .  9
       2.2.3.  ISP-Driven Informed Path Selection (IDIPS) Service . . 10
   3.  Application-Level Topology Estimation and the ALTO Problem . . 10
   4.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Coordinate Estimation or Path Latencies? . . . . . . . . . 12
     4.2.  Malicious Nodes  . . . . . . . . . . . . . . . . . . . . . 12
     4.3.  Information Integrity  . . . . . . . . . . . . . . . . . . 12
     4.4.  Richness of Topological Information  . . . . . . . . . . . 13
     4.5.  Hybrid Solutions . . . . . . . . . . . . . . . . . . . . . 13
     4.6.  Negative Impact of Over-Localization . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 14

1. Introduction 🦋

Lots of today's Internet traffic is P2P, and it started with file sharing before moving into real-time multimedia and live streaming 🎧. P2P apps are a real headache for Internet infrastructure. Some estimates say P2P systems make up somewhere between 40% and 85% of all Internet traffic, citing [Karagiannis], [LightReading], [LinuxReviews], [Parker], [Glasner]. Obsessed with how wild that number is, honestly 😭.

P2P systems keep popular content copied across several instances in the overlay. But here's the ironic part 💅: a peer hunting for that content can ignore the topology of the overlay underneath and just pick among the instances based on its own measurements. In some situations, that leads to suboptimal choices. For example, a shorter round-trip time estimate doesn't tell you much about the bandwidth and reliability of the underlying links. Those matter more than delay for big file transfers in P2P apps 🍓.

Most Distributed Hash Tables (DHTs), which are the data structures that give P2P overlays their ordering, use greedy forwarding algorithms to reach a destination. They make locally optimal decisions that may not add up to something globally optimized [Gummadi] 🧚. That leads straight to the Application-Layer Traffic Optimization (ALTO) problem [RFC5693]. The question is how to best expose the topology of the underlying network, while still letting the requesting node use that info to reach the node holding the content effectively ✨. So it kind of looks like P2P networks, with their application-layer routing based on overlay topologies, are in direct competition with Internet routing and topology 👑.

One way to handle the ALTO problem is to build distributed application-level services for location and path selection [Francis], [Ng], [Dabek], [Costa], [Wong], [Madhyastha]. Those let peers estimate where they sit in the network and pick their neighbors more efficiently 🌈. Similar ideas have been built into P2P apps like Vuze [Vuze]. A slightly different approach has the Internet service provider (ISP) take a proactive role in routing P2P app traffic, and some ways of doing that have been proposed [Aggarwal], [Xie], [Saucez]. There's an intrinsic struggle between the two layers, the P2P overlay and the network underlay, when they're both doing the same job (routing) 💀. Still, there are strategies to soften that dichotomy [Seetharaman] 🫶.

This document started as a complement to RFC 5693 [RFC5693] and was discussed while the IETF ALTO Working Group was forming. It has since been finished and refined in the IRTF P2P Research Group 🎀. The goal is to sum up current research on Application-Layer Traffic Optimization so the ALTO working group's protocol designers have something to work from 💖.

1.1. Terminology 📚

Some terms in this doc come from P2P scientific literature, like "ring geometry", "tree structure", and "butterfly network" 🧠. [RFC4981] gives a thorough definition of this terminology.

Certain security-related terms should be read the way [RFC4949] defines them. Those include, but aren't limited to, "attack", "authentication", "confidentiality", "encryption", "identity", and "integrity" 🔐. Other security terms, like "denial of service", should be read as the referenced specifications define them 🙈.

2. Survey of Existing Literature 💜

Gummadi et al. [Gummadi] compare popular DHT algorithms. Besides looking at how resilient they are, they carefully evaluate how well the logical overlay topology maps onto the physical network layer 🔍. Their method relies only on measurements that overlay nodes make on their own, with no extra location info from outside entities. What they found is that the most efficient algorithms, for both resilience and proximity performance, are the ones built on the simplest geometric concept, the ring geometry, and not the tree structures, butterfly networks, or hybrid geometries 💅✨.

No matter what geometry the distributed data structures use, the interactions between application-layer overlays and the networks underneath are a rich area to dig into 🌸. The literature in this field falls into two categories, shown in Figure 1: using application-level techniques to estimate topology, and using some kind of layer cooperation to estimate topology 🦋.

     Application-layer traffic optimization
       |
       +--> Application-level topology estimation
       |      |
       |      +--> Coordinates-based systems
       |      |      |
       |      |      +--> GNP
       |      |      |
       |      |      +--> Vivaldi
       |      |      |
       |      |      +--> PIC
       |      |
       |      +--> Path selection services
       |      |      |
       |      |      +--> IDMaps
       |      |      |
       |      |      +--> Meridian
       |      |      |
       |      |      +--> Ono
       |      |
       |      +--> Link-layer Internet maps
       |             |
       |             +--> iPlane
       |
       +--> Topology estimation through layer cooperation
              |
              +--> P4P: Provider portal for applications
              |
              +--> Oracle-based ISPs and P2P cooperation
              |
              +--> ISP-driven informed path selection

     Figure 1: Taxonomy of Solutions for the Application-Layer Traffic
                           Optimization Problem

2.1. Application-Level Topology Estimation ✨

Okay bestie, estimating network topology on the application layer has been a seriously active research area 🔍. Early systems used triangulation techniques to bound the distance between two hosts using a common landmark host 🗺️. The setup goes like this: you have a cost function C, a set of vertexes V and their corresponding edges, and the triangle inequality holds if, for any triple {a, b, c} in V, C(a, c) is always less than or equal to C(a, g) + C(b, c) 📐. The cost function C can be expressed in terms of desirable metrics like bandwidth or latency 💖.

We have to note that the techniques in this section are only representative of the sizable research in this area 🌸. We're not trying to list every single one, because we picked certain techniques that represent an advance in the area and then led to derivative works ✨. It's giving curated, not complete 💅.

Francis et al. proposed IDMaps [Francis], a system where one or more special hosts called tracers are deployed near an autonomous system 🛰️. The distance measured in round-trip time (RTT) between hosts A and B is estimated as the cumulative distance between A and its nearest tracer Ta, plus the distance between B and its nearest tracer Tb, plus the shortest distance from Ta to Tb 🧮. To help with scalability beyond what the client-server design of IDMaps could do, Ng et al. proposed a P2P-based Global Network Positioning (GNP) architecture [Ng] 🦋. GNP was a network coordinate system based on absolute coordinates, computed by modeling the Internet as a geometric space 🌈. It had a two-part architecture 👑. In the first part, a small set of finite distributed hosts called landmarks compute their own coordinates in a fixed geometric space. In the second part, a host that wants to participate computes its own coordinates relative to those of the landmark hosts. So armed with those computed coordinates, hosts can then determine interhost distance as soon as they discover each other 🫶.

Both IDMaps and GNP need fixed network infrastructure support in the form of tracers or landmark hosts, and this often introduces a single point of failure and inhibits scalability 😭. To combat this, new techniques were developed that embedded the network topology in a low-dimensional coordinate space, so network distance could be estimated through vector analysis 📊. Costa et al. introduced Practical Internet Coordinates (PIC) [Costa] 🎀. While PIC used the notion of landmark hosts, it did not require explicit network support to designate specific landmark hosts. Any node whose coordinates have been computed could act as a landmark host 🙌. When a node joined the system, it probed the network distance to some landmark hosts. Then it obtained the coordinates of each landmark host and computed its own coordinates relative to each one, subject to the constraint of minimizing the error between the predicted distance and the computed distance 🎯.

Like PIC, Vivaldi [Dabek] proposed a fully distributed network coordinate system without any distinguished hosts 🧚. Whenever a node A communicates with another node B, it measures the RTT to that node and learns that node's current coordinates. Node A then adjusts its coordinates so that it gets closer to, or further from, B, by computing new coordinates that minimize the squared error 📉. A Vivaldi node is basically always adjusting its position based on a simulation of interconnected mass springs, which is so random but also so cool 🌀. Vivaldi is now being used in the popular P2P application Vuze, and studies indicate that it scales well to very large networks [Ledlie] 🚀.

Network coordinate systems require embedding the Internet topology into a coordinate system. This isn't always possible without errors, and those errors affect the accuracy of distance estimations 🙈. In particular, it has proved hard to embed the triangular inequalities found in Internet path distances [Ledlie]. So Meridian [Wong] abandons the generality of network coordinate systems and provides specific distance evaluation services 🎯. In Meridian, each node keeps track of a small fixed number of neighbors and organizes them in concentric rings, ordered by distance from the node 💜. Meridian finds the closest node by running a multi-hop search where each hop exponentially reduces the distance to the target 🏹. Although it's less general than virtual coordinates, Meridian incurs significantly less error for closest node discovery 👑.

The Ono project [Ono] takes a different approach and uses network measurements from Content Distribution Networks (CDNs) such as Akamai to find nearby peers 🌐. Used as a plugin to the Vuze bittorrent client, Ono provides 31% average download rate improvement [Su] 🔥.

 Comparison of application-level topology estimation techniques, as
    reported in literature.  Results in terms of number of (D)imensions
             and (L)andmarks, 90th percentile relative error.

   +----------------+---------------+----------------+-----------------+
   | GNP vs.        | PIC(b) vs.    | Vivaldi vs.    | Meridian vs.    |
   | IDMaps(a) (7D, | GNP (8D, 16L) | GNP (2D, 32L)  | GNP (8D, 15L)   |
   | 15L)           |               |                |                 |
   +----------------+---------------+----------------+-----------------+
   | GNP: 0.50,     | PIC: 0.38,    | Vivaldi: 0.65, | Meridian: 0.78, |
   | IDMaps: 0.97   | GNP: 0.37     | GNP: 0.65      | GNP: 1.18       |
   +----------------+---------------+----------------+-----------------+

                 (a) Does not use dimensions or landmarks.
            (b) Uses results from the hybrid strategy for PIC.

                                  Table 1

Table 1 summarizes the application-level topology estimation techniques 📋. The salient performance metric is the relative error 🔑. While all approaches define this metric a bit differently, it can be generalized as how close a predicted distance comes to the corresponding measured distance. A value of zero implies perfect prediction, and a value of 1 implies that the predicted distance is in error by a factor of two 🤓. PIC, Vivaldi, and Meridian compare their results with GNP's, while GNP itself compares its results with a precursor technique, IDMaps 🥇. Because each technique uses a different Internet topology and a varying number of landmarks and dimensions to interpret the data set, it is impossible to normalize the relative error across all techniques uniformly 😵‍💫. So we present the relative error data in pairs, as reported in the literature describing each specific technique. Readers are urged to compare the relative error performance in each column on its own and not draw any conclusions by comparing the data across columns ⚠️.

Most of the work on estimating topology information focuses on predicting network distance in terms of latency, and it doesn't provide estimates for other metrics such as throughput or packet loss rate 🙃. However, for many P2P applications latency isn't the most important performance metric, so these applications could benefit from a richer information plane 💫. Sophisticated methods of active network probing and passive traffic monitoring are generally very powerful. They can generate network statistics that are indirectly related to performance measures of interest, such as delay and loss rate at link-level granularity 🔬. Those hidden attributes can be extracted by applying statistical inference techniques from the field of inferential network monitoring, or network tomography, after sampling the network state 🧠. So network tomography enables extraction of a richer set of topology information, but at the same time it inherently increases the complexity of a potential information plane and introduces estimation errors 😬. For both active and passive methods, statistical models for the measurement process need to be developed, and the spatial and temporal dependence of the measurements should be assessed. Moreover, measurement methodology and statistical inference strategy must be considered jointly 🫠. For a deeper dive into network tomography and recent developments in the field, we refer the reader to [Coates] 📚.

One system providing such a service is iPlane [Madhyastha], which aims to create an annotated atlas of the Internet containing information about latency, bandwidth, capacity, and loss rate 🗺️✨. To determine features of the Internet topology, iPlane bridges and builds upon different ideas, such as active probing based on packet dispersion techniques to infer available bandwidth along path segments 🎢. These ideas come from different fields, including network measurement as described by Dovrolis et al. in [Dovrolis] and network tomography [Coates] 💜.

2.2. Topology Estimation through Layer Cooperation 🤝

Instead of estimating topology information on the application level through distributed measurements, this information could be provided by the entities running the physical networks, usually ISPs or network operators 🏢. They actually have full knowledge of the topology of the networks they administer, and to avoid congestion on critical links, they're interested in helping applications optimize the traffic they generate 🚦. The rest of this section briefly describes three recently proposed solutions that follow this approach to address the ALTO problem 🎀.

2.2.1. P4P Architecture 🌸

The architecture proposed by Xie et al. [Xie] has been adopted by the Distributed Computing Industry Association (DCIA) P4P working group [P4P], an open group established by ISPs, P2P software distributors, and technology researchers 🫶. Its dual goal is defining mechanisms to (1) accelerate content distribution and (2) optimize utilization of network resources 🎯.

The main role in the P4P architecture is played by servers called "iTrackers" 👑. Network providers deploy them, and P2P applications (or, in general, elements of the P2P system) access them to make optimal decisions when selecting a peer to connect to 🧚. An iTracker may offer three interfaces:

  1. Info: Allows P2P elements (e.g., peers or trackers) to get opaque information associated with an IP address. Such information is kept opaque to hide the actual network topology, but it can be used to compute the network distance between IP addresses 🔍.
  2. Policy: Allows P2P elements to obtain policies and guidelines of the network, which specify how a network provider would like its networks to be utilized at a high level, regardless of P2P applications 📜.
  3. Capability: Allows P2P elements to request network providers' capabilities 💅.

The P4P architecture is being evaluated with simulations, experiments on the PlanetLab distributed testbed, and field tests with real users 🧪. Initial simulations and PlanetLab experiment results [P4P] indicate that improvements in BitTorrent download completion time and link utilization in the range of 50-70% are possible 📈. Results observed on Comcast's network during a field test trial, conducted with a modified version of the software used by the Pando content delivery network (documented in RFC 5632 [RFC5632]), show average improvements in download rate varying between 57% and 85% in different scenarios 🤯. The same trial also showed a 34% to 80% drop in the cross-domain traffic generated by such an application 🔥.

2.2.2. Oracle-Based ISP-P2P Collaboration 🔮

okay so in the general solution from Aggarwal et al. [Aggarwal], network providers run host servers called "oracles" 🧚 that help P2P users pick their best neighbors ✨

Here's how the oracle idea works: a P2P client sends its list of potential peers to the oracle hosted by its ISP, and gets back a re-arranged peer list. The order follows the ISP's local routing policies and preferences. For example, to keep traffic local, the ISP might prefer peers inside its own network, or pick links with higher bandwidth, or peers that are geographically closer so apps perform better 💅. Once the client has this ordered list, it has enough info to do better-than-random initial peer selection 🎀

This was tested with simulations and experiments on the PlanetLab testbed, and the results show both faster content download times and less overall P2P traffic 🔥. That held up even when only some of the apps actually asked the oracle to make their choices 🙈

2.2.3. ISP-Driven Informed Path Selection (IDIPS) Service 🦋

The solution from Saucez et al. [Saucez] is basically a modified version of the oracle approach from Section 2.2.2 😌. It's meant to be a network-layer service that finds the best source and destination addresses when two endpoints want to connect in multi-homed environments (which are super common in IPv6 networking 🌐). Peer selection optimization in P2P systems, aka the ALTO problem in today's Internet, can be handled by IDIPS as a specific sub-case. There, the destination address options are all the peers sharing a desired resource, while the source address choice is fixed. An evaluation of IDIPS shows that the costs of both providing and accessing the service are negligible 💖

3. Application-Level Topology Estimation and the ALTO Problem 🗺️

The application-level techniques from Section 2.1 give P2P apps tools to estimate parameters of the underlying network topology. These techniques can improve app performance, but there are limits to what you can achieve by working only at the application level 🫶

Topology estimation techniques use abstractions of the network topology, and those often hide features the app would actually care about. Network coordinate systems, for example, are unable to detect overlay paths shorter than the direct path in the Internet topology 😭. But these paths frequently exist in the Internet [Wang]. Similarly, application-level techniques may not accurately estimate topologies with multipath routing 🤔

When you use network coordinates to estimate topology information, the underlying assumption is that distance in terms of latency determines performance. But for file sharing and content distribution apps, there's more to performance than just network latency between nodes. The utility of a long-lived data transfer is determined by the throughput of the underlying TCP protocol, which depends on the round-trip time as well as the loss rate experienced on the corresponding path [Padhye]. So these apps benefit from a richer set of topology info that goes beyond latency, including loss rate, capacity, and available bandwidth 📈

Some of the topology estimation techniques P2P apps use need time to converge on a result. For example, current BitTorrent clients implement local, passive traffic measurements and a tit-for-tat bandwidth reciprocity mechanism to optimize peer selection at a local level. Peers eventually settle on a set of neighbors that maximizes their download rate. But because peers can't reason about the value of neighbors without actively exchanging data with them, and because the number of concurrent data transfers is limited (typically to 5-7), convergence is delayed and easily can be sub-optimal 🐢

Skype's P2P Voice over IP (VoIP) app chooses a relay node when two peers are behind NATs and can't connect directly 📞. Measurements taken by Ren et al. [Ren] showed that Skype's relay selection mechanism (1) isn't able to discover the best possible relay nodes in terms of minimum RTT, (2) requires a long setup and stabilization time, which degrades the end user experience, and (3) creates a non-negligible amount of overhead traffic due to probing a large number of nodes 😵. They further showed that relay path quality could be improved when the underlying network Autonomous System (AS) topology is considered 💡

Some features of the network topology are hard to infer through application-level techniques, and it may not be possible to infer them at all, e.g., service-provider policies and preferences such as the state and cost associated with interdomain peering and transit links 🙃. Another example is the traffic engineering policy of a service provider, which may counteract the routing objective of the overlay network, leading to poor overall performance [Seetharaman] 😬.

Finally, application-level techniques often require apps to perform measurements on the topology. These measurements create traffic overhead, in particular if every app interested in estimating topology measures individually 📉

4. Open Issues 🚧

Beyond a significant amount of research work on the topic, we believe there are sizable open issues to address in an infrastructure-based approach to traffic optimization. The following isn't an exhaustive list, but a representative sample of the pertinent issues 🧐

4.1. Coordinate Estimation or Path Latencies? 📏

Despite the many solutions proposed for giving applications topology information in a fully distributed manner, the research community is currently debating whether such solutions should focus on estimating nodes' coordinates or path latencies. That debate got a fresh boost from studies showing that the triangle inequality, which coordinate systems are based on, often turns out to be false in the Internet [Ledlie]. Proposed systems following both approaches have been simulated, implemented, and studied in real-world trials, each showing different strengths and weaknesses 🥊. Vivaldi [Dabek] and PIC [Costa] follow the former, while Meridian [Wong] and iPlane [Madhyastha] follow the latter. Concentrated work will be needed to determine which of the two solutions will be conducive to the ALTO problem 🔍

4.2. Malicious Nodes 😈

Another open issue, common in most distributed environments with a large number of peers, is resistance against malicious nodes. Security mechanisms that identify misbehavior are based on triangle inequality checks [Costa]. Those checks tend to fail and return false positives when measurement inaccuracies show up, for example from traffic fluctuations that happen quite often in large networks [Ledlie]. This is a big deal 🚨. Beyond the issue of using triangle inequality checks, authoritatively authenticating the identity of an oracle, and preventing an oracle from being attacked, are also important. Existing techniques, such as Public Key Infrastructure (PKI) [RFC5280] or identity-based encryption [Boneh] for authenticating identity, and secure multi-party computation techniques to prevent an oracle from collusion attacks, need to be explored and studied for judicious use in ALTO-type solutions 🔐

4.3. Information Integrity 🕵️

Similarly, even in controlled architectures deployed by network operators, where system elements may be authenticated [Xie], [Aggarwal],[Saucez], the information returned to applications can still be deliberately altered. For example, a higher priority might go to financially inexpensive links instead of neutrally applying proximity criteria 💸. What are the effects of such deliberate alterations if multiple peers collude to determine a different route to the target, one that the oracle doesn't provide? Similarly, what happens if an oracle targets a particular node in another AS by redirecting an inordinate number of querying peers to it, causing essentially a Distributed Denial-of-Service (DDoS) [RFC4732] attack on that node? 😱 Furthermore, does an oracle broadcast or multicast a response to a query? If so, techniques to protect the confidentiality of the multicast stream will need to be investigated to thwart "free riding" peers 🛡️

4.4. Richness of Topological Information 🌈

Many systems already use RTT to account for delay when establishing connections with peers (e.g., Content-Addressable Network (CAN) [Ratnasamy], Bamboo [Rhea]). An operator can provide not only the delay metric but also other metrics that the peer can't figure out on its own. These metrics may include the characteristics of the access links to other peers, bandwidth available to peers (based on operators' engineering of the network), network policies, preferences such as state and cost associated with intradomain peering links, and so on 🧩. Exactly what kinds of metrics an operator can provide to stabilize the network throughput will also need to be investigated 📊

4.5. Hybrid Solutions 🤝

It's conceivable that P2P users may not be comfortable with operator intervention to provide topology information. To eliminate this intervention, alternative schemes to estimate topological distance can be used. For instance, Ono uses client redirections generated by Akamai CDN servers as an approximation for estimating distance to peers, and Vivaldi, GNP, and PIC use synthetic coordinate systems 🛰️. A neutral third party can make available a hybrid layer-cooperation service, without the active participation of the ISP, that uses alternative techniques discussed in Section 2.1 to create a topological map. This map can then be used by a subset of users who may not trust the ISP 🫂

4.6. Negative Impact of Over-Localization 🌀

The literature presented in Section 2 shows that a certain level of locality-awareness in the peer selection process of P2P algorithms is usually beneficial to application performance. However, excessive localization of the traffic might cause partitioning in the overlay interconnecting these peers, which will negatively affect the performance the peers themselves experience 🧱

Finding the right balance between localization and randomness in peer selection is an open issue. At the time of writing, it seems that different applications have different levels of tolerance and should be addressed separately. Le Blond et al. [LeBlond] studied the specific case of BitTorrent and proposed a simple mechanism to prevent partitioning in the overlay, yet reach a high level of cross-domain traffic reduction without adversely impacting peers. that's the glow-up we love to see 🌈✨

5. Security Considerations 🔒

okay so this document is a survey of existing literature on topology estimation, which means it doesn't introduce any new security considerations 🙈 everything is already discussed in each paper it surveys. iykyk 💅

insofar as topology estimation is used to provide a solution to the ALTO problem, the issues in Sections 4.2 and 4.3 deserve special attention 😭 there are efforts underway in the IETF ALTO working group to design a protocol that protects the privacy of the peer-to-peer users as well as the service providers 🫶 [Chen] provides an overview of ALTO security issues, Section 11 of [Alimi] is an exhaustive overview of ALTO security, and Section 6 of RFC 5693 [RFC5693] also lists the privacy and confidentiality aspects of an ALTO solution 🎀

the following references are a starting point for general peer-to-peer security issues: [Wallach], [Sit], [Douceur], [Castro], and [Friedman] 🧚✨

6. Acknowledgments 💜

this document is a derivative work of a position paper submitted at the IETF RAI area/MIT workshop held on May 28th, 2008 on the topic of Peer-to-Peer Infrastructure (P2Pi) [RFC5594] 🌸 the article on a similar topic, also written by the authors of this document and published in IEEE Communications [Gurbani], was also partially derived from the same position paper 📚

the authors thank profusely Arnaud Legout, Richard Yang, Richard Woundy, Stefano Previdi, and the many people who have participated in discussions and provided insightful feedback at any stage of this work literally the best group of people ever 💖👑

7. Informative References ✨

okay bestie, this is the reading list 📚 every paper and draft the RFC leaned on, all listed with their full details so you can go find them yourself. no cap, the research trail is iconic 💅

  • [Aggarwal] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P users cooperate for improved performance?", in ACM SIGCOMM Computer Communications Review, vol. 37, no. 3.
  • [Alimi] Alimi, R., Ed., Penno, R., Ed., and Y. Yang, Ed., "ALTO Protocol", Work in Progress, July 2010.
  • [Boneh] Boneh, D. and M. Franklin, "Identity-Based Encryption from the Weil Pairing", in Proceedings of the 21st Annual International Cryptology Conference on Advances in Cryptology, August 2001. 🔐
  • [Castro] Castro, M., Druschelw, P., Ganesh, A., Rowstron, A., and D. Wallach, "Security for Structured Peer-to-peer Overlay Networks", in Proceedings of Symposium on Operating Systems Design and Implementation (OSDI'02), December 2002. 🛡️
  • [Chen] Chen, S., Gao, F., Beijing, X., and M. Xiong, "Overview for ALTO Security Issues", Work in Progress, February 2010.
  • [Coates] Coates, M., Hero, A., Nowak, R., and B. Yu, "Internet Tomography", in IEEE Signal Processing Magazine, vol. 19, no. 3.
  • [Costa] Costa, M., Castro, M., Rowstron, A., and P. Key, "PIC: Practical Internet coordinates for distance estimation", in Proceedings of International Conference on Distributed Systems 2003.
  • [Dabek] Dabek, F., Cox, R., Kaashoek, F., and R. Morris, "Vivaldi: A Decentralized Network Coordinate System", in ACM SIGCOMM: Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications, vol. 34, no. 4. 🦋
  • [Douceur] Douceur, J., "The Sybil Attack", in Proceedings of the First International Workshop on Peer-to-Peer Systems, March 2002.
  • [Dovrolis] Dovrolis, C., Ramanathan, P., and D. Moore, "What do packet dispersion techniques measure?", in Proceedings of IEEE INFOCOM 2001.
  • [Francis] Francis, P., Jamin, S., Jin, C., Jin, Y., Raz, D., Shavitt, Y., and L. Zhang, "IDMaps: A global Internet host distance estimation service", in Proceedings of IEEE INFOCOM 2001.
  • [Friedman] Friedman, A. and A. Camp, "Peer-to-Peer Security", in The Handbook of Information Security, J. Wiley & Sons, 2005.
  • [Glasner] Glasner, J., "P2P fuels global bandwidth binge", available from http://www.wired.com/.
  • [Gummadi] Gummadi, K., Gummadi, R., Gribble, S., Ratnasamy, S., Shenker, S., and I. Stoica, "The impact of DHT routing geometry on resilience and proximity", in ACM SIGCOMM: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications. 🌸
  • [Gurbani] Gurbani, V., Hilt, V., Rimac, I., Tomsu, M., and E. Marocco, "A Survey of Research on the Application-Layer Traffic Optimization Problem and the Need for Layer Cooperation", in IEEE Communications, vol. 47, no. 8.
  • [Karagiannis] Karagiannis, T., Broido, A., Brownlee, N., Claffy, K., and M. Faloutsos, "Is P2P dying or just hiding?", in Proceedings of IEEE GLOBECOM 2004 Conference.
  • [LeBlond] Le Blond, S., Legout, A., and W. Dabbous, "Pushing BitTorrent Locality to the Limit", available at http://hal.inria.fr/.
  • [Ledlie] Ledlie, J., Gardner, P., and M. Seltzer, "Network Coordinates in the Wild", in USENIX: Proceedings of NSDI 2007. 🌐
  • [LightReading] LightReading, "Controlling P2P traffic", available from http://www.lightreading.com/.
  • [LinuxReviews] linuxReviews.org, "Peer to peer network traffic may account for up to 85% of Internet's bandwidth usage", available from http://linuxreviews.org/.
  • [Madhyastha] Madhyastha, H., Isdal, T., Piatek, M., Dixon, C., Anderson, T., Krishnamurthy, A., and A. Venkataramani, "iPlane: an information plane for distributed services", in USENIX: Proceedings of the 7th symposium on Operating systems design and implementation.
  • [Ng] Ng, T. and H. Zhang, "Predicting internet network distance with coordinates-based approaches", in Proceedings of INFOCOM 2002.
  • [Ono] "Northwestern University Ono Project", <http://www.aqualab.cs.northwestern.edu/projects/Ono.html>.
  • [P4P] "DCIA P4P Working group", <http://www.dcia.info/activities/#P4P>. 💜
  • [Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP throughput: A simple model and its empirical validation", in Technical Report UM-CS-1998-008, University of Massachusetts 1998.
  • [Parker] Parker, A., "The true picture of peer-to-peer filesharing", available from http://www.cachelogic.com/.
  • [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
  • [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.
  • [RFC4981] Risson, J. and T. Moors, "Survey of Research towards Robust Peer-to-Peer Networks: Search Methods", RFC 4981, September 2007.
  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
  • [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", RFC 5594, July 2009.
  • [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and Y. Yang, "Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial", RFC 5632, September 2009.
  • [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
  • [Ratnasamy] Ratnasamy, S., Francis, P., Handley, M., Karp, R., and S. Shenker, "A Scalable Content-Addressable Network", in ACM SIGCOMM: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, January 2001.
  • [Ren] Ren, S., Guo, L., and X. Zhang, "ASAP: An AS-aware peer-relay protocol for high quality VoIP", in Proceedings of IEEE ICDCS 2006. 📞
  • [Rhea] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "OpenDHT: a public DHT service and its uses", in ACM SIGCOMM: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications, August 2005.
  • [Saucez] Saucez, D., Donnet, B., and O. Bonaventure, "Implementation and Preliminary Evaluation of an ISP-Driven Informed Path Selection", in Proceedings of ACM CoNEXT 2007.
  • [Seetharaman] Seetharaman, S., Hilt, V., Hofmann, M., and M. Ammar, "Preemptive Strategies to Improve Routing Performance of Native and Overlay Layers", in Proceedings of IEEE INFOCOM 2007.
  • [Sit] Sit, E. and R. Morris, "Security Considerations for Peer-to-Peer Distributed Hash Tables, Revised Papers from the First", in Proceedings of the First International Workshop on Peer-to-Peer Systems, March 2002. 🔒
  • [Su] Su, A., Choffnes, D., Kuzmanovic, A., and F. Bustamante, "Drafting behind Akamai (travelocity-based detouring)", in ACM SIGCOMM: Proceedings of the 2006 conference on Applications, technologies, architectures, and protocols for computer communications.
  • [Vuze] "Vuze bittorrent client", <http://www.vuze.com/>.
  • [Wallach] Wallach, D., "A survey of peer-to-peer security issues", in Proceedings of International Symposium on Software Security, 2002.
  • [Wang] Wang, G., Zhang, B., and T. Ng, "Towards Network Triangle Inequality Violation Aware Distributed Systems", in ACM SIGCOMM: Proceedings of the 7th conference on Internet measurement. 🧚
  • [Wong] Wong, B., Slivkins, A., and E. Sirer, "Meridian: A lightweight network location service without virtual coordinates", in ACM SIGCOMM: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications.
  • [Xie] Xie, H., Krishnamurthy, A., Silberschatz, A., and Y. Yang, "P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers", in ACM SIGCOMM Computer Communication Review, vol. 38, no. 4.

Authors' Addresses 🎀

these are the squad who wrote it, the people to thank (or slide into the DMs of) 🫶

  • Ivica Rimac, Bell Labs, Alcatel-Lucent, EMail: rimac@bell-labs.com
  • Volker Hilt, Bell Labs, Alcatel-Lucent, EMail: volkerh@bell-labs.com
  • Marco Tomsu, Bell Labs, Alcatel-Lucent, EMail: marco.tomsu@alcatel-lucent.com
  • Vijay K. Gurbani, Bell Labs, Alcatel-Lucent, EMail: vkg@bell-labs.com
  • Enrico Marocco, Telecom Italia, EMail: enrico.marocco@telecomitalia.it

and that's a wrap on the whole RFC 🌈✨ literally iconic work from this team 👑

📦 where this page comes from