Subject: Re: [p2prg] review of draft-asai-cross-domain-overlay

From: Piotr Wydrych <[email-masked]>
Date: Mon, 26 Sep 2011 23:42:27 +0200

Hirochika, Hiroshi, Tsuyoshi,
All,

Below you'll find my thoughts on the draft, both substantive and editorial.

In some places I thought that a preposition, punctuation, or junction 
should appear. Since I'm not a native speaker and I'm not sure, I do not 
enumerate these places. Maybe a proof-reader would help.

 > 1.  Introduction

Paragraph #2:
 >    (...) Our simulation results show that (...)

Reference(s) needed. [Asai10-1]? [Asai10-2]?

 >    (...) autonomous systems (ASes) [RFC1930] (...)

Do we really need to reference what an AS is in such a document?

 > 1.1.  Terminology
 > 1.1.1.  AS
 >    Autonomous System

As above.

 > 1.1.2.  AS Relationships

I'd rename it to AS-AS Relationship or AS-to-AS Relationship.

 > 1.1.3.  Transit
 >    Transit is a type of AS relationships.  Transit relationships are
 >    also called provider-customer relationships.  A customer AS purchases
 >    Internet access from its transit providers over transit links by
 >    paying some amount of money according to the actual bandwidth usage.

I'd change it to: Transit is an AS relationship in which a customer
AS purchases Internet access from its transit provider(s) over 
transitlink(s) by paying some amount of money according to the actual 
bandwidth usage.  Transit relationships are also called 
provider-customer relationships.

 > 1.1.4.  Peering
 >    Peering is a type of AS relationships, and the relationships between
 >    two peering ASes are equal relationships. (...)

I'd change it to: Peering is an AS relationship in which two peering 
ASes are equal.

 > 2.  Problem Statement

Paragraph #2:
 >    However, overlay networks sometimes break these routing policies and
 >    cause problems with cross-domain traffic. (...)

I'd change it to: However, overlay networks sometimes are not aware of 
these routing policies and generate expensive cross-domain traffic.

 > 2.2.  Cross-Domain Cooperation

Paragraph #1:
 >    (...) Cost distributed by
 >    this protocol is assumed to compute based on P4P [Xie08] that is an
 >    oracle-based approach of application-layer traffic optimization. (...)

1. This sentence needs rephrasing.
2. Since P4P was designed for BitTorrent and ALTO is 
protocol-independent, I'd rather say that the oracle service proposed in 
"Can ISPs and P2P systems co-operate for improved performance?" by 
Aggarval et al. is more similar to ALTO than P4P is.

Paragraph #3:
 >    (...) Hence, there is a difficulty in applying
 >    the approach of cross-domain cost computation in P4P to the real
 >    Internet because issues on disclosing topology information, such as
 >    confidential commercial contracts, lie upon it. (...)

s/P4P/an oracle-based service/, to be generic

 > 3.  Simulation Results: Cross-domain Policy Conflicts

Paragraph #3:
 >    (...) ``Selfish'' is an algorithm to select
 >    a peer minimizing expense of ASes accommodating download peers (based
 >    on a download-side policy or referring to a download-side ALTO
 >    server); (...)

First, file-sharing peers may use biased (ALTO-supported) unchoking 
(see, e.g., <http://www3.informatik.uni-wuerzburg.de/TR/tr459.pdf>).
Second, in case of CDNs, the optimization is done by the upload side. 
Third, in streaming services, e.g., P2PTV, peers may upload more than 
they download. Therefore, it may be not enough to take into account the 
download path and policy. The upload path and cost are needed. Moreover, 
``download-side'' may be not an adequate term. Maybe it should be named, 
e.g., a local (from the optimization algorithm's view) one?

 > 4.  Solution Approach
 >
 >    1.  AS path provision service: This service provides AS paths between
 >        two arbitrary nodes (IP addresses) to applications or cost
 >        computation servers (e.g., ALTO servers), and it is provided by
 >        each AS.
 >
 >    2.  AS relationships estimation service: This service provides AS
 >        relationships (i.e., cross-domain cost) of any specified inter-AS
 >        links to applications or cost computation servers.  This service
 >        is provided by its service providers which may not be ISPs but
 >        some other volunteer service providers.
 >
 >    3.  Cost computation service: This service computes cost for an AS
 >        path according to an algorithm, and it is installed into each
 >        application or cost computation servers on the Internet.  The
 >        cost is computed as a globally unique value on the Internet when
 >        the algorithm is identical.  Here, a set of the computed cost is
 >        denoted as ``global cost map''.  The computed cost for the AS
 >        path would be used for traffic optimization.

The probability that each AS will deploy the service is IMHO marginal. 
How does this cost estimation algorithm work if only a small subset of 
ASes provide information? Does it work well if the path information is 
provided not by each AS, but by each AS which is interested in 
cost-effective optimization? What if we do not have any information from 
transit ASes?

 >    This approach aims to hide information on AS relationships as much as
 >    possible; i.e., not to disclose AS relationships.  So, it uses AS
 >    relationships estimated from publicly available information instead
 >    of AS relationships which are to be disclosed by ASes.  This document
 >    provides one possible estimation method and the detailed description
 >    follows in Section 4.2.

I wonder what is better (and why). On one hand, ASes interested in 
cost-effective overlay traffic optimization may send path information to 
a trusted third-party server. Then, the server may redistribute this raw 
information. It may compute some combined map and redistribute it. It 
can even do only IP rating/ranking process to hide more information. On 
the other hand, ASes may exchange the path information between each 
other directly. Then, they may exchange as much information as they 
want. Especially, they may agree on some metrics which are in relation 
to traffic cost. I think that without input from operators, it will be 
an open question.

Regards,
Piotr
-- 
Piotr 'GhosT' Wydrych .. xmpp:wydrych//agh.edu.pl .. http://wydrych.net/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

---

From: Hirochika Asai <[email-masked]>
Date: Tue, 27 Sep 2011 11:13:25 +0200

Hi Piotr,

Thank you for your review.

We're trying to improve the draft according to your comments with some additional experiments and simulations.  We need more time to get comments we received from all volunteers involved in the draft.
As soon as we complete the modification, we'll summarize the points where discussions are required, and let you know.

As you pointed out, our solution approach needs discussion on the balance between deployment cost and its benefit.  So we'd better to start from making sure the problems with inter-domain traffic optimization; algorithms should follow clear problem statements.
One more from your review comments, we understand that we should summarize the problems, categorized by P2P algorithms like BitTorrent-like, CDNs, P2P streaming etc.

We'll consider them and update the draft soon.

Thank you,
Hirochika

On Sep 26, 2011, at 11:42 PM, Piotr Wydrych wrote:

> In some places I thought that a preposition, punctuation, or junction should appear. Since I'm not a native speaker and I'm not sure, I do not enumerate these places. Maybe a proof-reader would help.
> 
> > 1.  Introduction
> 
> Paragraph #2:
> AS purchases Internet access from its transit provider(s) over transitlink(s) by paying some amount of money according to the actual bandwidth usage.  Transit relationships are also called provider-customer relationships.
> 
> > 1.1.4.  Peering
> I'd change it to: Peering is an AS relationship in which two peering ASes are equal.
> 
> > 2.  Problem Statement
> 
> Paragraph #2:
> I'd change it to: However, overlay networks sometimes are not aware of these routing policies and generate expensive cross-domain traffic.
> 
> 2. Since P4P was designed for BitTorrent and ALTO is protocol-independent, I'd rather say that the oracle service proposed in "Can ISPs and P2P systems co-operate for improved performance?" by Aggarval et al. is more similar to ALTO than P4P is.
> 
> Paragraph #3:
> First, file-sharing peers may use biased (ALTO-supported) unchoking (see, e.g., <http://www3.informatik.uni-wuerzburg.de/TR/tr459.pdf>).
> Second, in case of CDNs, the optimization is done by the upload side. Third, in streaming services, e.g., P2PTV, peers may upload more than they download. Therefore, it may be not enough to take into account the download path and policy. The upload path and cost are needed. Moreover, ``download-side'' may be not an adequate term. Maybe it should be named, e.g., a local (from the optimization algorithm's view) one?
> 
> > 4.  Solution Approach
> >
> The probability that each AS will deploy the service is IMHO marginal. How does this cost estimation algorithm work if only a small subset of ASes provide information? Does it work well if the path information is provided not by each AS, but by each AS which is interested in cost-effective optimization? What if we do not have any information from transit ASes?
> 
> I wonder what is better (and why). On one hand, ASes interested in cost-effective overlay traffic optimization may send path information to a trusted third-party server. Then, the server may redistribute this raw information. It may compute some combined map and redistribute it. It can even do only IP rating/ranking process to hide more information. On the other hand, ASes may exchange the path information between each other directly. Then, they may exchange as much information as they want. Especially, they may agree on some metrics which are in relation to traffic cost. I think that without input from operators, it will be an open question.
> 
> Regards,
> Piotr
> -- 

-- 
Hirochika Asai <[email-masked]>, The University of Tokyo