On Sat, 28 Feb 2009, 1:11pm +0200, Spiros Spirou wrote: > 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
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 > 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 > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
