ALTO M. Stiemerling
Internet-Draft NEC Europe Ltd.
Intended status: Informational S. Kiesel
Expires: September 2, 2010 March 1, 2010
ALTO Server Load Reduction
draft-stiemerling-alto-load-reduction-00
Abstract
Traffic localization for peer-to-peer applications is currently
discussed by the IETF ALTO working group. The protocol specification
itself is discussed and some issues about load reduction for ALTO/P4P
servers are also discussed, but mainly on the transport level (i.e.,
caching of traffic localization data) and some data aggregation by
using macros that comprise a number of IP prefixes. However, there
are no considerations about reducing the query load to the ALTO
server. This memo aims at giving informational guidance to P2P
applications implementers on how reduce the query load for ALTO.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Stiemerling & Kiesel Expires September 2, 2010 [Page 1]
Internet-Draft ALTO Server Load Reduction March 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Guidance on Load Reduction . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Stiemerling & Kiesel Expires September 2, 2010 [Page 2]
Internet-Draft ALTO Server Load Reduction March 2010
1. Introduction
Peers in current p2p systems are keeping track of their neighbor
peers (neighbors in the overlay) in a peer list. This peer list
typically divided in active peers (they deliver data/chunks),
candidate peers (peers that have been recently learned by the peer)
and dead peers (peers that have performed bad in the last epoch and
will be discarded at some point). The currently deployed peer-to-
peer systems work on time epochs, i.e., they exchange data with other
peers for a fixed time period, and after this period the peers
evaluate the usefulness of each peer in terms of throughput and if
the peer did have the requested chunk. A typical value for an epoch
is 30 seconds.
The current proposal in traffic localization (P4P/ALTO) assumes that
peers do always send the complete candidate set or the active set to
the server, asking for traffic localization guidance on that set.
However, the active and the candidate sets are changing frequently.
Every peer needs to query the ALTO server quite frequently with the
updated candidate or active set.
It is foreseeable that ALTO servers will need to be able to handle a
query load that is proportional to the number of peers (ALTO
clients), the query rate of the peers, and the amount of peers
included in each query. P2P systems maintain an active and a
candidate peers set that should be evaluated by the ALTO server, so
that it can give guidance about what peers are to be preferred. This
would require querying the ALTO server every epoch even though it is
not clear whether the candidate peers can actually deliver the
requested content at a desired throughput. Second, new peers can
also be learned on a peer base, i.e., not in a bulk via a resource
directory. In this case, the peer would query for single peers at
the ALTO server.
The steps are:
1. The peer obtains the set of new peers and adds them to its
candidate set (either via a resource directory (tracker) or via a
peer exchange protocol);
2. The peer queries the ALTO server with the candidate set;
3. The peer takes peers preferred by the ALTO server out of its
candidate sets and starts data exchange with them;
4. The peer moves a candidate peer to the active set, if the peers
has the data of interest and if the peer delivers sufficient
throughput (typically above a certain threshold);
Stiemerling & Kiesel Expires September 2, 2010 [Page 3]
Internet-Draft ALTO Server Load Reduction March 2010
5. The peer moves a candidate peer to the dead set of drops
immediately if the data of interest is not available or if the
throughput is below a certain threshold.
Imagine now that every peer queries for a complete candidate set
(100s of peers) every 30 seconds and that there are thousands of
peers within a single ISP. This will cause a high load on the ALTO
servers that need to handle the requests of all ALTO clients.
Furthermore, the peer will query for candidate peers although they
might not have the data of interest or they might not able to deliver
the desired throughput, causing unnecessary queries or entries in
queries.
We call the set of peers send to the ALTO server the query set, as it
may contain other peers as the actual candidate set, i.e., more or
less entries and completely other entries.
Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org.
Stiemerling & Kiesel Expires September 2, 2010 [Page 4]
Internet-Draft ALTO Server Load Reduction March 2010
2. Guidance on Load Reduction
The known candidate set is divided into two sets called Pending 1 and
Pending 2. The candidate set in regular p2p systems is comparable
with the Pending 1 set, as it takes a full list of candidate peers
that have been rated (i.e., sorted by costs and expected performance)
by the ALTO server in the ALTO query 1. This track in Figure 1 XXX
is mainly performed for candidate peers that have been obtained from
a resource directory (e.g. a tracker or a DHT). Peers in the Pending
1 set are evaluated in their order of ALTO rating and good peers are
transferred to the active peers sets. Peers that do not perform well
in the Pending 1 set are transferred to the dead peers set. However,
this track is as in today's p2p systems.
P2P systems use also a peer exchange (via gossiping) to learn other
new candidate peers that can be added to the candidate set. Each of
the new peer would have to be rated by the ALTO server for it costs
and expected performance. To avoid querying the ALTO server too
much, we introduce the track 2 that is depicted on the right side of
Figure 1 XXX. Once the peer has learned a new candidate peer, the
peer evaluates if the new peer is required right now (e.g. throughput
is insufficient). If not, the candidate peer is collected in a
buffer (top of figure). The buffer content is pushed to track 1 is
some candidate peers have been accumulated.
If a new candidate peer is required right now, the peer will first
test the connectivity to the candidate peer, without asking for the
ALTO server rating. The peer is transferred to the dead peer set if
it performs badly or if it is unreachable. If the candidate peer
performs well it is queried at the ALTO server. Depending on the
ALTO rating it is either transferred into the active peer set (cheap
candidate peer) or it is transferred to the dead peers set if it is
expensive and if there is no urgent need to get new peers. The
urgent need for peers can be, for instance, if the throughput of all
peers in the active set drops below a threshold. In this case, the
candidate peer is anyhow transferred to the active peers set despite
the ALTO rating of being expensive. This will avoid that the peer is
disconnected from the p2p network and that the ISP network will get
fragmentation, i.e., disconnected from the rest of the p2p network.
An extension of the above proposed track 2 is shown in Figure 2 XXX.
In this all candidate peers are subject to track 2. This will lower
the query load on the server, as first all candidate peers are
subject to the connectivity test in Pending 2 set. However, this can
cause a higher traffic on the peering links of the actual ISP, as all
peers are first tested (this includes exchanging data) and only the
good peers.
Stiemerling & Kiesel Expires September 2, 2010 [Page 5]
Internet-Draft ALTO Server Load Reduction March 2010
3. Security Considerations
This memo does not introduce any new security considerations, other
than the ones stated in [I-D.ietf-alto-protocol]
Stiemerling & Kiesel Expires September 2, 2010 [Page 6]
Internet-Draft ALTO Server Load Reduction March 2010
4. Conclusion
This memo aims at giving guidance to P2P application designers and
implementors to reduce the query load to ALTO servers. The proposed
mechanism does not need any modification of the ALTO server and can
be easily implemented in the ALTO client or in the P2P application.
The figures for Section 2 are still missing.
Martin Stiemerling is partially supported by the NAPA-WINE project
(Network-Aware P2P-TV Application over Wise Networks,
http://www.napa-wine.org), a research project supported by the
European Commission under its 7th Framework Program (contract no.
214412). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the NAPA-WINE project or the European Commission.
Stiemerling & Kiesel Expires September 2, 2010 [Page 7]
Internet-Draft ALTO Server Load Reduction March 2010
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References
[ACM.ispp2p]
Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs
and P2P systems co-operate for improved performance?", In
ACM SIGCOMM Computer Communications Review
(CCR), 37:3, pp. 29-40.
[I-D.akonjang-alto-proxidor]
Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D.
Saucez, "The PROXIDOR Service",
draft-akonjang-alto-proxidor-00 (work in progress),
March 2009.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-01 (work in progress),
December 2009.
[I-D.kiesel-alto-3pdisc]
Kiesel, S. and M. Tomsu, "Third-party ALTO server
discovery", draft-kiesel-alto-3pdisc-01 (work in
progress), October 2009.
[I-D.kiesel-alto-h12]
Kiesel, S. and M. Stiemerling, "ALTO H12",
draft-kiesel-alto-h12-01 (work in progress), March 2010.
[I-D.kiesel-alto-reqs]
Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.
Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-kiesel-alto-reqs-02 (work in
progress), March 2009.
[I-D.penno-alto-protocol]
Penno, R. and Y. Yang, "ALTO Protocol",
draft-penno-alto-protocol-04 (work in progress),
October 2009.
[I-D.shalunov-alto-infoexport]
Shalunov, S., Penno, R., and R. Woundy, "ALTO Information
Stiemerling & Kiesel Expires September 2, 2010 [Page 8]
Internet-Draft ALTO Server Load Reduction March 2010
Export Service", draft-shalunov-alto-infoexport-00 (work
in progress), October 2008.
[I-D.stiemerling-alto-h1h2-protocol]
Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol",
draft-stiemerling-alto-h1h2-protocol-00 (work in
progress), March 2009.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
Stiemerling & Kiesel Expires September 2, 2010 [Page 9]
Internet-Draft ALTO Server Load Reduction March 2010
Authors' Addresses
Martin Stiemerling
NEC Laboratories Europe/University of Goettingen
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 113
Fax: +49 6221 4342 155
Email: martin.stiemerling@neclab.eu
URI: http://www.nw.neclab.eu/
Sebastian Kiesel
Email: ietf-alto@skiesel.de
Stiemerling & Kiesel Expires September 2, 2010 [Page 10]