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
