Internet DRAFT - draft-picconi-alto-home-proxy
draft-picconi-alto-home-proxy
ALTO Fabio Picconi
Internet-Draft Technicolor
Intended Status: Informational
Expires: April 23, 2012 October 21, 2011
ALTO home proxy
draft-picconi-alto-home-proxy-00
Abstract
This documents discusses the use of ALTO proxies running on home
devices such as gateways or home NAS servers. An ALTO home proxy
caches ALTO information obtained from an origin ALTO server, and uses
that information to serve queries originating from the home network.
ALTO home proxies reduce ALTO traffic and query latency, improve
scalability, and enhance user privacy.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fabio Picconi Expires April 23, 2012 [Page 1]
Internet-Draft Gateway-based distribution October 21, 2011
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 Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Devices to run home proxies . . . . . . . . . . . . . . . . . . 4
3. Proxy configuration and discovery . . . . . . . . . . . . . . . 4
3.1. Configuration . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Proxy discovery . . . . . . . . . . . . . . . . . . . . . . 5
4. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Transparent vs. non-transparent . . . . . . . . . . . . . . 5
4.2. Caching proxies vs. local ALTO servers . . . . . . . . . . 6
5. Obtaining ALTO information . . . . . . . . . . . . . . . . . . 6
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Introduction
The ALTO service allows applications to obtain information about the
network cost between two peers. Applications use this information to
optimize their traffic (e.g., through proximity-based neighbor
selection), leading to better performance for end users, and
potentially lower operational costs for network operators. See
[RFC5693] for the ALTO problem statement.
The ALTO protocol [I-D.ietf-alto-protocol] defines communications
between an ALTO client (requesting cost information) and an ALTO
server (providing such information). Clients are typically peer-to-
peer applications run by users, while servers are typically run by
network operators. Peer-to-peer trackers may also behave as ALTO
clients, using the retrieved ALTO information to return localized
peer sets. This document considers only the first scenario, in which
peers contact an ALTO server directly to obtain ALTO information.
Fabio Picconi Expires April 23, 2012 [Page 2]
Internet-Draft Gateway-based distribution October 21, 2011
To improve scalability, peers may exchange the cost information
retrieved from an ALTO server, thus reducing server load. This is
known as ALTO information redistribution, and is discussed in [I-
D.ietf-alto-protocol] and [I-D.gu-alto-redistribution]. The ALTO
protocol does not make redistribution mandatory, and does not define
how it should be performed. It is up to each application to decide
whether to implement redistribution, and how (e.g., by using DHT or a
gossip-based protocol).
In this document we argue that distribution of ALTO information can
be enhanced by employing home proxies. An ALTO home proxy caches ALTO
information obtained from an origin ALTO server, and uses it to
respond to ALTO queries originating from the local home network. This
presents several advantages compared to using a remotely located ALTO
server:
1) Reduced ALTO traffic. Application-dependent redistribution might
result in unnecessary ALTO traffic. Consider, for instance, a home
network with two different active applications (e.g., a file sharing
application and a streaming application) which both implement
redistribution but using different mechanisms. The network and cost
maps downloaded by one application cannot be shared with the other.
If both applications use the ALTO home proxy, the ALTO information
will be fetched only once.
2) Increased redistribution. ALTO home proxies may redistribute
information to the home proxies of other peers. Therefore,
applications which do not implement redistribution may still generate
little or no load on the ALTO server if they use an ALTO home proxy
that implements redistribution.
3) Reduced latency. In case of a cache hit, the ALTO home proxy can
serve queries quickly given the low RTT and high bandwidth of home
networks. This may improve the performance of delay-sensitive
applications.
4) Background updates. If the home proxy is executed in a device that
is always on and connected to the network (such as a home gateway or
a home NAS), ALTO information updates can be pushed to the proxy
during off-peak hours, when there is plenty of available bandwidth
and ALTO servers are lightly loaded.
5) Discovery. If the home proxy has been configured to use a default
origin ALTO server, then applications using the proxy do not need to
use ALTO discovery to select an ALTO server. Moreover, applications
may easily discover the home proxy using protocols such as SLP
[RFC2608], uPnP, or Bonjour.
Fabio Picconi Expires April 23, 2012 [Page 3]
Internet-Draft Gateway-based distribution October 21, 2011
6) User privacy. Serving ALTO queries within the home makes it more
difficult for a third party (e.g., a remote ALTO server) to infer the
user's communications patterns by analyzing ALTO traffic.
The following sections discuss in more detail several aspects of
using ALTO home proxies.
2. Devices to run home proxies
ALTO home proxies may run on any home device which is connected to
the home network and has Internet access. This includes PCs, home NAS
servers, home gateways, etc. However, it may be preferable to run
home proxies on devices which are always on, such as a home gateway
or a NAS. This allows the proxy to optimize traffic (e.g., download
ALTO information updates during off-peak hours), and to maximize the
number of queries that can be served locally.
Many users employ home gateways which are owned and managed by their
Internet Service Provider (ISP). Typically, the ISP ships the gateway
to the user when he or she signs up for the Internet access plan. The
gateway is remotely configured by the ISP, which retains control on
the firmware, and in particular all the services, that run on the
gateway. This is typically the case for triple-play subscriptions,
where the gateway runs VoIP and IPTV services in addition to Internet
access.
ISPs that deploy ALTO servers in their network will probably consider
implementing ALTO home proxies as well. The computing power of
current gateways should easily support the small increase in CPU load
caused by the ALTO proxy service, especially given that the service
only replies to queries originating from the local network. Moreover,
the home proxy can be added to already deployed gateways by means of
a remote firmware upgrade.
Some users employ gateways which are not managed by their ISP. In
this case, gateway vendors may provide firmware upgrades which can be
installed by the user. Similarly, vendors or home NAS servers or
other networked home devices may provide firmware upgrades which
include an ALTO home proxy.
3. Proxy configuration and discovery
Two steps must be executed before applications can use an ALTO home
proxy: configuration and discovery.
Fabio Picconi Expires April 23, 2012 [Page 4]
Internet-Draft Gateway-based distribution October 21, 2011
3.1. Configuration
This step involves configuring the ALTO home proxy parameters. One
important parameter is the default origin ALTO server, i.e., the
server from which ALTO information will be fetched and cached, and
which will be used by default to answer queries. This can be obtained
using the mechanisms described in [I-D.ietf-alto-server-discovery].
If the ALTO home proxy runs on an ISP-managed gateway, the ISP may
also provide a default origin ALTO proxy (the ISP's own).
Another important parameter is whether the proxy will behave as a
caching proxy or a local server (see Section 3.1 for more details).
Other parameters may specify the maximum amount of data that can be
cached, the expiration time, etc. The user may be able to configure
these parameters through a local management interface (e.g., a web
page).
3.2. Proxy discovery
Applications running on the home can discover a local ALTO home proxy
by employing protocols such as SLP [RFC2608], uPnP, or Bonjour. An
important point is that application need not apply the discovery
mechanisms that are needed to use a remote ALTO server [I-D.ietf-
alto-server-discovery], as the home proxy has already been configured
with a default origin ALTO server.
4. Proxy behavior
Similarly to HTTP proxies, ALTO home proxies may be transparent or
non-transparent. Also, ALTO home proxies may behave as caching
proxies or local ALTO servers.
4.1. Transparent vs. non-transparent
A non-transparent proxy requires ALTO clients to be aware of their
presence, and direct ALTO queries to them instead of remote ALTO
servers. ALTO clients must be configured, either manually or
automatically, to use the home proxy. Manual configuration is
typically achieved by prompting the user for an IP address belonging
to the home network (e.g., 192.168.0.x). Automatic configuration can
be achieved by using a discovery protocol such as SLP, uPnP, or
Bonjour.
A transparent proxy intercepts ALTO requests directed to a remote
ALTO server. Therefore, they do not require ALTO clients to be aware
of their presence, or to discover them using protocols such as SLP,
Fabio Picconi Expires April 23, 2012 [Page 5]
Internet-Draft Gateway-based distribution October 21, 2011
uPnP, or Bonjour. Transparent proxies would typically run in home
gateways so that they can intercept requests originating from
multiple devices of the home network.
4.2. Caching proxies vs. local ALTO servers
ALTO home proxies may behave as simple HTTP caching proxies. The main
advantage of this is caching large responses from ALTO servers, such
as full network and cost maps. A caching proxy may also use
redistribution to fetch cacheable responses from other caching
proxies, thus reducing the load on the ALTO server. Caching proxies
may also prefetch ALTO information (e.g., an updated version of the
cost map) to reduce latency.
The disadvantage of caching proxies is that client-specific requests,
such as filtered maps, will probably result in a cache miss. To
counter this limitation, a home proxy may behave as a local ALTO
server. In this case, it uses the entire cost and network maps
previously downloaded from the remote ALTO server to produce,
whenever possible, a valid response to the client. A proxy acting as
a local server may return filtered maps even though such response has
not been previously cached.
The main limitation of proxies acting as local ALTO server is that
not all the functionalities of the origin ALTO server may be
available, e.g., generating signed data, or obtaining information
based on non-standard cost models which are not publicly known.
5. Obtaining ALTO information
Besides from caching responses from ALTO servers, home proxies may
obtain ALTO information from wide variety of sources. Update
dissemination may be pull-based or push-based [I-D.gu-alto-
redistribution], and peer-to-peer protocols such as BitTorrent may be
used for redistribution between home proxies.
An important issue is deciding which information to obtain, i.e.,
which resources and from which ALTO servers. Some users may manually
configure their applications to use an ALTO server different from
that obtained through the standard ALTO discovery mechanism. Home
proxies should be aware of such scenarios, and obtain the appropriate
ALTO information to maximize their hit ratio.
6 Security Considerations
ALTO home proxying loses its benefits when clients employ SSL/TLS to
Fabio Picconi Expires April 23, 2012 [Page 6]
Internet-Draft Gateway-based distribution October 21, 2011
verify the identity of the remote ALTO server. Clients may switch
back to HTTP to use the home proxy, but should be aware of the
possibility of integrity attacks on non-signed data. In the case of
ALTO home proxies running on ISP-managed gateways, the ISP may
provide SSL/TLS certificates for each gateway, thus supporting
SSL/TLS communications between clients and proxies. In this scenario,
clients may reasonably assume that home proxies acting as local ALTO
servers provides authoritative responses equivalent to those of the
ISP's remote ALTO server.
As mentioned before, serving ALTO queries within the home reduces the
amount of user-sensitive information that leaks to external parties
(e.g., a remote ALTO server). Therefore, ALTO home proxies should
enhance user privacy.
7 IANA Considerations
This document does not mandate any IANA actions.
8 References
8.1 Informative References
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October
2009.
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June
1999.
[I-D.gu-alto-redistribution]
Yingjie, G., Alimi, R., and R. Even, "ALTO Information
Redistribution", draft-gu-alto-redistribution-03 (work in
progress), July 2010.
[I-D.ietf-alto-server-discovery]
Kiesel, S., Siemerling, M., Schwan, N., Scharf, M., and H.
Song, "ALTO Server Discovery", draft-ietf-alto-server-
discovery-02 (work in progress), September 2011.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R. and Y. Yang, "ALTO Protocol", draft-
ietf-alto-protocol-09 (work in progress), June 2011.
Fabio Picconi Expires April 23, 2012 [Page 7]
Internet-Draft Gateway-based distribution October 21, 2011
Authors' Addresses
Fabio Picconi
Technicolor
1 rue Jeanne d'Arc
92443 Issy les Moulineaux cedex
France
EMail: fabio.picconi@technicolor.com
Fabio Picconi Expires April 23, 2012 [Page 8]
