Subject: Re: [alto] Comments on requirements draft

From: Spiros Spirou <[email-masked]>
Date: Sat, 28 Feb 2009 13:11:22 +0200

Hi Sebastian, all,

On 25 Φεβ 2009, at 3:18 ΜΜ, Sebastian Kiesel wrote:

> On Wed, Feb 25, 2009 at 10:02:14AM +0200, Spiros Spirou wrote:
>> In the current draft, info seems to flow only
>> from the ALTO service to the P2P system. I feel that there is (or  
>> should
>> be) a reverse flow of info as well: the P2P system informs the  
>> provider of
>> the ALTO service (realistically, a network operator) about P2P system
>> traffic, so that the operator can do efficient traffic management.
>
> The extension you propose here sounds interesting but is rather
> substantial, so I kindly ask you to give us more information (if you
> have any), and the other folks here on the list to comment on it:
>
> - Are there any field trial or simulation results, which show that
> this mode of operation can improve the situation?

When an ALTO Client contacts the ALTO Service it indirectly provides  
two pieces of info: host identity (e.g. IP address) and application  
type (e.g. P2P). When the ALTO Client also submits a list of Transport  
Addresses of candidate Resource Providers to be ranked by the ALTO  
Service, it provides several pieces of additional info: host  
identities and application type of other nodes. When all these pieces  
are combined, the ALTO Service can deduce a set of specific  
application flows. This information, as has been shown by several  
simulations and trials so far, can be used by a party (e.g. a network  
operator) "behind" the ALTO Service, to manage (e.g. localize)  
application traffic. Note here that the alternative for a network  
operator is to use expensive monitoring methods like Deep Packet  
Inspection.

In the protocol implied by the requirements so far, the information  
flow described above is indirect and ad hoc. I'm suggesting that this  
should be formalized. There might be that in the future, or in  
different contexts, other information will be necessary  
(notwithstanding Laird's valuable comments). The protocol should allow  
for this information flow and leave it up to the involved parties and  
to "solutions" to decide what to use and how. This is the spirit  
behind a few of my proposed requirements:

- sec#4.1, add after REQ. 2 and re-number accordingly: "REQ. 3: The  
ALTO clients MUST be able to submit to the ALTO service information  
that can be used by network operators to optimize network resource  
consumption."
- sec#4.2, add after REQ 13 and re-number accordingly: "REQ. 13: The  
ALTO protocol MAY have a mechanism by which the ALTO service can  
specify the level and precision of application information required  
from the ALTO client."
- sec#4.2, add before REQ 14 and re-number accordingly: "REQ. 13: The  
ALTO protocol MAY have a mechanism by which the ALTO client can  
specify preferences and relative importance of rating criteria to be  
used by the ALTO service in calculating recommendations for resource  
provider selection."

In this view, the ALTO Service is more of an ALTO Broker that  
facilitates the transaction of (summarized) information between  
parties suspicious of each other (e.g. P2P systems and network  
operators), so it can be used by specific "solutions" to create  
appropriate incentives per situation. Actually, this discussion seems  
more fitting to the problem statement than to the protocol requirements.

Admittedly, the difficulty here is to strike a balance between  
protocol generalization and complexity.

> - Would ALTO server operators (i.e., network operators according to  
> your
> assertion) be willing to receive information from customers (users)
> via this interface, or will they only trust their own traffic
> monitoring systems? How big is the risk of this interface being  
> abused?

I think the risk is equal to that of the ALTO Client interface being  
abused by a malicious master of the ALTO Service. That's why neither  
party should blindly trust what the other is saying through the ALTO  
Service. ALTO-obtained info should initially complement info obtained  
through other means (e.g. operator monitoring systems, application- 
level topology discovery mechanisms) and its significance could be  
raised if it proves accurate. But now I'm going into solutions and  
we're only talking about the protocol. The ALTO protocol might make an  
effort to authorize and authenticate parties (I share Reinaldo's  
skepticism on this), but it should mainly and simply provide facility  
and syntax info transaction. Semantics and use of the carried info  
should be up to the transacting parties and specific solutions.

> - Who is willing to contribute to this work at this point in time?
>

SmoothIT, an FP7 project, is looking at the ALTO problem as an  
economic transaction. I can report/contribute findings, as they become  
available.

>
>> Also, to reflect the varying needs of P2P systems and their users,  
>> I think
>> there must be a way for an ALTO client to signal to the ALTO service
>> preferences regarding rating criteria to be used in calculating
>> recommendations. (I think this has been already proposed by various  
>> people
>> on the list).
>
> Indeed. Some days ago I posted a summary of such rating criteria,
> which have already been proposed during former discussions, to this
> mailing list. I am planning to include them in the next version of
> the requirements draft, so comments are most welcome. That mail was:
>
> Message-ID: <[email-masked]>
> Date: Wed, 11 Feb 2009 14:54:57 +0100
> Subject: [alto] list of possible attributes (was: Re: differences
>       among applications)
>

Thanks. I'll take a closer look and get back with comments.

>
>> Finally, neighboring domains might agree it makes business sense to
>> optimize P2P traffic in collaboration. An interface between ALTO  
>> services
>> that would facilitate the exchange of (summarized) topological info  
>> to
>> increase the optimization scope of either, would be helpful in this  
>> case.
>
> Sure. The fact that this is one part of the big picture has been
> discussed in the past (see, e.g., the slides from the Dublin meeting)
> but so far the main focus was on the interface to the clients.
> Can you propose requirements regarding this interface, or even a
> solution approach?
>

In trying to catch up, I looked at the wiki as Vijay suggested. This  
covers only IETF73, so could someone please provide pointers to  
earlier material (if available)?

I can have a go at the inter-ALTO interface, but let me first see what  
has been covered already.

Thanks,

Spiros

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 1 Mar 2009 08:08:43 -0800

Looking at the current draft, a few thoughts....

The usage cases may be too broad.  EG, local mirror/caching discovery  
for conventional CDN operation doesn't need to rely on alto, and would  
probably not benefit, as the conventional CDNs have solved the problem  
"good enough", and it also interacts with their OWN secret-sauce.

My thought would be focus on the two useage cases which count:

Bulk data P2P peer localization, and P2P hashtable localization, where  
the first is about saving cost while providing the same service, while  
the latter is reducing latency.

On security considerations, any open-world P2P system per file can be  
tracked from one or more nodes by creating sybils, so ALTO doesn't  
make the problem easier, and any P2P system which deliberately hides  
this (eg, by onion-routing data) is not going to WANT localization and  
increased localization increases the power of traffic analysis.

Thus I believe that ALTO should NOT attempt to be privacy preserving,  
because the protocols that use it won't be privacy preserving anyway.

---

From: "Y. R. Yang" <[email-masked]>
Date: Sun, 1 Mar 2009 12:23:15 -0500 (EST)

> the latter is reducing latency.
 
Can you elaborate some more on reducing latency only for P2P hashtable?
 
> tracked from one or more nodes by creating sybils, so ALTO doesn't make 
> the problem easier, and any P2P system which deliberately hides this 
> (eg, by onion-routing data) is not going to WANT localization and 

You mean no privacy preserving only for P2P clients. I have to disagree. 
Here are some reasons: (1) Giving ALTO Servers such information will make 
it possible for some parties to demand that such information be collected; 
this increases potential burdens on ISPs and thus may hinder ALTO 
deployment. (2) Sybils have limitations, e.g., limited view, large number 
of torrents that are hard to track, closed trackers, closed-source systems 
(the world is larger than BitTorrent), symbils can be banned... ALTO 
Servers without privacy preservation for P2P clients can help to "solve" 
these problems.

Richard

---

From: "Y. R. Yang" <[email-masked]>
Date: Sun, 1 Mar 2009 12:34:43 -0500 (EST)

On Sat, 28 Feb 2009, 1:11pm +0200, Spiros Spirou wrote:

> Hi Sebastian, all,
> On 25 ??? 2009, at 3:18 ??, Sebastian Kiesel wrote:
> 

Can you give references to the simulations and trials? I am curious about 
the "manage" they did by asking such fine-grained, per-flow information. 
Do they even need to ask for per-flow rate feedback? This opens a 
substantial scalability and privacy problem. There are schemes where 
detailed feedback from applications to networks can be helpful with 
convergence and efficiency (e.g., unitcast congestion control). But this 
requirement is so substantial that in my opinion, should not be required, 
at least during the first round.

Richard

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