Subject: [alto] Short review about the draft-ietf-alto-protocol-16

From: "Qiushi Wang" <[email-masked]>
Date: Fri, 12 Jul 2013 14:26:14 +0200

Dear authors,

I'm a Ph.D. student in FU-Berlin. I have taken an IETF course in my
university since May. This course introduces us some basic information
about the working groups. I choose Alto as my working group to follow,
because it has some relations with my research of offloading. I have read
the document of draft-ietf-alto-protocol-16, and followed the discussion
in the mailing list for two months. Obviously, this draft is clearly
written and has been polished quite well. I know it is very close to be an
RFC and the new version-17 will be available on Monday. If you still have
some time and interesting, please consider my two comments about this
draft.

1.
------------
It mentioned several times "third-party" in this document, but the
meanings in each place are not the same. As in the abstract, “and third
parties could also operate an ALTO service”, it's considered here that the
third party is one of the providers. But in section 1.2.2, “By using ALTO
information, applications can reduce the reliance on obtaining network
information through third-party databases”, and in section 3.2, “a
third-party” in the end of the second paragraph, they have different
meanings with each other, also with that in the abstract. So a clear
description about each third-party make readers more easy to understand.

2.
------------
Section 1.2.2

It's not obvious that the measurement overhead can be reduced by
conducting only fine-tuning or fault-tolerant measurement. It's better to
list the parts of the overhead which can be removed.

------------

Thanks a lot for your work.

Best wishes,
Qiushi Wang

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 12 Jul 2013 09:44:56 -0400

Dear Qiushi,

Thanks for the feedback. Please see below.

> some time and interesting, please consider my two comments about this

Good consistency check. The basic meaning of third-party is that it it
neither the owner of the network infrastructure nor the app. Assume that
the owner of the network infrasturce is A. But it is B who provides ALTO
network information for A's network. There can be multiple scenarios. One
example is that B is officially delegated by A to provide ALTO service for
A. This is not surprising in that many networks choose to delegate the
management to others. One can imagine that there can be cases where B is
not delegated by A. As an example, if a commercial database provider
decides to use ALTO as the mechnism to provide its collected information
about network A, it cannot a potential deployment scenario. All preceding
will have its security and privacy implications. It is a good suggestion
from you to be more careful. we will use more explicit words in the
revision.

To avoid the details and the complexity that follows, we can remove the
word fine-tuning and say only that the application can use ALTO info about
latency and bandwidth, if provided, and hence no need to measure the
latency or bandwidth itself. How does this sound?

Richard

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 12 Jul 2013 16:14:23 +0200

Qiushi,
Richard,

> latency or bandwidth itself. How does this sound?

I think the word fine-tuning shouldn't be removed completely. But maybe
we need some fine-tuning of that paragraph :-)

The motivation for this paragraph was to say that, in the P2P scenario,
if you really want to know throughput values you will have to measure
them yourself (in the overlay). ALTO can give some predictions who could
be good other peers and who not, but there are may reasons why ALTO may
not be accurate (see sec. 8.2.3. of draft-ietf-alto-deployments-06).

One of the main benefits of ALTO is that if I join a new swarm, ALTO may
give me some promising ("better-than-random") peers to start
communicationg with, but then I should do some fine-tuning of my peer
lists based on own measurements.  So the saving of overhead is probably
not saving traffic for probe messages (many measurements are done on the
regular application traffic anyway) but it is faster convergence to a
good state.

Just my 2 cents
Sebastian

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 12 Jul 2013 11:41:30 -0400

Hi Sebastian,

> regular application traffic anyway) but it is faster convergence to a
Good discussion. Please see below for the revised text:

        An application that uses an ALTO Service can benefit from
        better knowledge of the network to avoid network
        bottlenecks. For example, an overlay application can use
        information provided by the ALTO Service to avoid selecting
        peers connected via high-delay links (e.g., some
        intercontinental links).  Instead of using third-party
        databases such as geo-location databases, the application can
        use ALTO as a standard to obtain related information. Using
        ALTO to start each node with promising
        ("better-than-expected") peers, an adaptive peer-to-peer
        overlay may achieve faster, better convergence.

Does it address all comments?

Thanks!

Richard

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 12 Jul 2013 21:16:29 +0200

Hi Richard,

On Fri, Jul 12, 2013 at 11:41:30AM -0400, Y. Richard Yang wrote:
>         intercontinental links).

>         Instead of using third-party
>         use ALTO as a standard to obtain related information. 

I don't like this sentence, as it somehow mingles who provides
information ("third-party" -- we have an own paragraph on who could
possibly become an ALTO provider) and through which standard
interface/protocol (ALTO vs. (proprietary) databases).

Maybe just omit it.

>         Using

Maybe replace "start" with "initialize".

What is "better-than-expected"?  Please repeat the wording
"better-than-random peer selection" from the ALTO problem statement
document.

Thanks
Sebastian

p.s.: thanks to Qiushi for the review!

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 12 Jul 2013 15:34:00 -0400

Hi Sebastian,

On Friday, July 12, 2013, Sebastian Kiesel wrote:

> > On Fri, Jul 12, 2013 at 10:14 AM, Sebastian Kiesel <[email-masked]<javascript:;>
> >wrote:
> >
> > > Qiushi,
> > > Richard,
> > >
> > > > > conducting only fine-tuning or fault-tolerant measurement. It's
> better
> > > to
Using ALTO as a unifying interface is a benefit of a standard. But it is
indeed better that we delete the sentence.

> Maybe replace "start" with "initialize".
OK.

> "better-than-random peer selection" from the ALTO problem statement

Sure. It was a typo.

Thanks!

Richard