Meeting notes from ALTO BoF, IETF72, Dublin July 29, 2008, 9:00-11:30 a.m. About 300 attendees This report is a distillation of the detailed meeting notes taken by Jan Seedorf and Robert Sparks. For Slides, see: https://datatracker.ietf.org/meeting/72/materials.html Chairs: Vijay Gurbani and Enrico Marocco Agenda Bashing -------------- Vijay Gurbani presents the agenda, asking if there are any objections to the agenda. No questions nor comments. ALTO Problem Statement ---------------------- Enrico Marocco presents the problem statement for ALTO: P2P traffic accounts for most internet traffic today; there has been a P2P Infrastructure Workshop organized by the RAI ADs, at the workshop three work areas for the IETF have identified, among these ALTO refers to caching and localization; the ALTO problem is basically that the peers have no knowledge of the network topology; ALTO proposes to define an interface for a peer selection optimization interface; there can be different kinds of ALTO service providers; research has shown that such a service can improve P2P routing with respect to ISPs' load and other things; issues include ISPs wanting to hide their topology and possibly misbehaving ALTO services; the core goals of ALTO are to have a protocol for finding the ALTO oracle and a protocol for querying the oracle; there are several use cases for ALTO, including real-time communications, P2P streaming, proximity neighbor selection in DHTs. Questions/comments: Stanislav Shalunov: is the primary problem reducing interdomain traffic? Can we put the problem we're trying to solve in the charter? This would be a good problem to put there. Stanislav: does BGP not give you information about the AS of other peers? Jon Peterson: the questions is not if applications can get information somehow, this BOF shall explore if there is a need for a standard for applications to obtain this information. Bob Briscoe: focus on smaller aspects of the problem to avoid a random walk. Need to determine if we are optimizing for the p2p traffic or the remaining interdomain traffic. Optimization is a balance. Henning Schulzrinne: would like to have a set of application scenarios; are non-P2P applications in the scope of ALTO? Enrico: yes. Henning: wanted to make sure we were talking about finding a service, not a file. Ted Hardie: I think this is about right problem statement, but there should be some tweaks around describing what is "optimal", particularly separating the impact on local link and the network as a whole. Optimal may vary depending on the ALTO service. There should be a way to get information to edge elements to affect finding services. (discussion with chairs - is the scope restricted to interdomain traffic optimization? - chairs say no - more discussion at mic.) ??: can client claim to be a peer or will that identity be ascertained by a server? Yunfei Zhen: as an operator - supports having an ALTO like mechanism, but has concerns w/ the problem statement; even using opaque means, this might give too much information about local topology; can the operator influence peer selection (chairs/AD redirect conversation to mechanism discussion). Dave Oran: Does the claim in the request allow 3rd party queries (answer is probably?) ALTO Survey ----------- Marco Tomsu presented a survey on existing work related to the ALTO scope: fundamental question is how to select a good peer? This can be done on the application level or with layer cooperation, different solutions exist for each of these approaches. Questions/comments: Henry Sinnreich: most ISPs don't own their facilities and may not be able to provide some of the information this work is asking for - the model doesn't reflect reality. Jon: this related work is not what will be standardized, rather the interface about querying an oracle is in the scope of ALTO. Henning: it needs to be investigated if all the existing approaches fit in the ALTO approach, specifically, do some existing solutions not fit in the ALTO approach? Lars Eggert: ALTO also needs to look at the semantics of the information on the interface, not just the bits. For instance, understanding the metrics for optimization is going to be one of the most important part of the discussions. Lars: ALTO should not be a mechanism for querying a disparate set of infromation providers (not interoperable on their own). Lisa Dusseault: predicts that finding one metric for optimization is not going to happen (and certainly not in a BOF). Bandwidth Costs --------------- Henning Schulzrinne presented on bandwidth costs: long term goal is to minimize bandwidth costs; the average bandwidth costs on the Internet are decreasing over time; if we move to an explicit pricing model, will there be application-visible charging indication (gave examples, e.g., "you are currently in your penalty box"); the ALTO problem in essence is an economics problem, it is to short-sighted to look at the problem from a technical perspective only. Questions/comments: Henry: most ISP have a different problem - lots of bandwidth in the center, but backhaul costs dominate. [At this point, some discussion ensued on what exactly is the definition of a backhaul.] David Bryan: cost is different to each observer (operator, end user). Would like all participants to get information about the cost impact of each path. Bob: cost of providing bandwidth is different to the cost of using bandwidth; the goal of ALTO should be about adopting to run-time conditions. Richard Woundy: as a cable operator, the predominate cost is access network. Other charging models (average vs 95%) are emerging that will have an impact on optimization. And surprising end users with large bills is something we need to avoid. Henning: having service suddenly drop off because you're in a penalty box without warning is also to be avoided. Henning - having service suddenly drop off because you're in a penalty box without warning is also to be avoided. ??: (from Time Warner), trying to expose (or even use real) internal operator costs needs to be out of scope. ??: if you refer everybody to download later and everybody does that, you have not solved the problem. Henning: that is an algorithmic problem. ALTO Requirements ----------------- Sebastian Kiesel presented ALTO requirements: requirements are independent of solutions, however looking at an example how ALTO could look like makes sense; gives an example on how ALTO could work in a tracker-based P2P network; there is already an terminology in a very early stage; let's focus on querying the ALTO service by clients for now, and not on feeding the ALTO service with information nor coordination among ALTO servers; the information available from the ALTO service is not a replacement for congestion control mechanisms; ALTO requirements are regarding the ALTO interface, error handling and overload protection, and security/privacy; there are still quite a few open issues. Questions/comments: Dave: is there a requirement for the client to know the decay rate of the usefulness of the information its receiving is? Sebastian: we can consider lifetimes. Dave: any measure like this would be a decay rate, not a lifetime. Alan (missed last name): question about peer selection - bias is towards client, but both sides should be involved - is there any work here that would go towards bi-directional peer selection? Henry: should not be the P2P providers be part of the ALTO design team? Enrico: one author of this document is from a P2P provider. Jon Peterson: this BOF would not take place if there had there not been considerable input and support from P2P providers. Lars: lets just agree to use TCP instead of going "lightweight" now and have something very complicated grow around it later. Jason Livingood: as operator, there are usecases around content ids in both directions - sometimes we might want to provide them and sometimes not. Caching and Peer Selection -------------------------- Reinaldo Penno presented on caching and peer selection in ALTO: there are several types of discovery; the next step is to come up with a document on discovery for ALTO servers and caches. Questions/comments: Dave: there's a difference between a service that rates things you know about vs a service that lets you discover things you don't know about. Which is in scope for ALTO? Do we combine discovery with rating? Lisa: is there anyone here who thinks they must be combined? Dave: refining the terminology to differentiate discovering ALTO servers from discovering services would be helpful. Alan Arodvich: so far we're only talking about the surface of the problem with caching. There are many more requirements to be captured beyond discovery. Similar Problems in Multi-homed Networks ---------------------------------------- Dimitri Papadimitriou presented on similar problems in multi-homed networks: the ALTO problem is selecting the best peer from a swarm; this is similar to the multihoming problem and IPv4-IPv6 DS; the problem is generic, the common problem is best path selection; ALTO can be used for the common problem if ALTO does not restrict its usabliity and extensibility and if the ALTO protocol supports transport addresses. No questions nor comments. Charter Discussion ------------------ Vijay Gurbani presented the charter for ALTO: the problem consists in optimizing peer selection; WG will produce protocols to enable communication between P2P systems and "informed" external services, all kinds of P2P systems are considered; work items include survey, taxonomy, a requirements document, a discovery mechanism for locating the oracle, a query/response protocol for communicating with the oracle (core protocol of ALTO), discovery mechanism for locating special nodes (e.g., caches, media relays); the focus shall be on the ALTO interface, algorithms for actually implementing the service are out of scope; legal issues are out of scope. Questions/comments: Ted: there seem to be classes of queries for the query protocol? (the things listed on the slide as discovery mechanisms for "special" nodes may need clarification). The Discovery problem is how do I find a useful oracle. Then you have a question about how do a get a candidate list to present to the oracle? Then you get to how do you use the query to the oracle to find one or more services. Which of these three do these work items address? Jon: I don't think restriciting to just those 3 at this point in time is appropriate. We may separate things, surely, but not limit to a particular subset of them. Ted: larger question is whether the scope in the charter covers work not directly related to the topics discussed so far (like finding TURN or 6to4 boxes). Trying to figure out if that general discovery problem is in scope. Henning: we can either build separate protocols to solve the different kinds of questions or decide to build a tightly coupled set of protocols. Choosing now to put answers to all 3 of the questions in "One Oracle" right now feels like it constrains the discussion inappropriately. Generally speaking, separation is a good thing. We should not be talking about "The Oracle". Dave: SPEECHSC faced a similar question - one thing that helped was to get agreement on the difference between requirements and preconditions (things we assume are already solved some other way). One precondition might be that we rely on an existing discovery protocol to find ALTO servers, for example. This will help ALTO avoid becoming a "must solve everything" problem. Jon: we will definitely have a requirement phase - the charter doesn't need to determine whether the requirements we write are satisfied by existing things or things this group produces. Dave: the charter should also not prejudge. Jon: today's discussion should focus on whether doing the work to define a standard service along these lines is something the IETF community is willing to take on. Lets keep this high level and identify discrete scope. Hugh (?? from Microsoft): thinks discovery mechanism is a distraction - we should spend more time talking about what "best" means. Greg Liebowitz: is the charter going to mandate an existing discovery protocol be used vs producing one here? Jon: no. But I anticipate that after we go through requirements we will not likely choose an existing protocol. However, there will not be an item in the charter calling out developing a protocol until the requirements indicate its needed. Greg: bar should be high for a new protocol - and charter should explicitly capture that. Dave: this question should be left to the requirements analysis phase. Greg: if we do use an existing discovery mechanism, do we need to lump in other problems (like media relay discovery) in this effort, or should those go into existing working groups or a separate effort entirely. Avshalom Houri: there is a lot of overlap with P2PSIP - how much discussion of division of work has taken place. Lisa: the chairs and ADs have been talking about this and there seems to be use for this kind of work outside the P2PSIP context. John Schnizlein: can we partition out those things that have already been solved by, e.g. BitTorrent, which things are being solved in other working groups, and then only focus here on what's left instead of the union of those three sets. Henning: still have a terminology problem. A protocol, an oracle, etc. Run the risk of having participants agreeing to move forward with widely different expectation about what the term "discovery" means. There's still confusion about such things as whether the type of content as part of a query is in scope or not. Would really rather break out explicit questions and argue their scope separately. Lars: TANA (transport) will be all about congestion issues with P2P networks. ALTO may or may not have other transport related issues. If you get to query it for long term information there should be no transport issues. But querying for fast changing information like load, delay or jitter is likely to lead to problems that should be solved at the transport level, not the application level - so they should be out of scope for ALTO. Ted: I think we should work on this problem space. The query response protocol is the easiest part of this. There are a whole set of semantic problems to work through and a requirements document may not be the best way to mine those - a separate design effort to answer those will make finishing a requirements document much simpler. Call for a Hum on slide containing two work items (1) discovery mechanism for locating the "oracle", and (2) query/response protocol for communicating with the "oracle". Many people agreed that this is important work for the IETF, also some (less) people hummed against. Hum was inconclusive - some of the "no" hums were (in Jon's words) vehement. Jon: ALTO work would give credibility to the IETF for solving an important problem. Bruce Lowekamp: including the general form of discovering arbitrary things may take this into a 3-body problem (as opposed to a 2-body problem). Lars: agrees with Bruce - the scope is too wide right now - if we limit what you can query the oracle for will make a better charter. Jonathan Rosenberg: if people don't think this is appropriate to do in the IETF, what do they think _is_? I support this. ??: still not comfortable with what the request should be about. Jon - the charter isn't going to call out what the metrics are or what the query should answer - that's the work we're talking about doing. Jason Livingood: this is a big problem for service providers and it is meaningful to work on this. Laird Popkin: strongly suggests we do this in the IETF instead of piece by piece. Ian: agrees with Jonathan - we should do this. David (?) Shephard: would convert hum to a yes if we could make it more clear why an oracle model is the right model. Suspects we're pre-anticipating the solution - the discussion right now feels to researchy.