Dear all,
for a recent study on the benefits of CDN (an overlay application) and
network operator (a large ISP) collaboration please check here:
"Pushing CDN-ISP Collaboration to the Limit"
Benjamin Frank, Ingmar Poese, Yin Lin, Georgios Smaragdakis, Anja
Feldmann, Bruce Maggs, Jannis Rake, Steve Uhlig, and Rick Weber.
ACM SIGCOMM Computer Communication Review, 43(3), July 2013.
link:
http://www.smaragdakis.net/publications/CCR-NetPaaS
best regards,
--George
----------------------------------
Georgios Smaragdakis,
Senior Researcher
Deutsche Telekom Laboratories
Technical University of Berlin
http://www.smaragdakis.net
On Tue, 9 Jul 2013, Y. Richard Yang wrote:
Hi Sabine, Sebastian,
Thanks a lot for the feedback and suggestions, which are added to the newer
version that we will post soon. Here is the new version of the intro that we
see feedback:
1. Introduction
1.1. Problem Statement
This document defines the ALTO protocol, which provides a solution
for the problem defined in [RFC5693]. Specifically, in today's
networks, network information such as network topologies, link
availability, routing policies, and path costs are hidden from the
application layer, and many applications benefited from such hiding
of network complexity. However, new applications, such as
application-layer overlays, can benefit from information about the
underlying network infrastructure. In particular, these modern
network applications can be adaptive, and hence become more network-
efficient (e.g., reduce network resource consumption) and achieve
better application performance (e.g., accelerated download rate), by
leveraging network-provided information.
At a high level, the ALTO protocol specified in this document is a
unidirectional interface that allows a Service Provider (e.g., an
ISP) to publish network information such as network locations, costs
between them at configurable granularities, and endhost properties to
network applications. The information published by the ALTO protocol
should benefit both Service Providers (providers of the information)
and Applications (consumers of the information). When a Service
Provider provides such information through the ALTO protocol, we say
that the provider provides the ALTO Service.
To better understand the goal of the ALTO protocol, we provide a
short, non-normative overview of the benefits of ALTO to both Service
Providers and Applications:
o A Service Provider that provides an ALTO Service can achieve
better utilization of its networking infrastructure. For example,
by using ALTO as a tool to interact with applications, a Service
Provider is able to provide network information to applications so
that the applications can better manage traffic on more expensive
or difficult to provision links such as long distance, transit or
backup links. During the interaction, the Service Provider can
choose to protect its sensitive and confidential network state
information, by abstracting real metric values into non-real
numerical scores or ordinal ranking.
o An Application that uses an ALTO Service can benefit from better
knowledge of the network to avoid network bottlenecks. For
example, a peer-to-peer overlay application can use information
provided by an ALTO Service to avoid selecting peers connected via
high-delay links (e.g., some intercontinental links). By using
ALTO information, applications can reduce the reliance on
obtaining network information through third-party databases;
applications relying on measuring path performance metrics
themselves can reduce the measurement overhead by conducting only
fine-tuning or fault-tolerant measurements on top of ALTO
information.
1.2. Design Overview
The ALTO protocol specified in this document meets the ALTO
requirements specified in [RFC5693], and unifies multiple protocols
previously designed with similar intentions. See Appendix A for a
list of people and Appendix B for a list of proposals that have made
significant contributions to this effort.
The ALTO protocol uses a REST-ful design [Fielding-Thesis], and
encodes its requests and responses using JSON [RFC4627]. These
designs are chosen because of their flexibility and extensibility.
In addition, these designs make it possible for ALTO to be deployed
at scale by leveraging existing HTTP [RFC2616] implementations,
infrastructures and deployment experience.
---------
On Fri, Jul 5, 2013 at 11:36 PM, Y. Richard Yang <[email protected]> wrote:
Hi Sabine,
Thanks a lot for the nice comments. Please see below.
On Thu, Jul 4, 2013 at 12:13 PM, RANDRIAMASY, SABINE (SABINE)
<[email protected]> wrote:
Hi Sebastian, Richard and all,
I definitely agree with the text before 1.1. referring to the pb
statement and requirements RFCs.
I also agree on the "link bandwidth mine field" issue. However, an ALTO
Server does not need to unveil the true values to provide guidance w.r.t. such
values. Therefore how about adding at the end of section 1.2.1 "Service
providers" some text like:
"Without unveiling sensitive and confidential information on the provider
network state, an ALTO Server can provide applications with its preferences
w.r.t. metrics such as e.g. monetary costs, bandwidth and delay; the
preference for instance may abstract real metric values in a non real time
numerical
score or cost or an ordinal rank."
The clarification makes sense. We will add the idea.
As for the discussion during the interim meeting on whether to keep a 1.5
pages Introduction section or shorten it drastically and redirect the reader to
the Pb statement RFC: although this will be a IESG decision, I'd like to
back Rich Alimi who prefers documents that are somewhat self-contained and
pointed that many people are reluctant to fetch and read tens of document
pages just to have a glimpse. The ALTO protocol is widely promoted in the
technical literature, usually with some 5-10 presentation lines and a reference to
the "ALTO Protocol" document. The latter is very well written and
having a 1.5 pages clear introduction makes it self-contained.
The newer version tries to maintain the self-contained flavor. There is one
round of revision already and we will post a new revision by Monday to get more
feedback.
Thanks again!
Richard
Thanks,
Sabine
-----Message d'origine-----
De : [email protected] [mailto:[email protected]] De la part de
Sebastian Kiesel
Envoyé : jeudi 20 juin 2013 08:46
À : Y. Richard Yang
Cc : IETF ALTO
Objet : Re: [alto] draft-ietf-alto-protocol-16: introduction section
Hi Richard,
On Wed, Jun 19, 2013 at 09:49:47PM -0400, Y. Richard Yang wrote:
> > One more comment about section 1.2.2, which says:
> >
> > For example, a peer-to-peer overlay application can use
information
> > provided by an ALTO Service to avoid selecting peers connected
with
> > low bandwidth links.
> >
> >
> > ALTO and link bandwidth is a mine field - not impossible at all, but
> > difficult, see the long discussions we had, partly summarized in sec.
> > 8.2.3 of draft-ietf-alto-deployments-06. Therefore I think it would
> > be wise to use a less controversial example here, say:
> >
> >
> > For example, a peer-to-peer overlay application can use
information
> > provided by an ALTO Service to avoid selecting peers connected via
> > intercontinental (i.e., high-delay) links.
> >
> >
> >
> I like the revision. I may suggest some change to the wording, since
> some two points in two continents may be closer to some two
> intra-continent
> points:
>
> For example, a peer-to-peer overlay application can use information
> provided by an ALTO Service to avoid selecting peers connected via
> high-delay links (e.g., some intercontinental links).
>
> What do you think?
Even better!
Thanks
Sebastian
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
