FYI
s.
Begin forwarded message:
From: IETF I-D Submission Tool <[email protected]>
Date: March 2, 2009 5:46:43 PM GMT+01:00
To: [email protected]
Cc: [email protected], [email protected],
[email protected], [email protected]
Subject: New Version Notification for draft-akonjang-alto-proxidor-00
A new version of I-D, draft-akonjang-alto-proxidor-00.txt has been
successfuly submitted by Obi Akonjang and posted to the IETF
repository.
Filename: draft-akonjang-alto-proxidor
Revision: 00
Title: The PROXIDOR Service
Creation_date: 2009-03-02
WG ID: Independent Submission
Number_of_pages: 16
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.
The IETF Secretariat.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
