Skip to main content

The PROXIDOR Service
draft-akonjang-alto-proxidor-00

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Obi Akonjang , Anja Feldmann , Stefano Previdi , Dr. Bruce S. Davie , Damien Saucez
Last updated 2009-03-02
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

Several applications, such as peer-to-peer (P2P), content distribution and realtime services rely on selection mechanisms in order to select the peer or server from which to request the service. Examples of such services are: file sharing, media streaming and voice gateways. Application-layer selection algorithms do not typically take into account network-layer topology information; either that information is unavailable to them, or when such information is available (e.g., from BGP Looking Glass servers), it does not include sufficient information about the local topology in the neighbourhood of the application client(s). Therefore, most applications today make their selection decisions based on performance measurements (combined with some amount of random selection) and largely ignore network layer routing. It has been demonstrated that by keeping the traffic local (e.g., within the same Autonomous System) both infrastructure utilization and application performance may be improved. By enhancing selection algorithms through the use of accurate network-layer topology, applications may improve performance while network operators are also able to reduce the utilization of infrastructure resources by application traffic. At the same time, exchange of information between the application and the network should not be allowed to compromise confidentiality for either party. Detailed routing information owned by the service provider should not be made publicly available, while detailed information about the application should also not be made known to the service provider. This draft introduces a signaling protocol which we call "PROXIDOR". The PROXIDOR protocol is a request-response protocol in which a PROXIDOR Client (PxC) issues requests to and receives responses from a PROXIDOR Server (PxS). The questions of how a PxC discovers a PxS and how a PxS acquires network-layer topology information are beyond the scope of this document.

Authors

Obi Akonjang
Anja Feldmann
Stefano Previdi
Dr. Bruce S. Davie
Damien Saucez

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)