< draft-dulinski-alto-inter-problem-statement-00.txt   draft-dulinski-alto-inter-problem-statement-01.txt >
ALTO Working Group Z. Dulinski ALTO Working Group Z. Dulinski
Internet-Draft Jagiellonian University Internet-Draft Jagiellonian University
Intended status: Informational P. Wydrych Intended status: Informational P. Wydrych
Expires: September 5, 2011 R. Stankiewicz Expires: January 12, 2012 R. Stankiewicz
P. Cholda
M. Kantor
AGH University of Science and AGH University of Science and
Technology Technology
March 4, 2011 July 11, 2011
Inter-ALTO Communication Problem Statement Inter-ALTO Communication Problem Statement
draft-dulinski-alto-inter-problem-statement-00 draft-dulinski-alto-inter-problem-statement-01
Abstract Abstract
This draft considers an approach to the optimization of the traffic This draft considers an approach to the optimization of the traffic
generated by the overlay (peer-to-peer) applications, where some generated by the overlay (peer-to-peer) applications, where some
information on inter-AS (Autonomous System) paths is obtained with information on inter-AS (Autonomous System) paths is obtained with
the usage of dedicated communication scheme known as inter-ALTO the usage of dedicated communication scheme known as inter-ALTO
communication. communication.
The large amount of network traffic generated by overlay applications The large amount of network traffic generated by overlay applications
skipping to change at page 2, line 13 skipping to change at page 2, line 11
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Problem and Motivation . . . . . . . . . . . . . . . . . . 6 3. The Problem and Motivation . . . . . . . . . . . . . . . . . . 6
3.1. Route Asymmetry . . . . . . . . . . . . . . . . . . . . . 8 3.1. Route Asymmetry . . . . . . . . . . . . . . . . . . . . . 8
3.2. Different Types of Business Relations . . . . . . . . . . 8 3.2. Many ASes within One ISP . . . . . . . . . . . . . . . . . 8
3.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . . 9 3.3. Different Types of Business Relations . . . . . . . . . . 9
3.4. Proximity Awareness . . . . . . . . . . . . . . . . . . . 9 3.4. Congestion Avoidance . . . . . . . . . . . . . . . . . . . 9
3.5. Remote ISP's Preference . . . . . . . . . . . . . . . . . 9 3.5. Proximity Awareness . . . . . . . . . . . . . . . . . . . 9
3.6. Coordination of ISPs' Policies . . . . . . . . . . . . . . 10 3.6. Remote ISP's Preference . . . . . . . . . . . . . . . . . 10
3.7. Sensitivity of Topology Information . . . . . . . . . . . 11 3.7. Coordination of ISPs' Policies . . . . . . . . . . . . . . 10
3.8. Outdated Information . . . . . . . . . . . . . . . . . . . 11 3.8. Sensitivity of Topology Information . . . . . . . . . . . 11
3.9. Outdated Information . . . . . . . . . . . . . . . . . . . 11
3.10. Mobile Networks . . . . . . . . . . . . . . . . . . . . . 11
3.11. Route Aggregation . . . . . . . . . . . . . . . . . . . . 12
4. Usage of the Mechanisms Offered by the ALTO Protocol . . . . . 11 4. Usage of the Mechanisms Offered by the ALTO Protocol . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Informative References . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document describes the rationale for a communication to be used This document describes the rationale for a communication to be used
between ALTO servers located in different autonomous systems (AS). between ALTO servers located in different autonomous systems (AS).
Such an inter-ALTO communication extends the ALTO service Such an inter-ALTO communication extends the ALTO service
[RFC5693]capabilities and provides additional information on remote [RFC5693]capabilities and provides additional information on remote
peers, i.e., peers located in other ASes. To make the consideration peers, i.e., peers located in other ASes. To make the consideration
more clear we distinguish local AS and remote ASes. Local AS is the more clear we distinguish local AS and remote ASes. Local AS is the
one from which perspective we describe the communication. Local one from which perspective we describe the communication. Local
skipping to change at page 6, line 29 skipping to change at page 6, line 29
supporting the best choice of the mirror servers. If some mirror supporting the best choice of the mirror servers. If some mirror
servers are in other ASes than the client's AS, some information servers are in other ASes than the client's AS, some information
about the network conditions in the remote ASes may be delivered only about the network conditions in the remote ASes may be delivered only
by the ALTO servers localized in these ASes. Both clients and mirror by the ALTO servers localized in these ASes. Both clients and mirror
servers may communicate with their local ALTO servers for delivering servers may communicate with their local ALTO servers for delivering
traffic optimization parameters. As an ALTO client communicates only traffic optimization parameters. As an ALTO client communicates only
with its local ALTO server, the information from remote ASes is with its local ALTO server, the information from remote ASes is
accessible only via inter-ALTO communication. accessible only via inter-ALTO communication.
The ALTO-based traffic optimization may be also used in the context The ALTO-based traffic optimization may be also used in the context
of the Content Delivery Networks (CDNs) [I-D.penno-alto-cdn]. Penno of the Content Delivery Networks (CDNs)
et al. discuss how the ALTO service can be used in the existing and [I-D.jenkins-alto-cdn-use-cases]. The draft by Niven-Jenkins et al.
future CDNs. They consider the case when the CDN nodes are in shows how CDNs may benefit from the information provided by the ALTO
multiple administrative domains. In that case the inter-ALTO protocol. Local information, however, may be not sufficient to
communication is used. optimize the request routing process. The information gathered from
ALTO servers in other domains may be needed.
The basic ALTO architecture presented in Figure 1 of the ALTO The basic ALTO architecture presented in Figure 1 of the ALTO
protocol draft [I-D.ietf-alto-protocol] defines the external protocol draft [I-D.ietf-alto-protocol] defines the external
interface used to communicate with other information sources like interface used to communicate with other information sources like
remote ALTO servers. The ALTO Protocol draft, however, does not remote ALTO servers. The ALTO Protocol draft, however, does not
define what information should be exchanged between ALTO servers to define what information should be exchanged between ALTO servers to
optimize the traffic. The inter-ALTO communication proposed by the optimize the traffic. The inter-ALTO communication proposed by the
current document implements the external interface as defined by the current document implements the external interface as defined by the
ALTO protocol draft. ALTO protocol draft.
skipping to change at page 8, line 36 skipping to change at page 8, line 36
routing information can be obtained from Looking Glass Servers, but routing information can be obtained from Looking Glass Servers, but
not all ASes provide them. The inter-ALTO communication provides the not all ASes provide them. The inter-ALTO communication provides the
ability to exchange the relevant information between ALTO servers. ability to exchange the relevant information between ALTO servers.
Especially, the downstream path can be reliably determined using the Especially, the downstream path can be reliably determined using the
information provided by remote ALTO server. In the light of route information provided by remote ALTO server. In the light of route
asymmetry in the Internet such information appears to be necessary asymmetry in the Internet such information appears to be necessary
for a better optimization of a peer rating/ranking algorithm, as for a better optimization of a peer rating/ranking algorithm, as
assumption that the inter-AS routes follow symmetrical paths can give assumption that the inter-AS routes follow symmetrical paths can give
not only sub-optimal, but misleading and, in effect, harmful results. not only sub-optimal, but misleading and, in effect, harmful results.
3.2. Different Types of Business Relations 3.2. Many ASes within One ISP
An ISP may possess a complex topology network composed of many
autonomous systems. Current ALTO specification allows for deployment
of independent ALTO servers in each AS. In such a case the overlay
traffic management performed by the ALTO server is restricted to a
single AS since cost maps have a local meaning. An ISP operating a
multi-AS network may be interested in managing the traffic in the
whole administrative domain in a consistent and coordinated manner.
The information possessed by a single ALTO server is insufficient.
To obtain a complete knowledge on the multi-AS network a
communication between ALTO servers is needed. As a result, local
cost maps originating from different autonomous systems may be
coordinated. A uniform cost map reflecting the whole network
structure may be created and distributed between ALTO servers.
3.3. Different Types of Business Relations
Two basic business relations between ISPs may be distinguished. Two basic business relations between ISPs may be distinguished.
When two ISPs agree to exchange the traffic without any charge, such When two ISPs agree to exchange the traffic without any charge, such
a relation is called peering. The inter-domain link between the a relation is called peering. The inter-domain link between the
respective ASes is also called a peering link. Usually, there is no respective ASes is also called a peering link. Usually, there is no
charge if the difference between traffic volumes passing such a link charge if the difference between traffic volumes passing such a link
in different directions does not exceed a previously agreed limit. in different directions does not exceed a previously agreed limit.
The other case occurs when one ISP serves as a network provider to The other case occurs when one ISP serves as a network provider to
skipping to change at page 9, line 16 skipping to change at page 9, line 33
AS may be connected to many other ASes with various agreements. The AS may be connected to many other ASes with various agreements. The
cost of the inter-AS traffic transfer may differ depending on which cost of the inter-AS traffic transfer may differ depending on which
neighbor AS the path passes. For this reason an ISP may prefer that neighbor AS the path passes. For this reason an ISP may prefer that
its own customers exchange data with remote peers located in such its own customers exchange data with remote peers located in such
ASes that the path directed to them passes cheaper links. The ALTO ASes that the path directed to them passes cheaper links. The ALTO
server may sort peers taking into account these criteria. To receive server may sort peers taking into account these criteria. To receive
almost complete information on routing paths to and from different almost complete information on routing paths to and from different
remote domains the information provided by remote ALTO server using remote domains the information provided by remote ALTO server using
inter-AS communication may be helpful. inter-AS communication may be helpful.
3.3. Congestion Avoidance 3.4. Congestion Avoidance
A peer rating/ranking procedure may also take into account the A peer rating/ranking procedure may also take into account the
congestions on inter-AS links. An ISP is able to monitor queues on congestions on inter-AS links. An ISP is able to monitor queues on
its inter-domain links and assign metrics indicating the buffer its inter-domain links and assign metrics indicating the buffer
occupancy or bandwidth utilization. These metrics can express occupancy or bandwidth utilization. These metrics can express
percentage use of buffers or bandwidth on a particular inter-AS link. percentage use of buffers or bandwidth on a particular inter-AS link.
If one inter-domain link is congested it is desirable to promote If one inter-domain link is congested it is desirable to promote
peers reachable through lightly loaded links. Again, information peers reachable through lightly loaded links. Again, information
provided by the remote ALTO server would support such optimization. provided by the remote ALTO server would support such optimization.
The aim of the inter-ALTO communication is not to replace the The aim of the inter-ALTO communication is not to replace the
existing congestion avoidance mechanisms. The idea is to support the existing congestion avoidance mechanisms. The idea is to support the
present mechanism by the exchange of parameters describing the load present mechanism by the exchange of parameters describing the load
on the inter-AS links. on the inter-AS links.
3.4. Proximity Awareness 3.5. Proximity Awareness
For a set of reasons (e.g. the performance of an application) the For a set of reasons (e.g. the performance of an application) the
ALTO server may suggest its customers to connect to remote peers ALTO server may suggest its customers to connect to remote peers
located in its proximity. The simplest measure of proximity is the located in its proximity. The simplest measure of proximity is the
number of inter-AS hops. As indicated above, due to the route number of inter-AS hops. As indicated above, due to the route
asymmetry, the number of hops may significantly differ between the asymmetry, the number of hops may significantly differ between the
upstream and downstream paths. Such information for the downstream upstream and downstream paths. Such information for the downstream
path may be provided by the remote ALTO server. A more advanced path may be provided by the remote ALTO server. A more advanced
metric of proximity can be found in the delay that can be metric of proximity can be found in the delay that can be
approximated by exchanging messages between ALTO servers. The ALTO approximated by exchanging messages between ALTO servers. The ALTO
servers can be equipped with an application-layer ping functionality servers can be equipped with an application-layer ping functionality
which only operates between ALTO servers. By exchanging special which only operates between ALTO servers. By exchanging special
packets prepared by the ALTO servers, these servers can estimate packets prepared by the ALTO servers, these servers can estimate
delay and packet loss. delay and packet loss.
3.5. Remote ISP's Preference 3.6. Remote ISP's Preference
If two ISPs agree on a cooperation, the remote ALTO server may If two ISPs agree on a cooperation, the remote ALTO server may
provide its preference parameters (remote preference parameters) provide its preference parameters (remote preference parameters)
indicating which peers are better from the point of view of the indicating which peers are better from the point of view of the
remote ISP. For instance, the AS in which the remote ALTO server is remote ISP. For instance, the AS in which the remote ALTO server is
located may possess two subnetworks connected to the operator's core located may possess two subnetworks connected to the operator's core
network by distinct links. It may happen that a connection to one of network by distinct links. It may happen that a connection to one of
the subnetworks is cheaper than the other. The remote operator may the subnetworks is cheaper than the other. The remote operator may
prefer connections through cheaper link, so peers located in the prefer connections through cheaper link, so peers located in the
subnetwork transferring data via this cheaper link are preferred. subnetwork transferring data via this cheaper link are preferred.
skipping to change at page 10, line 26 skipping to change at page 10, line 42
parameters have only local meaning, i.e., their values are comparable parameters have only local meaning, i.e., their values are comparable
for peers located in the same AS only. for peers located in the same AS only.
If a remote ISP does not want to reveal numerical values of network If a remote ISP does not want to reveal numerical values of network
parameters related to its peers (such information might be considered parameters related to its peers (such information might be considered
as confidential) the remote ALTO server may perform a rating/ranking as confidential) the remote ALTO server may perform a rating/ranking
procedure and assign priority parameter to its peers. The rating/ procedure and assign priority parameter to its peers. The rating/
ranking criteria may remain hidden for the requesting local ALTO ranking criteria may remain hidden for the requesting local ALTO
server. server.
3.6. Coordination of ISPs' Policies 3.7. Coordination of ISPs' Policies
Operators may have an incentive to coordinate their efforts in order Operators may have an incentive to coordinate their efforts in order
to decrease transfer costs on inter-AS links or improve quality to decrease transfer costs on inter-AS links or improve quality
experienced by peers, i.e., coordinate their peer rating/ranking experienced by peers, i.e., coordinate their peer rating/ranking
strategies. This way, operators may avoid contradictory strategies strategies. This way, operators may avoid contradictory strategies
resulting in inefficiency of rating/ranking algorithms. Operators resulting in inefficiency of rating/ranking algorithms. Operators
may agree to promote each other's peers. may agree to promote each other's peers.
For example, it may happen that operator A wanting to decrease For example, it may happen that operator A wanting to decrease
traffic on one of its links discourages its own peers from traffic on one of its links discourages its own peers from
skipping to change at page 11, line 7 skipping to change at page 11, line 23
Another example of a usefulness of coordination of policies is Another example of a usefulness of coordination of policies is
clustering of ASes. Recent studies [IJNM.unfairness] have shown that clustering of ASes. Recent studies [IJNM.unfairness] have shown that
locality promotion might be ineffective or even harmful if used in AS locality promotion might be ineffective or even harmful if used in AS
with small number of peers. A proposed solution is to create a with small number of peers. A proposed solution is to create a
cluster of two or more ASes. Then ALTO servers serving different cluster of two or more ASes. Then ALTO servers serving different
ASes in the cluster treat all peers located in the cluster as if they ASes in the cluster treat all peers located in the cluster as if they
were in a single AS. In other words, from a point of view of were in a single AS. In other words, from a point of view of
locality promotion algorithm all peers located in the cluster are locality promotion algorithm all peers located in the cluster are
local, regardless of their home AS. local, regardless of their home AS.
3.7. Sensitivity of Topology Information 3.8. Sensitivity of Topology Information
The minimum information that the remote AS provides to the local ALTO The minimum information that the remote AS provides to the local ALTO
server via the inter-ALTO communication may be the number of inter-AS server via the inter-ALTO communication may be the number of inter-AS
hops and the number of the local AS's neighbor in the downstream path hops and the number of the local AS's neighbor in the downstream path
(the full downstream AS_PATH may be not exchanged). Such information (the full downstream AS_PATH may be not exchanged). Such information
does not reveal any sensitive information neither on the ISP internal does not reveal any sensitive information neither on the ISP internal
topology details nor remote AS connections with other ASes, but does topology details nor remote AS connections with other ASes, but does
provide basic and very useful information for the local ALTO server. provide basic and very useful information for the local ALTO server.
3.8. Outdated Information 3.9. Outdated Information
It is expected that some information (parameters) from routing It is expected that some information (parameters) from routing
protocols that will be used in the rating/ranking procedures may protocols that will be used in the rating/ranking procedures may
outdate. Also information related to the network performance is outdate. Also information related to the network performance is
constantly changing. Therefore, the information obtained from the constantly changing. Therefore, the information obtained from the
remote AS requires updates. This updates may be generated on request remote AS requires updates. This updates may be generated on request
(pull mechanism), on event base schema or periodically (push (pull mechanism), on event base schema or periodically (push
mechanism). The inter-ALTO communication should be equipped with mechanism). The inter-ALTO communication should be equipped with
mechanisms for updates. The need for the present information mechanisms for updates. The need for the present information
describing network conditions and some routing parameters are describing network conditions and some routing parameters are
arguments for introducing specific protocol for the communication arguments for introducing specific protocol for the communication
between ALTO servers. between ALTO servers.
3.10. Mobile Networks
The inter-ALTO communication may be very useful for mobile network
operators and content providers serving mobile clients. An ALTO
server may recognize mobile clients and properly assign them to PIDs.
Some information about the mobile network resources gathered from
mobile network nodes located in different networks should be
exchanged between operators for better then random peer selection.
ALTO servers should posses information which allows to make proper
peer selection, taking into account, e.g., the mobile network load
(including the load in the radio access network and in the circuit-
and packet-switched domains).
After collecting the load information, the ALTO server may assign
priorities. These priorities may exemplify the load in some parts of
the radio access network. Via the inter-ALTO communication, the
priorities may be passed to the other operator's networks where other
clients are located. Relying on this information, the ALTO server
may optimize the connections between clients.
3.11. Route Aggregation
The BGP protocol allows the aggregation of specific routes into one
route. In such a case the aggregate route is advertised. The full
path is either lost completely or the AS set information is
available. In the latter case only the set of ASes behind the
aggregating router is known but the detailed information about the
routing path, including AS sequence and AS-hop count, is lost. From
the overlay traffic optimization point of view the knowledge on ASes
located behind aggregating router and the number as well as sequence
of inter-AS hops may be useful, e.g., because of route asymmetry
problem described earlier (Section 3.1). The solution for this
problem is information exchange between ALTO servers located in ASes
ahead and behind the router aggregating routes.
4. Usage of the Mechanisms Offered by the ALTO Protocol 4. Usage of the Mechanisms Offered by the ALTO Protocol
The basic ALTO protocol architecture allows an ALTO server to The basic ALTO protocol architecture allows an ALTO server to
communicate with a third party through the external interface. The communicate with a third party through the external interface. The
inter-ALTO communication may use some functionalities offered by the inter-ALTO communication may use some functionalities offered by the
ALTO protocol [I-D.ietf-alto-protocol]. ALTO protocol [I-D.ietf-alto-protocol].
Server Information Service: This service defined by the ALTO Server Information Service: This service defined by the ALTO
protocol may be extended in order to provide information about protocol may be extended in order to provide information about
server's ability to cooperate with other ALTO servers. Thanks server's ability to cooperate with other ALTO servers. Thanks
skipping to change at page 13, line 35 skipping to change at page 14, line 35
The set of procedures for the inter-ALTO communication is expected to The set of procedures for the inter-ALTO communication is expected to
be separated from the client ALTO communication and this can be be separated from the client ALTO communication and this can be
achieved by distinct protocols. achieved by distinct protocols.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgements 7. Acknowledgements
This draft evolved from draft-dulinski-alto-inter-alto-protocol-00. The authors would like to thank following people for the valuable
The authors would like to thank all authors of the Inter-ALTO discussions (in alphabetical order):
communication protocol draft for their contributions.
o Piotr Cholda (AGH University of Science and Technology)
o Miroslaw Kantor (AGH University of Science and Technology)
o Jan Medved (Juniper)
o Stefano Previdi (Cisco)
o Robert Varga (Pantheon)
This work has been partially supported by the EU through the ICT FP7 This work has been partially supported by the EU through the ICT FP7
Project SmoothIT (FP7-2007-ICT-216259). Project SmoothIT (FP7-2007-ICT-216259).
8. Informative References 8. References
8.1. Normative References
[I-D.ietf-alto-protocol] [I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-06 (work in progress), draft-ietf-alto-protocol-09 (work in progress), June 2011.
October 2010.
[I-D.penno-alto-cdn]
Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R.,
and S. Previdi, "ALTO and Content Delivery Networks",
draft-penno-alto-cdn-02 (work in progress), October 2010.
[ICC.optimal] [ICC.optimal]
Dulinski, Z., Kantor, M., Krzysztofek, W., Stankiewicz, Dulinski, Z., Kantor, M., Krzysztofek, W., Stankiewicz,
R., and P. Cholda, "Optimal Choice of Peers based on BGP R., and P. Cholda, "Optimal Choice of Peers based on BGP
Information", Proceedings of 2010 IEEE International Information", Proceedings of 2010 IEEE International
Conference on Communications (ICC), May 2010. Conference on Communications (ICC), May 2010.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
8.2. Informative References
[I-D.jenkins-alto-cdn-use-cases]
Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
S. Previdi, "Use Cases for ALTO within CDNs",
draft-jenkins-alto-cdn-use-cases-01 (work in progress),
June 2011.
[IJNM.unfairness] [IJNM.unfairness]
Lehrieder, F., Oechsner, S., Hossfeld, T., Staehle, D., Lehrieder, F., Oechsner, S., Hossfeld, T., Staehle, D.,
Despotovic, Z., Kellerer, W., and M. Michel, "Mitigating Despotovic, Z., Kellerer, W., and M. Michel, "Mitigating
unfairness in locality-aware peer-to-peer networks", unfairness in locality-aware peer-to-peer networks",
International Journal of Network Management, Volume 21, International Journal of Network Management, Volume 21,
Issue 1, pp. 3-20, January/February 2011. Issue 1, pp. 3-20, January/February 2011.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
Authors' Addresses Authors' Addresses
Zbigniew Dulinski Zbigniew Dulinski
Jagiellonian University Jagiellonian University
ul. Reymonta 4 ul. Reymonta 4
Krakow 30-059 Krakow 30-059
Poland Poland
Phone: +48 12 663 5571 Phone: +48 12 663 5571
Fax: +48 12 633 4079 Fax: +48 12 633 4079
skipping to change at page 14, line 38 skipping to change at page 16, line 4
Zbigniew Dulinski Zbigniew Dulinski
Jagiellonian University Jagiellonian University
ul. Reymonta 4 ul. Reymonta 4
Krakow 30-059 Krakow 30-059
Poland Poland
Phone: +48 12 663 5571 Phone: +48 12 663 5571
Fax: +48 12 633 4079 Fax: +48 12 633 4079
Email: dulinski@th.if.uj.edu.pl Email: dulinski@th.if.uj.edu.pl
Piotr Wydrych Piotr Wydrych
AGH University of Science and Technology AGH University of Science and Technology
al. Mickiewicza 30 al. Mickiewicza 30
Krakow 30-059 Krakow 30-059
Poland Poland
Phone: +48 12 617 4817 Phone: +48 12 617 4817
Fax: +48 12 634 2372 Fax: +48 12 634 2372
Email: piotr.wydrych@agh.edu.pl Email: piotr.wydrych@agh.edu.pl
Rafal Stankiewicz Rafal Stankiewicz
AGH University of Science and Technology AGH University of Science and Technology
al. Mickiewicza 30 al. Mickiewicza 30
Krakow 30-059 Krakow 30-059
Poland Poland
Phone: +48 12 617 4036 Phone: +48 12 617 4036
Fax: +48 12 634 2372 Fax: +48 12 634 2372
Email: rstankie@agh.edu.pl Email: rstankie@agh.edu.pl
Piotr Cholda
AGH University of Science and Technology
al. Mickiewicza 30
Krakow 30-059
Poland
Phone: +48 12 617 4036
Fax: +48 12 634 2372
Email: piotr.cholda@agh.edu.pl
Miroslaw Kantor
AGH University of Science and Technology
al. Mickiewicza 30
Krakow 30-059
Poland
Phone: +48 12 617 2852
Fax: +48 12 634 2372
Email: kantor@kt.agh.edu.pl
 End of changes. 28 change blocks. 
47 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/