Subject: Re: [alto] draft-ietf-alto-protocol-16: introduction section

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Thu, 4 Jul 2013 16:13:39 +0000

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."

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. 

Thanks,
Sabine

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 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-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 5 Jul 2013 23:36:20 -0400

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-masked]> wrote:

> 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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 9 Jul 2013 14:11:30 -0400

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-masked]> wrote:

> 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
>>
>>
>>

---

From: Georgios Smaragdakis <[email-masked]>
Date: Tue, 9 Jul 2013 20:27:46 +0200 (CEST)

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
> 
> On Thu, Jul 4, 2013 at 12:13 PM, RANDRIAMASY, SABINE (SABINE) <[email-masked]> wrote:
>       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."
> 
>       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
> 
> 
>