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 protected]>
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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
